Intelligent agents need boundaries more than personality

What makes software an agent?

A conventional chatbot produces a response. An agent can also choose and execute actions: search a knowledge base, query a CRM, draft a document, create a ticket or request approval. Most agents follow a loop of observation, reasoning, action and evaluation until the task is complete or a limit is reached. The loop may be implemented with a visual workflow, application code or an agent framework, but the operational concerns remain the same.

Agents are useful where work varies enough to resist rigid rules but still has an objective outcome. Examples include qualifying inbound leads, investigating support cases, reconciling invoice exceptions and preparing research briefs. They are a poor fit for deterministic calculations, irreversible high-risk decisions or processes with badly maintained source data. If ordinary software can solve the problem predictably, use ordinary software.

The six components of a dependable agent

1. Goal: a precise instruction with completion criteria and prohibited actions.
2. Model: selected for the reasoning level, latency and budget of the task.
3. Tools: narrowly scoped functions with typed inputs, permissions and useful error messages.
4. State: the current job, completed steps, evidence and remaining budget.
5. Memory: approved information carried across sessions, subject to retention controls.
6. Evaluator: rules, models or humans that verify quality before consequential action.

Tool descriptions deserve particular attention. An ambiguous tool name or undocumented parameter can cause the model to choose incorrectly. Keep tools atomic, validate every argument server-side and return structured results. The agent should never receive broad database credentials. Use a service account with the minimum permissions required, and require fresh authorisation for sensitive actions.

Single agent versus multiple agents

Multi-agent demonstrations are compelling, but each additional handoff increases latency, token usage and failure modes. Begin with a deterministic workflow surrounding one model. Add a specialist only when evaluation data shows a clear limitation that separation solves. A fixed router based on request type is often more dependable than letting agents negotiate among themselves.

Memory without surveillance

Short-term state tracks the current task. Long-term memory stores information for future sessions. Conflating the two creates privacy and accuracy problems. Save durable facts only when they have a defined business purpose, provenance and expiry. Users should be able to inspect and correct important profile data. Avoid saving speculative model inferences as facts.

Retrieval systems can supply policies, customer records or prior cases as needed. Apply access control before retrieval, not after generation. In a multi-tenant system, test rigorously for cross-customer leakage. Mark untrusted content clearly because documents and web pages can contain prompt-injection instructions designed to manipulate an agent.

Guardrails and approval gates

Guardrails should exist in code, not only in prompts. Set maximum steps, token budgets, timeouts and spending limits. Allowlist domains and tool operations. Validate generated SQL, file paths and recipient addresses. Put irreversible actions—payments, account deletion, public publication or legal commitments—behind explicit human approval. Show reviewers the proposed action, evidence and relevant policy rather than asking for a blind yes or no.

Agents also need graceful failure. When evidence conflicts, a tool is unavailable or confidence is low, the correct behaviour is escalation. Design an exception queue with ownership and service levels. Every run should have a trace containing prompts, model version, retrieved evidence, tool calls, outputs, approvals and errors, with sensitive fields redacted.

Evaluate the whole trajectory

A polished final answer can conceal a dangerous route. Measure task completion, factual quality, correct tool selection, unnecessary actions, policy violations, latency and cost per successful task. Create tests for normal requests, missing data, malicious instructions and third-party outages. Run these evaluations whenever a model, prompt, tool or policy changes.

Agent economics differ from chatbot economics because one request may trigger many model and tool calls. Cap loops and measure successful outcomes rather than cost per token. During rollout, operate in observation mode, then recommendation mode, then limited execution. Expand authority only after the system demonstrates stable performance over meaningful volume.