From Agent Intent to Governed Execution

A model asks to issue a refund. Somewhere between that request and money moving, a series of decisions happens. In many systems those decisions are implicit, which means they are being made by whichever code happens to run first.

This page is about making them explicit, because each one fails in a different way and needs a different fix.

The path

A model can produce a request for an action. Software outside the model determines whether that request is allowed to become an effect.

Between the two, four things happen:

Check the request. Is it well-formed? Does it name a real operation, with arguments of the right types referring to things that exist? This is the structured output work, applied at the moment before action.

Decide whether it is permitted. Separately from whether it parses, should this run, for this user, in this context, right now?

Run it. Call the tool, with whatever limits apply.

Check what happened. Not whether the call returned, but whether the thing you wanted is now true.

That is a sequence, not an architecture. Small systems collapse it into a few lines of code, and it still helps to know which of the four a given line is doing.

Permission is its own question

Authorization asks whether an operation is permitted, which is a different question from whether the request is well-formed.

This gets confused with four other things routinely:

• Authentication establishes who is asking. Permission is about what they may do.
• Schema validation establishes the request is well-shaped. A perfectly formed request to delete a production table is perfectly formed.
• Model confidence is a property of generation. It is not a permission signal and should not be used as one.
• Human approval is one way to resolve a permission question, not the same thing as having one.

In practice this layer answers questions with concrete answers: is this tool available to this caller, is this resource inside the scope they were granted, does the amount exceed a threshold that requires something extra. Keep those rules in code you can read, separate from the instruction text, because a rule inside a prompt is a request and a rule in the authorization layer is a check.

What bounded autonomy means

Bounded autonomy is the arrangement on this page, given a name. The model has real discretion: it can choose the next step and propose actions nobody scripted in advance. The bounds sit outside it: which tools it may request, what scope and amounts are allowed, and what happens when the answer is unclear. A model that can ask for anything, where only permitted requests become effects, has autonomy within bounds. A prompt asking it to be careful is not a bound. The four bounds, and the test for telling a bound from a request, are in what is bounded autonomy. Who chooses the next step in the first place is covered in AI agents vs AI workflows.

When the answer is not obvious

Sometimes the system cannot tell whether an action should proceed. Treating that as a binary produces bad outcomes at both ends: block everything useful, or let everything through.

Four responses are usually enough:

Mode	When	What it leaves behind
allow	Permitted, and evidence is sufficient	The action and its verification
ask	A person needs to decide, or context is missing	A specific question, with the reason
deny	Not permitted, or the risk is unacceptable	A reason code
defer	Evidence is thin and the impact is high	A handoff record

Choosing between them comes down to three things: whether policy permits it at all, whether there is enough evidence to justify it now, and how expensive the mistake is to undo. That last one does most of the work. An action that can be reversed in a click deserves a different threshold from one that emails a customer.

It also helps to know what kind of uncertainty you have. Missing or conflicting inputs usually call for getting more context. Several plausible options with nothing to separate them calls for a tighter constraint or a second check. An action that will technically succeed while possibly being the wrong thing to do calls for reversibility or a person. These need different responses, so collapsing them into "the system was unsure" loses the information you need.

When the answer is that a person should decide, this page hands over. Who reviews it, what they see, and whether they are positioned to say no is human judgment, and it is a real design problem rather than a checkbox.

The tool returned success

A successful tool call is not proof that the intended effect occurred.

An API can return 200 while the record it was supposed to update is unchanged, or updated in a way that gets rejected downstream a moment later. A file write can succeed to the wrong path. A message can send to an address that bounces.

So verification is a separate step. A successful response establishes what the interface reports about the call. Where the thing you wanted is a change of state, check that state rather than treating the response as proof of it. Read the record. Confirm the balance.

This is the difference between a step that reports done and a step that shows done. Completion should be evidenced rather than stated, and the gap between those two is where a surprising number of confident, wrong systems live.

Classifying what went wrong

Once the path is explicit, failures stop being one undifferentiated category. They fall out as:

• policy denied it
• the tool errored
• verification failed
• required evidence was missing
• it exceeded a time or cost limit

Each leads somewhere different. A denial might mean the policy is too broad or correctly protective. A verification failure means the tool lied to you, or you checked the wrong thing. Without those classes, incident review turns into narrative: debugging becomes storytelling instead of engineering, and the same fix gets applied to unrelated problems.

Keeping a record of each decision is what makes this possible, and what belongs in that record over time is observability. This page only claims the narrower thing: you cannot classify a failure at a boundary you never made explicit.

What stays probabilistic

None of this makes the system deterministic. The model still varies, and a policy check does not change that.

What the checks give you is a dependable answer about one candidate action: given these rules and this request, permitted or not, every time. The variation stays upstream where it belongs, and the decisions about effects stop inheriting it.