Chris M. / 17 August 2026 / Reviewed 17 August 2026

Agents, Tools and Orchestration

This is part five of the AI and Software Architecture Translation Guide, the six part series on how modern AI systems are actually assembled. Parts one to four, most recently how a system finds the right record and cites it, covered what a task needs, which model tier it should reach, how a system waits, and how it finds and cites the right record. This part covers what happens once a task needs to act, not just answer, and how the pieces around a model fit into a single system.

Three terms, kept separate

An agent is an AI driven workflow that can decide which steps or tools to use while pursuing a goal, a definition close to Anthropic's own framing of the term. A tool is a defined capability: searching a database, reading a file, calling an API, creating a record. MCP, the Model Context Protocol, is a standard way for AI applications to discover and invoke the capabilities a server chooses to expose.

The single most important correction to make here: MCP does not grant access. It is a protocol for asking. The server, the permissions and the host application determine what the model is actually allowed to see or do. A protocol that standardises the request is not the same as a protocol that grants the request.

The model is the person making decisions. Tools are the plant, registers and communication channels available to them. MCP is closer to a standard radio protocol that lets compatible systems understand how to request those capabilities. Everybody on site speaks the same protocol. That does not mean everybody can operate the crane. Authorisation is a separate matter from communication, and it always was.

That list of published tools is a design decision made by people, not by the model. An AI coding agent could, in principle, use an authorised workflow automation integration to inspect the available tools, create or amend a workflow definition, and test it. Whether it can actually deploy that workflow depends entirely on the tools and permissions the server exposes, and that is a question for whoever configured the server, worth having in writing rather than assumed.

A specification note. The Model Context Protocol changed significantly on 28 July 2026: a stateless core, an extensions framework, and authorisation hardening aligned more closely with OAuth and OpenID Connect deployments. The change is not backward compatible in either direction, so servers and clients need to share a supported specification era. If a supplier tells you they support MCP, ask which specification date they mean.

Where the risk actually sits is not in reading. It is in writing. An agent that can read your project record is a research tool. An agent that can write to your register, send messages or alter a business system is an operational one, and it needs the same treatment you would give any other person or system with those rights: scoped credentials, an audit trail, and a human approval gate on anything consequential.

How the pieces fit together end to end

Intelligence is one package within a wider system. Interfaces, responsibilities, permissions, records and approval points matter just as much as the model itself, and that surrounding structure is where most of the engineering effort actually goes.

This is the digital equivalent of a project execution plan. Nobody builds a project by hiring the cleverest engineer and hoping. You define the sequence, the interfaces, the responsibilities, the hold points and the records, and the same discipline produces the same result here. Layers seven and eight are the two that get cut when a project is behind schedule. They are also the two that determine whether the output can actually be relied upon. Cutting them does not save time. It moves the cost to the point where something is challenged.

Cost accumulates at layer four: send everything to the strongest model and the bill becomes indefensible before the value does, which is why routing is the single largest cost lever in the whole stack. Risk accumulates at layers five and six: if the record is incomplete or permissions are applied late, every layer above produces confident answers built on a partial picture. Value accumulates at layers seven and eight: approvals and override records are what turn a useful tool into a business record you can rely on when it is tested.

Most failures in practice are not model failures. They are layer failures, and they show up in predictable places: a capture route that asks people to change how they work, so adoption stalls; permissions applied inconsistently at the application layer, so someone sees a commercial position they should not have; no defined behaviour when an orchestrator step fails, so records disappear silently until an audit finds the gap; everything routed to one model regardless of task, so either the bill is indefensible or the reasoning is too thin; free text with no controlled fields, so you can search the data but cannot report on it or price it; large parts of the record never indexed, so retrieval builds confident answers on a partial picture; approval reduced to a single tick box with no evidence shown, which is approval without meaningful human involvement; and outputs retained without their inputs or versions, so you can show what was decided but not why.

Using the stack as a procurement checklist. Ask a supplier to walk you down all eight layers and name the technology, the owner and the failure behaviour at each one. Either you get a coherent architecture, or you find out that layers six, seven and eight do not exist and the product is a chat window pointed at your files. The second outcome is common and not always dishonest: it is often a good demonstration that has not yet been engineered into a controlled business process. The difference between putting a chatbot on construction data and engineering a controlled AI enabled business process is layers five through eight, and that is where the real cost of building this properly sits.

Next: a routing matrix for construction work, a worked example, and where to actually start building this, the final part in this series.