An AI agent in production is a chain of systems. The model decides what to do next, but other layers provide the data, credentials and software needed to carry out that decision.
This distinction matters because the model is rarely the part that owns the customer record, sends the email or changes a deployment. Those consequences come from the services connected around it. For the operating decision, use the separate guide to choose an AI agent’s permissions.
The model chooses a next step
The language model interprets the request and produces a response or proposed action. It may also decide which available tool to call. A stronger model can improve planning and reduce some errors, but it does not remove the limits or permissions of the connected systems.
Changing the model can alter how the agent reasons. Changing its tools can alter what the agent is capable of doing to the business.
Tools turn an answer into an action
A tool can be a narrow function such as retrieving an invoice or a broad connection to email, source control or a customer database. Tool descriptions tell the model what is available; the application decides which tools are exposed and how calls are validated.
The Model Context Protocol specification formalises one way for AI applications to connect with external data and tools. Its client-host-server design is useful because it makes the connection layer visible. It does not make every connected tool safe by default.
Identity determines the blast radius
Every useful connection eventually resolves to an account, token or service identity. That identity decides which organisation, project and records the agent can reach.
An agent using an owner-level credential may inherit far more authority than its task requires. A read-only analytics role and a production administrator can call the same service while presenting entirely different risks. The identity layer therefore needs its own design, separate from the prompt.
State gives the agent continuity
State includes the current task, earlier messages, stored preferences and records retrieved during a run. Long-term memory is one form of state, but ordinary application data matters just as much.
The difficult questions are practical: which information survives the session, who can correct it, when it expires and whether one customer’s context can appear in another customer’s work. A fluent answer does not prove that the underlying state is current or correctly scoped.
Approvals decide when work becomes real
Some systems ask a person to approve an action. Others let the agent execute immediately. Approval is part of the product architecture because it determines where responsibility moves from software to a named operator.
The useful approval screen shows the proposed action, its target and the evidence behind it. A generic confirmation button placed after the important details have been hidden provides little protection.
Logs make the chain inspectable
When an agent behaves unexpectedly, the operator needs to reconstruct the run: the request, model decision, tool call, returned data, approval and final result. OpenTelemetry provides common ways to collect traces, metrics and logs across distributed software, although an agent still needs application-specific records explaining its decisions and actions.
The practical unit to evaluate is the whole chain. A capable model attached to excessive permissions and weak records is a fragile system. A modest model with narrow tools, clear approvals and useful logs may be the one an operator can actually trust. The strategic consequence is examined in why agent platforms are becoming permission systems.