An AI agent becomes useful when it can do more than produce text. It reads information, chooses a next step, uses a tool and evaluates the result. The same capability creates the largest operational risk: an inaccurate answer is visible, while an incorrect tool action can change data, contact a customer or trigger a security test.
Production readiness is therefore a systems question, not a model ranking. The model is one component inside a workflow with permissions, state, budgets, tests and responsible human decisions.
Define the task before selecting a model
“Research this matter” is not a testable task. A useful definition names the permitted sources, expected output, relevant deadline, required citations and the conditions under which the agent must stop.
The first version should cover one narrow, valuable workflow. The team then collects representative successful cases, difficult edge cases and requests the system must reject. These cases become the initial evaluation set. Without them, model comparisons are impressions rather than evidence.
Model the workflow as explicit states
A chat history is not an operating model. A dependable agent has named states such as received, classified, awaiting data, planned, approved, executing, evaluating and completed. Each transition has conditions and a stored result.
Explicit state makes interruption and recovery possible. If a tool times out, the system can resume from the last valid state instead of repeating all actions. It also becomes possible to answer basic audit questions: which model proposed the action, which data was available, which tool was called and who approved it?
Treat every tool as a strict contract
A tool should expose one understandable operation with validated input and a predictable response. A generic execute-command tool gives the agent too much freedom. A purpose-built search-case-law or create-draft tool can restrict queries, data and side effects.
The contract needs schema validation, timeouts, output limits and explicit error states. Returned content is untrusted input. A website, document or tool result may contain instructions that conflict with the actual task. The model must not gain more authority simply because text inside a source asks it to.
Apply least privilege to agents
An agent should receive only the data and tools required for the current task. Read and write operations are separated. Tenant, user and project context must be enforced by the application around the model, not inferred by the model itself.
Temporary credentials, narrow scopes and isolated execution reduce the impact of a bad decision. For security work, tools run inside controlled environments with an authorised target list. For business workflows, write actions can produce a proposed change that requires approval instead of modifying production data directly.
Put technical limits on time, cost and repetition
Prompts cannot reliably prevent loops. The orchestration layer needs hard budgets for tool calls, tokens, retries, wall-clock time and spend. It also needs a global stop mechanism.
The user should receive a controlled result when a limit is reached: what was completed, what failed and whether the run can be resumed. Silent repetition is both expensive and difficult to investigate.
Evaluate the whole system
A general benchmark says little about a specific workflow. Production evaluation executes the complete chain with representative tasks: retrieval, model, tool permissions, approvals and final output.
Useful measurements include:
- professional task success
- correct and complete source grounding
- unnecessary or forbidden tool calls
- compliance with roles and approvals
- error rate and controlled termination
- latency and cost per successful task
For RAG, an answer that merely sounds correct is not enough. It must use the right source, show uncertainty and refrain from inventing material when evidence is missing. For an agent, the route to the answer must also be permitted.
Place humans at expensive boundaries
Human approval after every step removes the value of automation. Approval belongs at points with high impact or poor reversibility, including external communication, legal decisions, changes to production data, deployments and active security testing.
The interface must show the information and intermediate steps behind the proposed action. A confirm button without context is not meaningful control.
Use local models for data control
Local inference prevents confidential code, legal documents or vulnerability data from being sent to an external model provider for inference. It solves an important data-control problem, but it does not guarantee quality.
Model size, quantisation, context, retrieval and tool design all affect results. Real tasks must show which model meets the required quality within memory, latency and cost limits. Hybrid workflows can keep sensitive content local while using frontier models for non-sensitive development or documentation. The decisive requirement is a binding data classification for each step.
Production checklist
- The task and success criteria are professionally defined.
- State, resume and termination behaviour are implemented.
- Tools use validated contracts and minimal permissions.
- Irreversible actions require appropriate approval.
- Time, token, cost and retry budgets are technically enforced.
- Success, failure and abuse cases run automatically.
- Model, prompt, retrieval and tool versions are traceable.
- Logs support diagnosis without collecting unnecessary sensitive data.
- Local and external calls follow a documented data rule.
- A responsible person can stop and evaluate every run.
Conclusion
An agent is production-ready when its behaviour remains predictable with missing information, failed tools and prohibited tasks. No frontier model removes this systems work. A smaller model with clear tools, strong evals and controlled state is often more valuable than an impressive demo with broad permissions.