Module 1 · Chapter 1: What an agent is
When to use an agent, and how freely
In short
If the steps can be written in order now, use a plain prompt or a fixed workflow. If not, an agent may fit, and its autonomy is chosen per action: suggest, act with approval, or act alone.
After this lesson you can
- Choose between a plain prompt, a fixed workflow and an agent for one task
- Set an agent's level of autonomy from the task's risk and how easily it can be undone
Terms in this lesson
Understand
For every task there are three honest choices: a plain prompt, a fixed workflow, or an agent. Their order is also their order of cost and risk, from lightest.
Use a plain prompt when the result is one document or one answer that you will read and use yourself: summarising minutes, drafting a letter, explaining a term. No tool needs to touch another system.
Use a fixed workflow, that is automation whose order a person wrote, when the steps are the same every time and you can write them up front: every morning fetch the report, summarise it, post it to the team channel. A model may be used in one step, but it does not pick the path. Such a workflow is easy to test because every run is the same.
Use an agent when the next step truly depends on what is found, and there are too many possible paths to write one by one: tracing the cause of an error, building a report from dozens of documents whose content you do not know yet, fixing code until its tests pass.
The deciding question is simple: can I write the steps in order now? If yes, do not use an agent. If not, an agent may fit, and the next question is how freely it may act. The full discussion of when not to automate at all is in the lesson on when not to automate.
An agent's autonomy has levels, and you choose them per action, not per agent:
- Suggest. The agent only reads and writes a proposal. You carry it out. Good for the start, and for actions that touch other people.
- Act with approval. The agent prepares a complete action with a preview, then waits for you to press approve. This is the right level for most write actions.
- Act alone. The agent runs without asking. Only for actions that are cheap, narrow and easy to undo, such as reading files or writing in a test folder.
Two measures help you choose. Can it be undone? A draft can be discarded; a sent e-mail, a payment and deleted data cannot. How wide is the damage if it is wrong? Changing one file in your own copy is narrow; changing data the whole team uses is wide. Actions that are hard to undo or wide in impact still need human approval, however much you trust the agent. That is not a sign of distrust; it is how one mistake stays small.
Agents also carry costs that do not show in a demo. Every turn resends the whole context to the model, so a twenty-turn task can cost many times more than one good prompt. Results also differ between runs, so you need a test set to know whether a change made things better or worse; that is covered in this phase's projects. And someone has to read the trace when something goes wrong. If these costs are larger than the time saved, a fixed workflow or a plain prompt is the better decision, not the less advanced one.
Before
The prompt
Build an agent that handles all my incoming e-mail: replying, archiving and deleting what is not important.
What came back
Weak output: Agent ready. It will read all incoming e-mail, reply on your behalf, move e-mail to the archive and delete e-mail it judges unimportant.
After
The prompt
Goal: I want to spend less time reading e-mail in the morning. Material: the project inbox only, not personal e-mail. Limits per action: reading and labelling may run directly; reply drafts may be created but not sent; moving to the archive waits for my approval; deleting is not allowed at all. Shape: a morning list of e-mails that need me, with reply drafts for routine ones. Check: for two weeks I compare the list with the real inbox.
What came back
Morning list: 6 e-mails need your decision, 9 routine e-mails with reply drafts ready to review, 23 information e-mails labelled. Archive proposal: 17 e-mails, waiting for your approval.
What changed
- The first request gives one autonomy level to every action, including sending and deleting, which cannot be undone.
- The second chooses the level per action and limits the material to one inbox.
- The two-week trial gives evidence before autonomy is raised.
Common mistake
- Mistake
- Giving an agent full autonomy from day one because the demo went smoothly.
- Why it hurts
- A demo uses chosen examples. Real data has odd cases the demo never showed, and an agent acting alone will carry out those mistakes with no one watching, until other people feel the impact.
- Do this instead
- Start at suggest, move to act with approval for actions that have proven right, and let only cheap, easily undone actions run alone. Raise the level based on a record of results, not an impression.
Try
Sorting card
Which level should each agent action sit at?
Writing files in a test folder
Sending an announcement to every employee
Changing a meeting that involves five people
Creating a new ticket in the team system
Reading files in the project folder
Deleting old customer data
6 cards left
At the end of every month you copy figures from three reports that always have the same format into one table, then write a summary paragraph. Which choice fits best?
Take home
Choosing the form and the level
- Can I write the steps in order now? If so, not an agent
- For each action: can it be undone, and how wide is its impact?
- Send, delete, pay and actions towards many people always wait for approval
- Autonomy is raised on a record of results, not the impression of a demo
- I write down who checks the results and when
Try it now with one real task from this week. Write the task in one sentence, then answer the deciding question: can you write its steps in order? If so, write those steps and mark the one step where a model helps. If not, list every action the agent might take and give each one an autonomy level. Keep that list; in chapter two you will turn it into real permission rules.
What went wrong for us
Plans are also judged by an attacker
- Context
- When planning a feature, we ask AI to judge it from several viewpoints: engineering, strategy, revenue, and an attacker.
- What tends to go wrong
- A plan judged only by people who want the feature to work tends to miss how it can be abused, such as an agent allowed to run any action.
- What it costs if ignored
- A dangerous design can reach the build stage and then be costly to undo.
- Root cause
- We judge ideas from the viewpoint we like.
- How we do it
- The attacker persona tries to use the feature to delete data, send mass messages or bypass permissions. Its findings become design limits, such as a list of allowed actions and user confirmation.
- The rule we keep
- Every plan that touches data or automated actions is also judged by an attacker persona before approval.
The lessonAsk AI to attack your plan before someone else does.
What it means for your workBefore you put forward an important plan, ask someone, or the AI, to look for its weaknesses on purpose. People who want a plan to succeed rarely see its holes.