AI agents are becoming easier to deploy and harder to supervise.
Giving an agent a broad goal, a collection of tools and permission to keep working can feel like leverage. It can also create a new management burden: duplicated effort, silent scope drift, unnecessary model spend, weak handoffs and actions that are difficult to reverse.
The practical question is no longer simply, “What can this agent do?” It is, “How do I make its work dependable enough to use repeatedly?”
The answer is to stop treating an agent like a magic employee and start treating it like a junior operator inside a well-designed control system. The model supplies reasoning and flexibility. You supply the job definition, boundaries, evidence standards and escalation rules.
That approach can turn occasional AI assistance into durable time leverage without pretending that autonomy removes human responsibility.
Begin with a job card, not a personality
Many agent instructions focus on tone or role: “You are an expert researcher” or “Act as my operations manager.” Those descriptions may influence style, but they do not define a manageable job.
A useful job card should answer six questions:
- Outcome: What observable result must exist when the work is complete?
- Inputs: Which files, systems and sources may the agent use?
- Boundaries: What must it avoid changing, sharing or assuming?
- Evidence: What proves the result is correct?
- Escalation: Which decisions require a human?
- Stop condition: When should the agent finish, pause or abandon the attempt?
For example, “manage my newsletter” is too broad. A safer job is: “Draft one newsletter from the approved research folder, preserve existing links, flag unsupported claims, and stop at a preview for editorial approval.”
The second version is not less ambitious. It is more reusable because success and failure are visible.
Choose the least autonomous pattern that works
Not every task needs a free-roaming agent. Anthropic distinguishes between workflows, where tools and model calls follow defined paths, and agents, where the model directs more of its own process. Its guidance recommends beginning with the simplest approach that can do the job because additional autonomy often increases cost and latency as well as flexibility.
Use a fixed workflow when the stages are known: collect inputs, transform them, validate the output and request approval. Use a more autonomous agent when the route cannot be predicted in advance, such as investigating an unfamiliar failure across several systems.
A useful autonomy ladder is:
- Level 1 — advise: the agent recommends an action but changes nothing.
- Level 2 — prepare: it creates drafts, plans or proposed changes in a recoverable space.
- Level 3 — act with approval: it can execute a consequential step only after a human checks the exact candidate.
- Level 4 — act within limits: it can complete reversible, low-risk actions inside a defined budget and scope.
Move a job up the ladder only after lower levels produce reliable evidence. Autonomy should be earned by a task, not granted permanently to a model.
Give each agent the minimum tools and context
An agent’s behaviour depends on more than the model. Its instructions, tools and working environment shape what it can see and do. A powerful model with an over-permissive tool can still create an avoidable failure.
Apply least privilege in practical terms:
- give a research agent read access, not publishing access;
- separate production credentials from testing credentials;
- restrict each agent to the folders, accounts and actions required for its job;
- keep deletion, payment, publication and external messaging behind explicit approval; and
- treat webpages, emails and retrieved documents as untrusted inputs rather than instructions.
OWASP recommends validating tool calls against user permissions, restricting tools to the minimum access required and requiring human approval for high-impact actions. These controls also limit the damage from prompt injection, where hostile instructions hidden in external content try to redirect the agent.
Context needs similar discipline. More information is not always better. Long histories, stale plans and irrelevant files consume attention and can introduce contradictory instructions. Give the agent a small set of authoritative inputs, let it retrieve supporting material when needed, and maintain a short progress record for long-running work.
Install checkpoints where the risk changes
Reviewing every minor step destroys the time savings that agents promise. Reviewing nothing transfers too much judgment to a system that can misunderstand intent.
Place checkpoints at risk boundaries instead:
- before an external message is sent;
- before money is committed;
- before production data or public content changes;
- when the agent wants to expand its original scope;
- after conflicting evidence appears; and
- when a retry could create a duplicate.
The approval should show the exact proposed action, destination and material effects. “Ready to proceed?” is weak if the reviewer cannot see what will be sent or changed.
For recoverable internal work, the agent can usually proceed and report afterwards. For consequential work, it should pause with a preview. This preserves human control without turning the human into a full-time observer.
Manage the portfolio with an agent register
Once you use more than one agent, keep a simple register. A spreadsheet or small database is enough.
Track:
- agent or workflow name;
- owner;
- job and trigger;
- tools and permissions;
- source of truth;
- approval gates;
- cost or run limit;
- expected completion evidence;
- last reviewed date; and
- recent failure or intervention rate.
This reveals duplication quickly. If three agents independently research the same topic, maintain separate memories and publish through different paths, the apparent leverage may be fragile complexity.
The register also creates an offboarding mechanism. When a tool, model or business process changes, you can identify which workflows depend on it and disable them deliberately rather than discovering the dependency after a failure.
Evaluate completed work, not confident language
Agents can produce persuasive status messages even when the real task is incomplete. A claim such as “published successfully” is weaker than a public URL, a matching database record or a test against the actual output.
Define evidence before the run. Depending on the job, completion might require:
- a document that passes a factual checklist;
- a calculation reproduced from source data;
- a deployment followed by a successful live-route check;
- a message visible at the intended destination; or
- a changed file plus passing tests and a reviewable difference.
Keep the trace needed to diagnose important failures: the initial request, tool calls, approvals, material outputs and final verification. Anthropic’s guidance on agent evaluations emphasises that multi-turn agents must be tested across the full trajectory, not judged only by the final answer. NIST similarly frames AI risk management as a continuous lifecycle involving governance, mapping, measurement and management.
Start with a small evaluation set drawn from real work. Include ordinary tasks, ambiguous requests, missing inputs, hostile external content and tool failures. Review where the agent needed intervention, not only whether the happy path worked.
Put hard limits around retries, time and spend
An agent loop can continue consuming tokens and calling paid services while making little progress. Every managed job needs a budget.
Set limits for:
- maximum runtime or number of turns;
- model and tool spend;
- number of retries;
- volume of records, messages or files processed; and
- acceptable error rate before pausing.
Retries should respond to evidence. If an upload times out, first check whether it actually succeeded. Blind repetition can create duplicate posts, charges or records. If the same blocker recurs, the agent should stop with a concise account of what happened, what it verified and what decision is needed.
Cost should be compared with the value of the completed job, not the novelty of the technology. A more expensive model may be justified for a high-value analysis. A deterministic script may be better for a stable repetitive transformation. A person may remain the right choice for rare, sensitive decisions.
Run a weekly agent review
A lightweight weekly review keeps the system from decaying. For each active agent, ask:
- Did it complete a useful job this week?
- What evidence confirms that outcome?
- Where did a human intervene?
- Did its permissions or scope exceed what it needed?
- What did the run cost in money and attention?
- Should the workflow be simplified, retrained, restricted or retired?
Do not optimise only for fewer human touches. Some approvals are valuable controls. The better measure is whether human attention is concentrated on judgment while repetitive execution becomes dependable.
The real wealth machine is the management system
An AI agent creates leverage only when its output can be trusted, checked and repeated. Otherwise, it merely shifts work from execution to supervision and cleanup.
Start with one recurring job. Write its job card, limit its tools, require evidence, add one approval gate at the highest-risk boundary and review its performance for several runs. Expand autonomy only when the record supports it.
The goal is not to remove people from the loop. It is to design a better loop—one where AI handles repeatable effort and people retain responsibility for direction, judgment and consequential decisions.
Sources
- Anthropic: Building effective agents
- Anthropic: Effective context engineering for AI agents
- Anthropic: Demystifying evals for AI agents
- Anthropic: Trustworthy agents in practice
- NIST: AI Risk Management Framework Core
- OWASP: LLM Prompt Injection Prevention Cheat Sheet
Information date: 12 August 2026. This article provides general educational information. Product capabilities and security guidance may change; verify current documentation before deploying an agent.
