Automate a bounded job, not a vague ambition
“Handle my inbox” is not a safe agent brief. “Draft replies to shipping-status questions using this approved knowledge base, without sending them” is easier to test. A good first task has clear inputs, a limited tool set, an expected output and an obvious stopping point. It should also be reversible if the agent makes a poor choice.
🐰 I start with work that is repetitive but easy for a person to inspect: classifying requests, preparing a comparison table, extracting fields from a known document type or drafting a weekly summary. Payroll changes, hiring decisions, refunds, account deletion and public statements are different because a plausible mistake can affect money, rights or reputation.
Write a small test set before connecting the agent to real work. Include a normal request, missing information, contradictory instructions and a request that should be refused or escalated. Decide the expected behaviour in advance. Otherwise a smooth demo can quietly become the definition of success after the fact.
Give the agent the smallest useful keyring
An agent connected to email, files, a browser and payment systems does not merely generate text—it can act. Use separate service accounts where possible, restrict folders and records, prefer read-only access, and issue temporary credentials instead of permanent broad permissions. Never place secrets inside prompts or documents the agent must interpret.
Untrusted material can contain instructions aimed at the agent rather than the employee. The prompt-injection demo in this collection makes the risk visible: a résumé or webpage can look ordinary to a person while trying to redirect a tool-enabled system. Treat external content as data, not authority, and prevent it from silently changing the agent’s objective.
Tool limits should exist outside the prompt. A sentence telling an agent “never send money” is weaker than an account that simply cannot make payments. Add rate limits, allowlists and maximum transaction sizes where tools support them. A high-risk request should fail closed and create a review item instead of improvising another path.
Put human approval before the consequence
Approval is most useful before an irreversible action, not after a morning report. The reviewer needs the proposed action, source material, affected records and a clear description of what will happen after clicking. A vague “Approve” button encourages rubber-stamping.
The NIST AI Risk Management Framework emphasises governance, defined human roles, testing, evaluation, verification and validation. In practice, that means assigning an owner, documenting the intended use, recording failures and specifying when a person must take over. Human oversight is a designed responsibility—not a reassuring sentence added at the end of a policy.
Reviewers also need time and authority to say no. If every proposal arrives as urgent, or rejecting it creates more work than accepting it, the approval step becomes theatre. Show uncertainty and source links, require a reason for exceptional actions and route specialised cases to someone who understands the domain rather than the agent platform alone.
Keep evidence that helps the next review 🔍
Log the request, data sources, model or agent version, tools called, proposed action, approval decision and final outcome. Protect those logs like other sensitive business records, with appropriate retention and access controls. A complete trail should help someone reconstruct what happened without exposing every private input to every employee.
Review samples even when nothing appears broken. Track unsupported claims, wrong tool calls, unnecessary escalation and how often reviewers reverse the agent’s suggestion. Expand permissions only after the narrow workflow behaves reliably. The goal is not maximum autonomy; it is a useful division of labour in which the machine handles repeatable steps and a named human remains accountable for the consequence.
Set a review date from the start. Models, connected tools, business rules and attack techniques all change. A workflow that was acceptably bounded at launch may gain a new integration or start handling more sensitive data six months later. Recheck the task, permissions and stop conditions whenever its scope changes.
