AI Agents: Architecture, Tools and Workflows

An AI assistant responds to a request. An AI agent goes further: it interacts with tools, keeps track of a task across several steps, and takes actions inside an environment you define.

The loop is simple to describe and difficult to engineer: a goal, then reasoning, then an action, then an observation of what that action returned, then the next action, until the task is done or the system stops.

What is an AI agent?

An agent is a software system that uses a model to pursue a task through one or more actions. Architectures vary, but an agent typically has access to a language model, a set of tools, application data, some memory or state, instructions that bound its behaviour, external systems, and a way of evaluating whether it succeeded.

The model is the reasoning component. Everything else is ordinary software engineering, and that is where agents are won or lost.

How does an agent differ from a simple AI feature?

A simple feature is a straight line: input, model, output.

An agentic workflow is a loop: goal, model, tool, result, model, tool, result, outcome. The system decides how many times round the loop to go and which tool to reach for each time.

That difference introduces every engineering consideration below. A straight line fails in one place; a loop can fail in a different place each time it runs.

How do tools work?

Tools are what let the system act rather than only answer. They might be interfaces to other services, databases, search systems, calculators, business applications or internal services.

The mechanism matters: the model does not touch your systems. It emits a structured request to call a named tool with specific arguments, and your code decides whether to honour it. That boundary is the only place you can enforce anything, so it is where permission checks, validation and logging belong.

Tool access should be granted narrowly. A tool that only reads is recoverable. A tool that writes, sends, pays or deletes is not.

How is state handled?

Longer workflows need to know what has already happened: conversation state, task state, intermediate results, user preferences, retrieved information.

State management should be deliberate. Assuming the model will simply remember is the most common source of agents that lose the thread halfway through a task, repeat work they have already done, or contradict their own earlier steps.

Where do people fit?

Some actions should wait for a person. The pattern is: the agent prepares the action, a human reviews it, and only then does it execute.

This matters most when an action changes data, communicates outside the organisation, or affects a business process someone is accountable for. The review has to be genuinely possible — a queue nobody has time to read is not oversight, it is a formality.

What does the architecture look like?

A goal enters the system and reaches the model. The model selects a tool and supplies arguments; your code validates and executes it, possibly in parallel across several tools. Results return as observations, the model reasons over them, and the loop continues until it produces a final action or hits a limit you set.

Real systems add more: retries, timeouts, step budgets, fallbacks when a tool is unavailable, and a trace of everything that happened.

1. 01GoalEnters the system and reaches the model.
2. 02ModelSelects a tool and supplies arguments.
3. 03ToolYour code validates and executes it.
4. 04ObservationResults return to the model.
5. 05Final actionProduced when the loop ends.

The model reasons over the observation and the loop continues, until a final action or a limit you set.

What should an engineer consider?

Agentic systems introduce failure modes a single model call does not have:

• Incorrect tool selection — the right action, taken on the wrong thing.
• Incorrect arguments — plausible values that do not match reality.
• Unexpected loops — retrying a failing approach, or oscillating between two. Step limits and timeouts are not optional.
• Incorrect assumptions carried forward, where an early mistake becomes the foundation for every later step.
• Incomplete tasks reported as finished. Verify outcomes against the system, never against the agent's own summary.
• Unsafe actions, especially where the agent reads external content. Anything it reads may contain instructions aimed at it, so treat retrieved text as untrusted input rather than as direction.

Evaluation therefore has to examine the whole workflow, not the quality of any single response. And because the same input can take different paths, evaluate across many runs and accept a distribution rather than a guarantee.

The practical conclusion

An AI agent is best understood as a software system that uses a model to pursue a task through controlled interaction with tools and information. The control is the engineering.

---

Related reading: AI agents explained for the non-technical version, and retrieval-augmented generation for how an agent is given something to reason over.