The Smallest Useful Agent: Model, Tools, and Instructions
The architecture of an AI agent begins with a boundary question: what should the system decide, what should it merely retrieve or present, and what must remain an explicit operation outside the model? This part of the series focuses on the smallest useful agent—one built from a model, tools, and instructions—and gives the reader a way to map those responsibilities to an ambiguous workflow. The aim is not to assemble the longest tool catalogue. It is to make every interface explainable in terms of reliability, consequence, and evidence.
The distinction matters because a model can be capable without being appropriately placed in control. A language model may interpret a request, but an agent has to do something with that interpretation. It may need to look up an account, compare a policy, draft a response, update a record, or hand a case to a specialist. Each action crosses a boundary. The architecture is sound only when those boundaries are explicit enough to evaluate and constrained enough to govern.
First decide whether the workflow needs an agent
An agent is justified when the uncertainty in a workflow affects the outcome and cannot be handled economically by fixed rules alone. The supplied guidance identifies three recurring conditions: nuanced judgment or exceptions, rules that have become difficult to maintain, and heavy reliance on natural language or unstructured information. These are selection criteria, not a guarantee of better performance. They tell a team where to investigate, not what to deploy automatically.
Consider a customer-support escalation. A deterministic workflow can route a message when it contains a known product term or matches a defined category. That remains useful for routine requests. But an escalation may require the system to understand the customer's actual problem, inspect account history, consult a knowledge base, draft a response, and decide whether a specialist should take over. The path depends on what the message says, what the records contain, and whether the available remedy fits the situation. A language model can help interpret that combination, but the workflow does not become safe simply because the interpretation sounds plausible.
The first design decision is therefore narrower than “where can the organization use AI?” Ask which part of the workflow contains the uncertainty, and which parts are already stable. A system might use ordinary software to authenticate a customer and fetch a record, an agent to interpret an unusual request, and a fixed policy check before any account-changing action. The agent does not need authority over the entire process. In fact, limiting it to the judgment boundary may make the system easier to test and safer to operate.
The opposite case is equally important. If a task is simple, stable, and fully expressible as deterministic rules, an agent may add cost, latency, and unpredictable behavior without proportional value. A long sequence of known transformations is not automatically an agent problem. Nor is a short workflow automatically simple: a brief decision can still be high-stakes if it changes money, access, or a customer's case. Complexity and consequence should be assessed separately. The useful question is whether flexible interpretation earns its place at the point where the workflow can no longer be specified reliably in advance.
Three responsibilities and their interfaces
Once the use case is bounded, the minimal architecture has three core responsibilities. The model reasons about the current state and selects a next step. Tools expose data or actions in external systems. Instructions define the role, operating rules, and boundaries within which the model should act. The two supplied guides describe these components at different levels: one presents model, tools, and instructions as the core; the other also emphasizes integrations and specialized Skills as ways to extend the core. That is a difference in emphasis, not a reason to treat a Skill or integration as a replacement for the underlying boundaries.
The model is the reasoning component, not the owner of every decision in the surrounding system. It can interpret a request, compare possible next steps, and select among available tools. The model may also recognize that the task is complete or that it cannot proceed. But the model should not be treated as the only place where authority lives. Authentication, authorization, access control, and the actual implementation of a state change remain external concerns. A model can request an action; an explicit interface and the surrounding security controls determine whether that request is permitted.
This separation also makes evaluation more meaningful. If an agent fails, a team can ask whether the model misunderstood the request, whether a data tool returned incomplete context, whether an action tool exposed too much authority, or whether instructions failed to cover an edge case. A single opaque prompt hides those causes. Distinct interfaces do not eliminate failure, but they give the system places where failure can be observed and corrected.
Data, action, and orchestration tools
The practical tool taxonomy is simple but consequential. Data tools retrieve context: they may query a transaction database or customer relationship system, read documents, or search the web. Action tools change a system or communicate with another party: they may update a record, send a message, or hand a support ticket to a human. Orchestration tools allow one agent to invoke another agent for a specialized task.
The categories differ in consequence, not merely in function names. A data lookup can still expose sensitive information, but it is usually reversible in a way that a payment or account update is not. An action tool may create an external commitment that cannot be undone cleanly. An orchestration tool can transfer responsibility and context, making the boundary between agents part of the workflow's control model. The supplied guidance recommends rating tools by factors such as read or write access, reversibility, required permissions, and financial impact. Those factors should influence whether the call is automatic, checked, or held for review.
Tools also need to be reusable and understandable. Standardized definitions, clear parameters, documentation, and testing help an agent discover the right interface and help a team version it without silently changing the whole system. The important relationship is many-to-many: one tool may be useful to several agents, and one agent may use several tools. That flexibility is valuable only when tool descriptions make the distinctions visible. Ten overlapping tools can be harder to select safely than a larger set of clearly different tools.
A data tool should return enough context for the next decision without overwhelming it. An action tool should expose what it will change and, where relevant, the result or confirmation of that change. An orchestration tool should make the delegated responsibility clear. These are not cosmetic documentation choices. They shape what the model can distinguish, what the operator can audit, and how a failed call can be retried or stopped.
Instructions as an operating routine
Instructions convert general model ability into a bounded routine. A broad role description such as “help the customer” leaves too many decisions implicit. More reliable instructions can be derived from an existing operating procedure, support script, policy document, or knowledge-base article and rewritten as clear directions for the agent.
The key is to turn each step into an action or an explicit output. The agent may need to ask for a missing order number, retrieve account details, compare a request with a policy, draft a response, or hand the case to a person. It also needs branches: what happens if the required information is missing, the tool returns no record, two sources disagree, or the user asks for something outside the agent's scope? Naming the branch is more useful than assuming the model will infer it from a general instruction.
Instructions should also specify what not to do. A customer-support agent might be allowed to explain a policy and prepare an escalation but not to authorize a high-value refund. A data-analysis agent might retrieve a result but be required to state when the available data cannot support a conclusion. Boundaries of refusal and handback are part of the routine because they tell the model when persistence is no longer helpful.
Prompt templates can support several related contexts without duplicating an entire workflow. Policy variables may change the customer's tenure, complaint categories, or operating constraints while preserving the same basic routine. This is a form of modularity: the behavior can adapt without turning every new case into a new agent. It does not remove the need to review the underlying policy. If the source procedure is ambiguous or contradictory, generating a clearer prompt only makes the ambiguity easier to execute.
Specialized Skills can extend a single agent with domain knowledge, workflows, or tool integrations without encoding every capability in one monolithic instruction. The useful architectural idea is composition: a financial-analysis capability and a customer-support capability can be maintained separately, and a more complex capability can invoke another when needed. The boundary still matters. A Skill should add a defined capability, not become an unexplained second control plane.
Model choice must be tested, not assumed
Different tasks need different balances of reasoning capability, speed, and cost. The supplied guidance recommends establishing a performance baseline with the most capable available model, then testing smaller or faster models against explicit evaluations. A simple retrieval or intent-classification step may meet its target with a lighter model; a difficult approval or multi-agent coordination decision may require more capability. The recommendation is not to use the strongest model forever. It is to avoid shrinking capability before the team knows what the task actually requires.
An evaluation baseline should measure the outcome that matters at the workflow boundary. For support escalation, that may include correct routing, useful responses, appropriate handback, and the rate of actions that require correction. For a data task, it may include whether the right sources were consulted and whether unsupported conclusions were avoided. Latency and cost belong beside quality because a design that is accurate but too slow or expensive may fail operationally. The guides do not supply a universal accuracy threshold; that threshold must come from the use case and its consequences.
The baseline also protects against a common category error. If a smaller model performs poorly, the problem may be insufficient reasoning capability—but it may instead be a confusing tool interface, a missing branch in the instructions, or an evaluation that rewards fluent answers rather than correct workflow outcomes. Testing the whole boundary is more informative than swapping models in isolation. Model selection is an allocation decision supported by evidence, not a ranking exercise.
A support escalation viewed as a system
Return to the support example. The model interprets the customer's request and decides whether it needs account history, a knowledge-base lookup, or a direct response. The data tools retrieve the relevant context. Instructions specify what information is required, which routine cases can be resolved, and when incomplete or unusual information requires handback. An action tool may update the ticket or route it to a specialist, but that state change remains an explicit operation with its own permission and risk.
Evaluation can then ask several separate questions. Did the model identify the customer's actual intent? Did it select the appropriate data source? Did the response follow the support policy? Did the system avoid acting when the evidence was incomplete? Did the handoff preserve enough context for the receiving person or agent? A high-quality final message answers only one part of this set. The architecture earns confidence when each boundary has a test and when a failure reveals which responsibility needs repair.
This is why the smallest useful agent is not the smallest possible prompt. It is the smallest complete arrangement of reasoning, interfaces, instructions, and measurement that can perform the intended workflow within its authority. Once that arrangement is visible, the next question is temporal: how does the system use these components repeatedly, incorporate tool results, and know when to continue or stop?