Design agent permissions before you design agent capability

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.

An agent's permissions are the actual product decision. The prompt is just implementation detail on top of it.

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.