# AI agent architecture: choose the simplest system that works - Author: FMKTech Team - Published: 2025-11-06 - Reading time: 4 min - Tags: AI Architecture, Workflows, Software Engineering - URL: https://www.fmktech.com.br/blog/understanding-ai-agents-architecture-and-patterns.md (HTML: https://www.fmktech.com.br/blog/understanding-ai-agents-architecture-and-patterns) From a fixed workflow to an autonomous loop: how to choose an architecture, define its boundaries, and evaluate the result beyond a convincing demo. --- *Revised September 4, 2026.* An agent architecture should explain who decides the next action, where state lives, and what prevents an invalid action. A diagram with several model icons is not enough. Start by identifying which decisions are predictable. Keep calculations, permissions, and fixed business rules in ordinary code. Use a model where interpretation is valuable, then decide whether it needs to choose the sequence of work. ## Workflow or agent? A workflow follows a path defined by the application. An agent can choose its next step based on what it observes. Anthropic's discussion of effective agents makes this distinction and recommends starting with simple approaches before adding complexity. More autonomy can introduce additional latency, cost, and opportunities for error. [Read the original discussion](https://www.anthropic.com/engineering/building-effective-agents). For example, extracting fields from an incoming request does not necessarily require an agent. Validating those fields, applying a known rule, and routing exceptions to a person may be enough. ## Choose a pattern for a reason The following is our practical selection guide, using a support operation as an illustrative example. | Shape | Useful when | What to check | | --- | --- | --- | | Fixed sequence | The same steps apply to each request: extract, validate, draft. | A bad early result must not silently pass to the next stage. | | Routing | Requests need different handling paths. | Include an explicit uncertain or unsupported category. | | Parallel work | Independent checks can run at the same time. | Reconcile disagreement; duplicated model opinions are not independent evidence. | | Coordinator and workers | The work can be split after inspecting the request. | Define ownership, input/output contracts, and a final integration check. | | Evaluation loop | There is a concrete criterion for improving a draft. | Stop after a budget or lack of progress; an evaluator's approval is not ground truth. | | Agent loop | The right next step depends on new information. | Bound tools, steps, cost, and escalation before execution. | These shapes can be combined, but each additional layer should solve a demonstrated problem. Do not add workers merely because parallel execution is available. ## Make state explicit For a request under investigation, keep the authoritative state outside the conversation: request identifier, current status, collected evidence, proposed actions, approvals, and recorded outcomes. The model can interpret this state, but a fluent summary should not replace it. If the run restarts, the system needs to know whether an action happened, not whether a previous message said it probably did. Separate proposed actions from executed ones. A draft response, an approved response, and a sent response are distinct states. Carry a durable identifier across retries and use the downstream system's recorded result to resolve uncertainty. ## Design tools around business operations Prefer a tool with a narrow purpose and meaningful errors over a general escape hatch. “Get the permitted order's delivery status” is easier to validate than “execute arbitrary SQL.” Define required inputs, authorization, side effects, retry behavior, and the evidence returned. Make missing information explicit rather than substituting a plausible value. The calling model should be able to distinguish “not found,” “not permitted,” and “temporarily unavailable” where disclosure rules allow it. An agent may choose among available tools; it should not be able to expand its own authority. See our [security guide](/blog/ai-agent-security-challenges) for that boundary. ## Evaluate the whole task Build a small set of representative cases before optimizing prompts. Include normal requests, ambiguous requests, contradictory sources, and cases outside the system's authority. Hold back some cases for evaluation so you are not only testing examples used during development. Check both outcome and conduct. Did the system reach the correct result? Did it consult an appropriate source, respect access restrictions, and stop when required? Measure end-to-end latency and total cost, including retries and human correction. Review failures by category. If a fixed rule solves a recurring class of errors, use it rather than asking the model to reason through it again. ## A sensible path to more autonomy Begin with recommendations or drafts for review. Add a specific action when its acceptance criteria, authorization, and recovery behavior have been demonstrated. Expanding autonomy is a change to the product's risk, not merely a model setting. Re-run the relevant evaluations whenever the model, tools, instructions, or connected systems change. For a concrete experiment with typed interfaces and parallel workers, see [our game-building workflow and playable results](/blog/replicating-fable-with-opus). For choosing the business problem first, see [the operational guide to agents](/blog/what-are-ai-agents). --- ## Where to look next - [Blog index](https://www.fmktech.com.br/blog.md) - [Homepage](https://www.fmktech.com.br/.md) - [llms.txt](https://www.fmktech.com.br/llms.txt)