Agent Architectures in Practice: Patterns, Platforms, and Use Cases

I use a simple test before designing an agent: could ordinary code or a clear workflow solve this more reliably?

If the answer is yes, I use ordinary code. Agents are useful when the work is open-ended, the next step depends on what was found, and a model needs to choose between several tools. They are not a better name for every automation.

The basic loop

An agent receives a goal, chooses an action, observes the result, and decides what to do next.

flowchart LR
  G[Goal] --> P[Choose next step]
  P --> T[Call a tool]
  T --> C[Check the result]
  C -->|Continue| P
  C -->|Need approval| H[Human review]
  C -->|Complete| D[Return result]
  H --> P

The loop is easy to draw. The engineering work sits around it:

• tools with narrow permissions and clear schemas;
• state that survives retries and restarts;
• limits on time, cost, and tool calls;
• checks for invalid or unsafe output;
• traces that explain what happened;
• a defined way to stop or ask a person.

Without those controls, autonomy mostly means unpredictable failure.

Choose the simplest architecture

I think about four levels.

1. A function

Use a function when inputs, rules, and outputs are known. Calculations, validation, data transforms, and permission checks belong here. A model can help interpret an input, but it should not replace rules the business already understands.

2. A workflow

Use a workflow when the steps are known but some steps need a model. For example: classify a document, extract fields, validate them, ask for approval, then update a system. The workflow owns the order and retries; the model handles bounded judgement inside a step.

This is my default for business automation because it is easier to test and operate than an open loop.

3. A single agent

Use one agent when the goal is open-ended and the agent must choose tools or revise its approach. Research, support investigation, and coding assistance can fit this shape.

One capable agent with good tools is usually easier to understand than a team of agents. I add specialisation only when evaluation shows that one role is carrying too much context or making conflicting decisions.

4. Multiple agents

Use multiple agents when separate roles need different instructions, tools, permissions, or review responsibilities. Splitting a task merely to make the diagram look sophisticated adds latency and more failure points.

Patterns I actually use

A group chat is rarely my first choice. Free-form conversations between agents are difficult to test and can consume a great deal of context without improving the result. Explicit hand-offs and structured outputs are easier to reason about.

Tools are the real security boundary

An agent cannot do more than its tools allow. I design tools as if they were public APIs:

• one clear purpose per tool;
• typed inputs and validated outputs;
• authentication outside the prompt;
• least-privilege access;
• idempotency where retries are possible;
• read-only access first;
• approval before high-impact writes.

For knowledge tools, I treat retrieval as a separate system. This guide to vector databases and hybrid search covers the design choices behind it.

I never rely on the model to enforce authorisation. The application checks the user’s identity and permissions for every tool call. Instructions such as “only access the current customer’s data” are useful context, not a security control.

State, memory, and context are different

These terms are often mixed together.

• State is where the workflow is and what has happened.
• Context is the information sent to the model for this call.
• Memory is selected information kept for future calls or sessions.

I persist workflow state outside the model so a failed process can resume. I keep context as small as the task allows. I only store memory with a clear purpose, retention rule, and deletion path. Saving every conversation forever is not a memory strategy.

Production controls

Before release, I want answers to these questions:

1. What marks the task as complete?
2. What is the maximum number of steps, tool calls, tokens, and elapsed time?
3. Which actions require approval?
4. Can the process be retried without repeating a harmful action?
5. Can I replay a failed run from its trace?
6. What happens when a dependency is unavailable?
7. Which evaluation set must pass before a change ships?

I log model calls, tool inputs and outputs with sensitive fields removed, routing decisions, approvals, latency, and cost. A final answer alone is not enough to debug an agent.

Frameworks and platforms

In 2026, Microsoft Agent Framework provides code-first agents and graph-based workflows across .NET and Python, with integrations for Microsoft Foundry and other model providers. Foundry Agent Service adds managed hosting, identity, observability, and related platform services.

Those tools can reduce infrastructure work, but they do not decide the architecture. The same design rules apply if I use another framework or build the loop directly with a model SDK.

I keep domain tools and business rules in ordinary application code. Framework-specific orchestration stays at the edge. That makes it easier to test the important logic and change the agent runtime later.

A sensible first release

I start with one narrow outcome, one agent or workflow, and a small set of read-only tools. I collect real examples, trace failures, and add a human approval step before any meaningful write.

Only after that works do I consider more tools, memory, or specialised agents. Complexity should answer a measured failure, not anticipate one.

References

• Microsoft Agent Framework
• Microsoft Agent Framework overview
• Foundry Agent Service