AI system architecture: from data to dependable workflows

Start with the system boundary

Define one job before choosing a model. A support assistant may draft an answer from approved documentation; an operations assistant may propose a CRM update. Those jobs have different data access, failure costs, and review requirements. Write down the input, the permitted output, and the person responsible when the system cannot finish.

This is a design reference for teams building AI workflows. It is not a claim that every Arrow deployment uses the same infrastructure or that a specific integration is available in every plan.

Separate the five responsibilities

1. Sources: keep an inventory of approved documents and records, with owners, versions, access rules, and deletion behavior.
2. Retrieval: select relevant evidence within the authenticated user's permissions before giving it to the model.
3. Generation: ask the model for a bounded answer or proposal and retain the source references used.
4. Execution: validate proposed actions against server-side rules. Apply approval and duplicate protection where the action requires them.
5. Evaluation: replay representative tasks after a change and inspect both answer quality and workflow outcomes.

The boundaries let a team diagnose a bad result. An outdated answer could come from an old source, a missed document, or a claim the model added. Changing the prompt alone will not repair all three.

A worked example: a support response draft

Illustrative design: a signed-in support specialist asks whether a product supports a specific export format. The service identifies the account and product version, retrieves the matching documentation, and asks for a draft with a source link. The specialist reviews the draft before sending it.

If the documentation does not answer the question, the assistant says what is missing and routes the request to a product owner. It does not infer support from a similar product. The trace stores document identifiers, the model and prompt versions, a review outcome, and timing; sensitive ticket text follows a separate retention policy.

Choose the smallest useful release

Start with a read-only task and a named review owner. Add writes only after the team can evaluate the proposals and explain failures. Live account facts belong in an authorized data lookup; internal manuals belong in permission-aware retrieval. Neither should be copied into a public answer hub.

For the next design decision, read how to build reliable answer systems and our guide to retries and duplicate protection. For Arrow product scope, visit AI Systems.

Sources and editorial scope

Engineering guidance by Arrow AI, published and reviewed October 15, 2026. Worked examples are illustrative designs; they are not customer deployments or measured results.

• AWS: transactional outbox and duplicate event handling