AI system architecture: the model is one component

Start with the whole service

An AI application needs an entry point, identity checks, orchestration, information access and a way to return useful results. The model handles a particular part of that service. Business systems, monitoring and human review complete the picture. Architecture describes how those responsibilities fit together and what happens when a component is unavailable.

Keep business rules in trusted services

An agent can propose a tool call, but the receiving service must validate its inputs and permissions. A purchase-order update should pass the same business rules as an equivalent user action. Read-only information access and transactional changes deserve separate interfaces. Logs should make an action traceable without indiscriminately recording private prompts or customer data.

One agent or several?

Microsoft describes orchestration patterns for coordinating agents, including sequential and concurrent approaches. Additional agents introduce coordination and failure paths. Begin with the simplest pattern that meets the task. Separate specialists only when their responsibilities, tools or evaluation requirements justify it; more agents do not automatically create a better business result.

A practical architecture review

For the supplier-delay scenario already on this site, draw the message source, order lookup, proposed response, approval and update as separate responsibilities. Ask who owns each step, how duplicate messages are handled and how a failure is recovered. Assess quality, response time and operating cost together. That discussion is more useful than selecting a model before agreeing what the service must do.

Microsoft sources and further reading

• Microsoft Architecture Center: AI agent orchestration patterns