What you will learn How agents differ from tool use, why autonomy cuts both ways, and how to decide how much to hand over.
Tool use in the previous chapter had this flow:
A person asks once and gets one answer. An agent is different.
It takes a goal and repeats on its own until it is done.
HyperTeamsgraph TD
A["Receive a goal"] --> B["Decide what to do now"]
B --> C["Run a tool"]
C --> D["Check the result"]
D -->|"goal not met"| B
D -->|"done"| E["Report the final result"]Within a single request this loop can turn dozens of times.
Take the request "summarise how last month's revenue did against target."
Nobody directed each step. Turn 3's "I should look at why" was its own judgement. That is what "autonomous" means.
| Upside | Downside |
|---|---|
| A person need not attend every step | it goes just as hard in the wrong direction |
| It finds paths you did not expect | it also causes incidents you did not expect |
| You can hand over long-running work | long-running also means more cost |
An agent goes just as hard in the wrong direction.
Give it the wrong goal and it will take dozens of steps towards that wrong goal. Tool use wrong once is wrong once; an agent keeps building on a false premise.
So the human's job moves earlier.
| What the human does | |
|---|---|
| Tool use | asks each turn and looks at the answer |
| Agent | states the goal precisely and sets the stopping points |
In practice you set autonomy in levels. HyperTeams uses a representative split.
| Level | Behaviour | When |
|---|---|---|
| Plan only | shows how it would do it, does not execute | first handover, risky work |
| Partly automatic | proceeds with reversible things, confirms the rest | a sensible working default |
| Fully automatic | runs to the end without stopping | verified, repeated work |
Run it a few times on "plan only" first. Seeing what it intends and then widening beats opening it wide and cleaning up afterwards.
An autonomous loop may not stop on its own. So you bound it from outside.
The last matters most. Put a human in front of anything irreversible — as we saw in tool use, the system does the executing, so approval can be inserted in between.
No. It is overkill for simple work. Using an agent where one lookup would do only adds cost and time. Use it for work with several steps and judgement in the middle.
The front end gets harder. Instead of watching and correcting each turn, you have to state the goal precisely at the start. Give it vaguely and it goes dozens of steps in a vague direction. The next chapters are about stating it precisely.
1. What is the core difference between tool use and an agent?
Repetition. Tool use calls once and stops; an agent takes a goal and repeats, judging for itself, until it is complete. So a person does not direct each step.
2. What does "an agent goes just as hard in the wrong direction" mean in practice?
Give it the wrong goal and it stacks dozens of steps on a false premise. Tool use wrong once is wrong once; an agent accumulates. So the human's job moves forward, from "check each turn" to "state the goal precisely and set the stopping points."
3. What four limits should be imposed on an autonomous loop from outside?
Maximum turns, maximum cost, maximum time, and actions requiring human approval. The last matters most — put a human in front of anything irreversible.
What "stating the goal precisely" means, starting with the vessel it goes in → The context window
question → tool call → result → answerTurn 1: I need revenue data → get_revenue(2026-07) → result: 420,000Turn 2: I also need the target → get_target(2026-07) → result: 450,000Turn 3: There's a gap. I should look at why → get_revenue_by_product(2026-07) → result: (table by product)Turn 4: Product A dropped a lot. Compare with the same month last year → get_revenue(2025-07, product=A) → result: ...Turn 5: That's enough → write up the summary□ maximum turns (e.g. 20)□ maximum cost (e.g. $2 for this job)□ maximum time (e.g. 10 minutes)□ actions requiring human approval (anything irreversible)