What you actually need to be able to do. Not coding, and not prompt engineering either. The skills that separate an agent you can leave running from one that quietly does the wrong thing are mostly about judgement, and each is learnable in an afternoon.
One note on the word. “Skills” here means your capability. You will also meet Agent Skills, which are written procedures you hand to the agent. Related, and covered on the tools page.
One: describing a process properly
The most valuable and least glamorous. If you can write down how a job is done, step by step, well enough that a new starter could follow it on Monday, you can build an agent. If you cannot, no tool will rescue you.
This is also the skill with the best return outside AI entirely. The written procedure survives everything: changing tools, changing platforms, changing your mind. It is the one asset in this subject that does not go out of date.
Practical version: write the steps, hand them to someone who does not do the job, and watch where they get stuck. Those gaps are exactly where your agent will fail.
Three: designing the handback
A good agent knows when to stop and ask. That is a feature you build, not a failure you admit, and it is the most useful single thing on this page.
Write the rule down. It should come back to a person when:
- the value is over a threshold you set
- the case falls outside the policy it was given
- it is not confident
- the action cannot be undone
- it hits something it has not seen before
This is now how the serious platforms are sold. The enterprise agent products released this year lead on exactly this: the customer sets what the agent may do, when it needs approval, and when a human takes over. Full autonomy stopped being the goal.
A handback rate is not a failure rate. Expect a decent share of cases to reach a person on anything well built, and read that as the design working. Since August 2026 it is also close to what the EU AI Act asks for under human oversight, so designing it well is no longer only good practice.
If a vendor cannot tell you what makes their agent stop and ask, there is no handback rule, and the honest reading is that it escalates by failing.
Four: telling a rule from a wish
There are two kinds of rule and only one is reliable.
Instructions are things you tell the model in its prompt. It will usually follow them. Usually.
Guardrails are enforced outside the model: permissions that do not grant access, code that runs before an action and blocks it, an approval step that cannot be skipped. The model cannot reason its way round these, because it never gets the chance.
Anything that genuinely matters belongs in the second category. Never sends external email without approval. Cannot see the confidential folder. Cannot spend money. Those are permissions and checks, not sentences in a prompt.
The question to ask of your own build, or of a vendor: what should it never be allowed to do, even if it decides it should? If the answer lives only in a prompt, it is not a guardrail.
Five: spotting the silent failure
Loud failures are easy. The agent crashes, you notice, you fix it. The one that costs you is the agent that keeps running and quietly produces nothing useful.
Four of our own pipelines did precisely that for weeks. Every check was green. The jobs were running. They just were not doing anything, and we found out because a user complained.
The skill is knowing that a health check is not an outcome check. Do not ask “did it run”. Ask “does the thing that should exist by now exist”. If a report should land every Monday, alert when Monday passes without one.
This is the difference between an agent you can leave running and one you have merely stopped watching.
Six: earning autonomy rather than granting it
Keep a human in the loop for the first fifty runs. Not fifty runs of watching it work, which teaches you little, but fifty runs where you record what it got wrong and why. Patterns appear fast, and almost never the ones you predicted.
Then widen its authority one notch at a time. Assist to suggest-and-approve. Approve to act-and-review. Only go further if the error rate at the previous notch was genuinely acceptable rather than merely tolerable.
Keep the log. If your agent ever touches anything regulated you will need it, and six months of records is now a common expectation rather than a nicety.
These six are what we teach, and they are why our clients’ agents are still running a year later. If you would rather be taught them than read them, that is most of what our programmes do.
Risk does not live where people think it does
Put the two decisions side by side and something useful falls out. Down the side, who decides the next step. Across the top, who is in the loop.
| Assist | Approve first | Act, review after | Nobody reviews | |
|---|---|---|---|---|
| One AI call | A chatbot. The commonest thing there is | Suggest and accept. Very safe | Rare | Auto-classification. Fine if errors are cheap |
| Automation | — | An approval step in a flow | Runs overnight, checked in the morning | The classic batch job. Where most real damage happens |
| Automation with AI | A drafting tool | Drafts for approval. The safest useful shape | Reviewed by exception | Needs a flagging rule, not a decision |
| Agent | — | Plan, then approve | The normal, sane agent shape | The scary one. Rare, and rarely wise |
Read the bottom-right corner, then read the row above it. A fully automated process with nobody reviewing it is more dangerous than a supervised agent, and it is the one nobody worries about, precisely because it does not have a frightening name.
Until recently that corner had an accidental gate in front of it: reaching it needed an engineer, and engineers ask about error handling. That gate has gone. Around fifty pounds a month now buys a no-code agent that reasons, connects to your systems, runs on a schedule and clicks around a website when there is no API. Nothing in the interface ever asks who reviews the output.
Which is why this question belongs in the first conversation rather than the deployment one.