Most agent projects start with a capability list: it should be able to look up orders, draft emails, update records, issue refunds. That's the wrong list to start with. The list that actually determines whether the project is safe to ship is the one nobody writes down by default: what should this agent never be allowed to do without a human confirming it first.
Capability and judgment aren't the same thing
An agent can be technically capable of issuing a refund, sending an email to a customer, or modifying a database record, and still not have the judgment to know when it's the right call. That gap is where the risk lives. The fix isn't a smarter model, it's a permission boundary that doesn't depend on the model getting the judgment call right every time, because eventually it won't.
- Tiered autonomy: read and draft freely, but require explicit confirmation for anything that spends money, sends an external message, or deletes data.
- Hard caps: a refund agent that can approve up to a set dollar amount and routes anything above it to a human, no exceptions in the code path.
- Scoped credentials: the agent's API key can only touch the systems and actions it actually needs, so a bad decision has a small blast radius.
- A kill switch that's actually tested, not just present in the design doc.
Write the boundary before the prompt
It's tempting to write the agent's instructions first and bolt on guardrails once something goes wrong in testing. Do it the other way around: decide the permission boundary and the escalation path before writing a single line of the agent's behavior, then build the capability inside that boundary. It's a smaller design surface and it forces the question of what 'safe to leave unattended' actually means for this specific workflow, not agents in general.
This is what clients are actually buying
When a client asks for an AI agent, what they're really asking for is something they can trust to run without watching it constantly. That trust doesn't come from the agent being smart. It comes from knowing exactly what it can and can't do, and having that be true even on the day it's wrong about something.
Related reading
AI-ready data: four tests before you add an AI step
Gartner expects most AI projects without AI-ready data to be abandoned through 2026. The model is rarely the reason. Here is what AI-ready data means for a small business, the workflow that sits under an AI step that works, and four tests you can run on your own data this week.
Sources → Pipeline → One source → AI step → Checks → Person
Everyone sells agents now. Most of what you need is not an agent.
Agentic AI is the loudest pitch of the year. But for most back-office work, a pipeline with one well-placed model step beats an autonomous agent on cost, reliability, and sleep. Here are the three questions that tell you which one you actually need.
Fetch → Extract → Check → Write → Checkpoint
AI agents vs. chatbots: what actually reduces support load
Most support bots just deflect. An AI agent that can read your docs and take action is a different thing entirely. Here's where each one earns its keep.
Ticket in → Reads knowledge → Takes action → Knows its limits → Improves
Continues · Got a workflow like this?