An architecture decision should connect a customer constraint to a design choice. A diagram with model, database, and agent boxes is incomplete unless it explains why those components are necessary and who operates them.
Compare a baseline
For document-assisted support, compare a searchable knowledge base with a retrieval-and-drafting system. The latter may reduce writing effort while introducing generated-answer risk, model costs, and extra operational work.
Use a decision record:
| Field | Example |
|---|---|
| Problem | Staff repeatedly search policy documents |
| Constraint | Answers must use the requesting team’s documents |
| Options | Search only; search plus draft generation |
| Decision | Pilot draft generation with human review |
| Evidence | Representative tasks and measured baseline |
| Revisit when | Quality or operating costs miss agreed targets |
Show trust boundaries: browser to backend, backend to customer APIs, and backend to model provider. Specify which data crosses each boundary and which identity authorizes it. Consider retention and hosting constraints before choosing services.
Budget the request
Split the latency budget among retrieval, model generation, and other integrations. A component that seems fast alone may be too slow when several calls run sequentially. Define timeout and fallback behavior for the whole request.
Exercise
Draw two architectures for the same pilot and write the decision record. Include operating ownership and the simplest rollback.
Check: each extra component addresses a documented need. Explain one condition that would make you choose the simpler alternative.