A list of technologies is not yet an architecture. Start by identifying the responsibilities the application must fulfil and the boundaries between them. Then choose tools that fit those responsibilities and the team's ability to operate them.
- 01Follow one request
- 02Separate slow work from the interaction
- 03Make retrieval accountable
- 04Define failure at each boundary
- 05Choose for maintainability
Follow one request
Describe the sequence from the user's action to the final result. The interface collects input. The application checks permission. A task may run immediately or be queued. Data may be retrieved before a model is called. The result needs validation, storage and a way for the user to find it.
Not every application needs every stage. Add components because the work requires them, not because a reference stack includes them.
Separate slow work from the interaction
Long-running generation or processing may need a background job with visible status. Define what happens if the user closes the page, the job fails or the request is repeated. Store enough state to resume or explain the outcome.
Make retrieval accountable
If the application uses a knowledge library, preserve source references and access rules. A search result should not expose material the user was never allowed to read. Retrieved content also needs to remain distinct from system instructions.
Define failure at each boundary
Consider unavailable providers, invalid output, missing records and expired permissions. Decide what the user sees and what an operator can inspect. A generic error message is not an operating strategy.
Choose for maintainability
Use a small, understandable stack that meets the current requirements. The transcript that prompted this map listed several specific frameworks and services. Their names matter less than the responsibilities they were intended to handle. A team must be able to maintain the boundaries after the initial build.