Contents
An architecture should explain how a user request becomes a verified result. For an AI application, that includes where information is selected, where model output is checked and where an action is authorised. Start with those responsibilities and the intended user journey before choosing the components that implement them.
Trace a request from entry to accepted result
Choose a representative task and draw the path through the application. Identify the request boundary, user identity, data sources, model call and final response or mutation. Mark where external input enters and which component is responsible for validating it.
Include unsuccessful paths. Show what happens when required information is unavailable, an external dependency fails or the model produces an unusable result. The architecture should explain how the application reports incomplete work and preserves a consistent state.
Separate information selection from model generation
Identify which component retrieves or prepares the information the model receives. Document the source of truth and how access rules apply during selection. Make the freshness and availability requirements explicit so the team can decide what the application should do when they are not met.
Keep generated content distinguishable from source records. Decide which outputs are temporary suggestions and which may be persisted after validation or review. If the product stores conversation or task history, define its purpose, access and retention through the organisation's appropriate data-handling process.
Give orchestration a clear contract
Define what a task controller receives, the stages it may execute and what counts as completion. Keep business rules and permissions in application services rather than embedding them solely in model instructions. Record which choices are fixed and which are delegated to the model.
For long-running work, decide how status is represented and how the user can stop or resume the task. Bound repeated attempts and external calls. If the process spans failures or restarts, identify the durable state needed to avoid losing progress or repeating accepted actions.
Treat tools as application interfaces
Expose operations with narrow, documented inputs and safe result shapes. Validate requests and enforce the user's authority at each operation. Keep direct database access and external-service credentials behind the application's established boundaries.
For mutations, define idempotency and the evidence of acceptance. A task should use the responsible service's result to determine whether an action succeeded. If human approval is required, specify where it is captured and how the approved values reach the final operation unchanged.
Make configuration and evaluation part of delivery
Track the model configuration, prompts, retrieval settings and tool contracts that affect behaviour. Link a release to the relevant evaluation evidence. Define which changes require a fresh comparison and which owners must review the result.
Keep the evaluation environment representative enough to test the important boundaries without exposing production data unnecessarily. Use controlled cases for permissions, missing evidence and failed dependencies. Document the limitations of the test environment alongside its results.
Design for the team that will operate it
Identify the signals needed to distinguish failures in retrieval, model generation, validation and downstream actions. Use safe identifiers and coarse categories where they provide enough diagnostic value. Agree who can inspect more detailed records when an authorised investigation requires them.
Plan the behaviour when an AI capability is disabled or its provider is unavailable. Decide which surrounding journeys can continue and how users are informed. Keep the operating documentation aligned with the released system so the architecture remains useful after the first implementation.
Compare synchronous suggestions with durable background work
For a fictional assistant summarising one supplied request, a synchronous path may be enough: authenticate, validate input, call the model with a bounded timeout, validate the result and show a suggestion. On failure, return an understandable incomplete state. Avoid introducing a background task system solely because the feature uses AI.
For a longer task that reads several authorised records and prepares an amendment for approval, compare a durable background controller. It records progress and configuration, validates each operation and waits for explicit approval of proposed values. If the process restarts after an amendment was accepted, it reconciles that result rather than issuing the write again. Cancellation must define which work stops and which already accepted changes remain.
Use a component record: entry point owns identity; retrieval owns permitted source selection; model adapter owns provider communication; validator owns output checks; business service owns authority and mutations; task controller owns progress; reviewer owns the approval decision. Compare these boundaries with a monolithic handler through the same timeout, permission and restart cases. Microsoft’s retrieval reference informs the information boundary, not the entire architecture or its acceptance.
How this relates to Veda Software’s work
Powerleague’s separation of venue ordering, central visibility and fulfilment is relevant to responsibility mapping. It does not prove an AI architecture. These are Veda Software application concerns; strategy and adoption remain with VEDA AI.