What should an AI agent take with it into a task?
An agent should take only what the task actually needs: the accounts it must act inside, the skills the work calls for, any extra abilities that are explicitly required, and helper agents only when the task has a clear boundary. Everything else stays behind. The point is not to build a maximally capable traveller; it is to make the run inspectable and reversible.
What should an agent carry into a task by default?
An agent should start with the narrowest useful context. If a task is to draft a reply, it needs the draft and the thread, not the whole inbox. If a task is to update a sheet, it needs that sheet and the relevant rows, not every file the workspace can see.
The default question is not what the agent might do, but what it cannot do without. Anything that is not needed for the stated outcome should not be loaded, because every extra credential, tool or memory is something a mistake can reach.
| Item | Carry when | Leave behind by default | Why it matters |
|---|---|---|---|
| Email account | the task must read or send mail | all other tasks | reduces the messages a mistake can touch |
| Payment method | a payment is the explicit task | everything else | money movement should be opt-in |
| Document store | the task edits or reads a specific folder | otherwise | limits exposure to unrelated files |
| Helper agent | the task has a clear handoff boundary | otherwise | avoids chains of unsupervised work |
Which connected accounts should travel, and which should stay at home?
Connected accounts are the highest-risk cargo because they let an agent act as you. The useful rule is to attach an account only when the task description names an action in that account. Reading a calendar does not require the ability to send invitations. Posting a draft does not require the ability to delete posts.
A payment method should stay home unless the task is itself a payment. If money can move, the default should be off. When a payment is genuinely required, the instruction should state the recipient, the amount, and the condition for release, not merely ask the agent to handle it.
- Least privilege
- give the agent only the permissions this task requires, no more
- Reversibility
- prefer actions you can undo, and avoid actions that settle instantly
- Blast radius
- the set of things a bad step could touch; keep it small
- Audit surface
- the record of what the agent saw and did; a smaller surface is easier to review
How do skills and extra abilities change what the agent can touch?
A skill is not neutral. It extends the agent's reach, sometimes far beyond the original request. A skill that can run shell commands, edit files or call external services turns a writing task into a system task. The skill should be loaded because the task needs it, not because it is available.
Extra abilities multiply in the same way. If the agent can deploy an application, it can also alter what is already running. If it can post on your behalf, it can also affect an audience. The practical test is to ask what the ability would allow if every instruction after this point were wrong.
- Ask whether the skill is needed for the stated outcome.
- Prefer skills with a clear input and output over open-ended automation.
- Treat skills that move data out of the workspace as high-risk cargo.
When should helper agents be allowed to follow it in?
A helper agent should be invited only when the parent can state what done looks like. That means a single, verifiable objective, not an open-ended mandate. If the parent cannot describe the acceptance condition, the helper should not be part of the run.
If one agent can hire another, the hired helper should be paid only when the work is accepted, and the money should be held until then. That creates a reason to finish and a way to get money back if the work fails. A helper that acts before any of this is clear is not a helper; it is a risk you are carrying without knowing the cost.
What should you be able to see before the run starts?
Before an agent takes a step, you should be able to see the list of tools, accounts and helpers it will carry, and the price of any model or service it will call. If a run can spend credits, the cost of each choice should be visible before the choice is made, not discovered afterwards.
The same applies to helpers. A hired helper should show what it will do, what it will be paid, and what happens if it fails. If that information is not visible, the sensible default is to refuse the run. Visibility before the run is cheaper than recovery after it.
Common questions
Why should an agent carry fewer tools rather than more?
Fewer tools mean a smaller blast radius. Every extra credential, account or skill is something a mistake can reach, and the more an agent can do, the harder it is to review what it did. Carrying only what the task needs keeps the run inspectable, reversible and easier to stop when something looks wrong.
What is the first thing to leave out of an agent run?
Anything that can move money should be left out by default. A payment method, a trading account or a wallet should only travel when the task is itself a payment or a trade, and even then the instruction should state the recipient, the amount and the condition for release.
How do I decide whether a helper agent should be included?
Include a helper only when you can state what done looks like as a single, verifiable objective. The helper should be paid on completion, with money held until the work is accepted and refunded if it fails. If you cannot describe the acceptance condition, leave the helper out.
What should be visible before an agent starts a task?
You should see the tools, accounts and helpers the agent will carry, and the cost of any model or service it will call. If a helper is involved, its task, payment and failure terms should be visible too. If those details are not clear before the run, the safer choice is not to start.
Choose what travels with your agent and what stays behind, and make the run visible before it begins.