Define what an agent may do with your data

#ai #agents #webdev

Reliable agent operations depend on usable inputs, explicit permissions and observable outcomes. Define the allowed actions and the conditions that require a human decision.

Reading a site is the first step. The harder one is letting an agent act on a system that matters, where a wrong move has a cost. That depends on two things the model does not provide on its own. The data the agent works from has to arrive intact, and the decisions it is allowed to make have to sit inside a boundary you set.

Inputs

An agent's decision is bounded by the data that reaches it. In a clean environment that is invisible. Where the work happens it is the whole problem, because a dropped link, a delayed hop or a lost packet can leave the agent working from stale input. The model did not get worse, its inputs did. Reliability lives in the layer below the model, where data either arrives in order and on time or it does not.

Allowed actions

A correct decision is not an agent doing whatever it infers. It starts with an envelope defined for the agent, the permissions, the thresholds and the explicit list of what it may touch and what it may not. The judgment is front-loaded into that boundary by a person who knew the stakes. Staying inside it makes an action allowed, and an allowed action can still be wrong for the task, which is why the data the agent acts on matters as much as the boundary. Draw the boundary loosely and a capable agent still does something, just not what you wanted.

Commerce protocols are one place where the boundary is written down in a specification. The Universal Commerce Protocol carries a checkout state called requires_escalation, which means the agent has reached the edge of what it may finish alone and a person has to complete the step. AP2 does the same on the payment side, where a mandate records the limits the user agreed to before the agent acted. Both encode a decision somebody made in advance. Decision envelope is the name this guide gives that pattern, and neither specification uses the term, so do not go looking for it in either document. Neither decides for you where the line sits, and that is a judgment about which actions are reversible and who carries the cost when one is not.

Human handoff

Letting agents act is not removing people. The stronger pattern carries a human expert's judgment to where the work is and lets the agent handle the parts that have to be instant or exact, with a clear point where control passes back. The hardest version is where no person can step in fast enough, so the decision has to be made locally under rules agreed in advance. The fields that work under that constraint learned the discipline first.

Verification

An agent that acts has to be auditable. Log what it decided and why, keep the envelope explicit rather than implied, and verify after the fact that it stayed inside the boundary. Guardrails have to be checkable to count. That separates an agent that looks convincing in a demo from one you would let touch a real operation.

These patterns are illustrative rather than a description of a delivered client implementation. The specifics of a workable envelope depend on the system and the stakes involved.

For a review of the data path, the decision envelope and where a human stays in the loop, contact info@turva.dev.

Frequently asked

What is a decision envelope?

The permissions, the thresholds and the explicit list of what an agent may touch and what it may not. The judgment is front-loaded into that boundary by a person who knew the stakes, so the envelope decides which actions are allowed. An allowed action can still be wrong for the task.

Where is the decision envelope written down in a protocol?

Commerce protocols give concrete examples. UCP carries a checkout state called requires_escalation, where the agent has reached the edge of what it may finish alone. AP2 does the same on the payment side, where a mandate records the limits the user agreed to beforehand.

What makes an acting agent auditable?

A log of what it decided and why, an envelope that is explicit rather than implied, and a check after the fact that it stayed inside the boundary. Guardrails have to be checkable to count.

Sources

Originally published at https://turva.dev/guides/letting-agents-act-on-data

DEV Community