‘Here are my files. Here are my logins. Figure it out.’ That is a strange way to onboard a person. For software that can reach into your systems, it is stranger still.
An AI agent (An AI agent carries out several steps of a defined task. A person decides before it sends anything outside your firm or spends money.) is a program that uses a language model (A language model is the actual AI behind an AI assistant: it has learned from a great deal of text and writes an answer to an input.) to plan its own steps and use tools: read files, write drafts, look something up in a spreadsheet. That is useful. But it is not a colleague with judgement and responsibility. It is a tool with permissions, costs and limits. Treat it like one.
Able is not the same as allowed
A capable agent can read documents, suggest changes and explain its steps. That does not mean it should search customer records, trigger payments or email your customers. Four questions belong apart:
- What should it achieve? The result, not the hope.
- What may it see? The details it needs for this task.
- Which tools may it use? Reading is not writing, and writing is not sending.
- Where does it stop? The point where a person decides.
With us, the last question is not up for negotiation: nothing we build sends a message outside your firm or spends money without a person making the final decision. Everything else we agree step by step. More independence is earned, not assumed: first the AI suggests details and your people check them, later it handles clearly defined internal routine cases. The five stages are on the About page.
Context is a budget and a boundary
More context is not automatically better context. Give an agent your whole drive so it can read one delivery note, and you create noise and expose details that have nothing to do with the task. A model’s context window (Context is everything a language model sees for a request; the context window is the amount of text it can process at once.) is limited too: what does not fit, it does not see.
A good work package starts with the result you want, the rules that apply, the files that are really needed, and a description of what ‘done’ looks like. If the agent needs more, it should ask. That also makes its work easier to review: whoever checks it can see what it was meant to do.
The work has to outlive the conversation
The second common mistake: one long chat becomes the only record of a piece of work. Conversations end, computers restart, connections drop. Your business still needs a trail of what ran and what changed.
So keep a record outside the conversation of the task the agent had, the files it worked on, what came out and who approved it. A record sounds boring. It is the difference between supervised work and work you merely hope went well.
Where you do not need an agent
Not every task deserves an agent. If two programs should match the same fields every night, ordinary code that runs the same way each time is enough. If an Excel macro solves it, that is the answer. Use an agent where inputs vary a lot and a rigid set of rules keeps breaking.
The choice of tool stays open too. You choose the AI harness (An AI harness is the workspace on your computer in which AI reads files and carries out agreed steps.), the model and the provider; Claude Code (Claude Code is an AI harness made by Anthropic: it runs on your computer, reads files and carries out steps you describe in plain language.) is one option, not a requirement. What matters is not the logo but the job description.
Worksheet
A job description in five lines
Fill in these five lines before an agent works for you. If a line stays empty, it is not ready yet.
Keep the five lines where you also record what the agent did. That way you can check later whether it stuck to its job.
Good agent design is not about giving the model unlimited freedom. It is about surrounding useful flexibility with limits, so that you can trust the results. A real example where exactly this applies is ‘From inbox to booking: one click, full control’.