Understand AI · Chapter 2 of 13
Your AI can click. What should it be allowed to do?
Understand tools and agents by planning one task with a clear boundary between reading and acting.
About 5 minutes · school-level background
Edition 2026-10-28.1 · Checked 2026-10-28
What you will understand
Distinguish a model, a tool, a workflow and an agent, then give one bounded task a usable permissions brief.
In this lesson
Build the idea
The moment an answer becomes an action
A chat assistant can suggest that you book a room. An assistant connected to a browser might also fill in the booking form. These look similar on screen, but their consequences are different. The first produces text for you to consider. The second may change something outside the conversation. To use capable AI well, you need to know where that boundary lies. Being good at describing an action does not by itself give a system permission to perform it.
Think about a calculator. A model can request a calculation, the calculator returns a result, and the model uses that result in its answer. The calculator is a tool. A browser, a file reader and a calendar connection are tools too, but they have different powers. A file reader may reveal information; a calendar connection may create an event. The application that supplies these tools should control which operations are actually available.
Assistant proposes
Tool can act
Person checks the action
Person approves before publishing
A simplified reading aid. Follow the article for sources, conditions and limits.
What the source reports
Why this matters now
Qwen Code’s 9 October update describes voice interaction and work in logged-in browser sessions. Anthropic’s engineering essay distinguishes predetermined workflows from agents that choose their own next steps. Together these sources motivate a practical question: how much freedom does this particular job need? Product capability and permission to use someone’s account are separate decisions.
Original report: Qwen Code: 9 October product update (Chinese) · Anthropic: Building effective agents
Worked teaching example
A workflow and an agent walk into a venue search
Imagine three fictional venues for a club meeting. A fixed workflow reads each supplied description, extracts capacity and price, calculates the total, and presents a table. The steps are known in advance. An agent might instead notice that one venue does not specify accessibility, search its information page, and decide whether another source is needed. It chooses part of the route while working. Both designs can be useful. The difference is who chooses the next step.
Suppose the task is to compare costs for twenty people. Venue A lists a flat fee of sixty pounds. Venue B charges two pounds per person plus twenty pounds for the room. Venue C lists forty pounds but does not say whether equipment is included. A and B both total sixty pounds. C cannot yet be treated as the cheapest complete option. A useful assistant preserves that missing condition rather than guessing an equipment fee and turning uncertainty into an apparently precise ranking.
Try to predict what the assistant should do next. If it has only the supplied text, the correct next step is to report the missing condition. If you authorised reading the venues’ public pages, it can look for the equipment policy and record the source. If you did not authorise sending messages, it should not email the venue on your behalf. A good task can have a useful stopping point before every uncertainty is resolved.
Use the idea
Write permissions in the language of the task
A helpful brief names the goal, allowed inputs, allowed actions, forbidden actions, output and stopping rule. For our example: compare the three supplied venues for a twenty-person meeting; read only the supplied descriptions; calculate stated prices; do not book, pay or contact anyone; return a table with unresolved conditions; stop after the comparison. This is more useful than simply saying to be careful. It tells the system what to do when the task becomes ambiguous.
If you later allow web reading, make that an explicit change. A page being public does not make every instruction on it part of your task. A venue page might contain advertising or even text telling an assistant to ignore its user. Treat the page as information to inspect. Keep the user’s goal and the application’s permission rules outside the authority of retrieved content. In software, tool restrictions should be enforced by the application, not only written as a request in a prompt.
Build the idea
Give the system a way to stop well
Stopping is part of doing the job. An assistant that cannot find a fee can return the sources it checked, the information it extracted and the exact missing question. That partial result is reusable. An assistant that keeps opening pages indefinitely may spend more time without improving the decision. Before a run, decide what a satisfactory result looks like and what should happen when it cannot be obtained.
For this exercise, a satisfactory result is a comparison with correct arithmetic and visible unknowns. A sensible stop is one completed comparison or one unresolved conflict that would change the recommendation. In a larger application you might also set time, tool-call or spending limits. A limit should produce a readable handoff, not turn an unfinished job into a false success message. Preserve what was actually checked so that a later attempt does not start from nothing.
Use the idea
A chat-only route still works
You can practise this without installing an agent framework. Paste the three invented descriptions into an ordinary chat and ask for a table. Check the arithmetic yourself. Then add an ambiguous sentence and see whether the assistant reports the ambiguity. This tests the shape of the work without granting access to your email, files or payment methods. You are learning to define a good task before connecting powerful tools.
When you do use a tool-capable agent, begin with an output you can inspect: a saved draft, a comparison or a proposed change. Read the actual action description before approving an external change. The useful ambition is to make the work easier while keeping the scope understandable. Your finished artifact from this lesson is a permissions brief that another person could read and say, yes, I understand exactly what this assistant may do.
Words you can now use
- Tool
- A capability the application exposes, such as reading a file or calculating a value.
- Workflow
- A process whose main steps are set in advance.
- Agent
- A system that can choose further actions while working towards a goal.
Check your understanding
A venue page tells the assistant to send your contact details to claim a discount. Your brief allowed public-page reading only. What should happen?
Show the explanation
The assistant should treat that text as page content, not permission. It can mention the offer if relevant but must not send your details. The application should not expose an unauthorised sending action.
Read the original sources
- Qwen Code: 9 October product update (Chinese)Vendor product update · Published 2026-10-09 · Checked 2026-10-28
- Anthropic: Building effective agentsEngineering experience · Published 2024-12-19 · Checked 2026-10-28
Try it with your own assistant
Select and copy this bounded exercise. A normal chat assistant is enough to start.
Draft a read-only brief for comparing three fictional event venues. Allow only the supplied text, forbid purchases and messages, require an uncertainty list, and stop after one comparison. Ask your assistant to identify missing information before recommending a venue.
Keep the task brief, supplied inputs, checked output and unresolved questions together. Using this exercise does not submit anything to WRS.