Start with the boundary, not the promise.
An agent that produces a good answer once is an encouraging experiment. An agent that participates in a product has a different responsibility. Its work has a beginning and an end. It interacts with information that has an owner. It may call tools that change something important. Someone needs to understand what happened when an execution takes an unexpected turn.
A useful way to design that responsibility is to start with boundaries. Not a vague instruction to “be careful,” and not a larger prompt explaining every possible exception. A boundary is a concrete decision about what the workflow may access, which actions it may perform, when it must stop, and who owns the next step.
This field guide proposes four such boundaries. They are an operating model to adapt, not a claim that one configuration makes a system safe or reliable. The example is a fictional support-resolution workflow that can retrieve help articles and draft a reply. It cannot change an account or issue a refund.
1. Give context a shape and a purpose.
Begin by listing the information the workflow actually needs. A support resolver might need a customer’s current question, a product version, and a set of approved help articles. It does not automatically need the entire customer record, every previous conversation, or unrestricted access to internal documents.
Separate the scope of retrieval from the permission to act. Reading an article about an account change is not authorization to perform the change. A workflow can use relevant context to explain a process while still handing the action to a person or a separately authorized service.
Name the source and version of important context. An investigator should be able to tell whether an answer was based on an old policy, an incomplete document, or an unexpected retrieval result. Keeping that reference is often more useful than keeping another undifferentiated copy of the full input.
Treat retrieved text as data. A document can contain instructions that are unrelated to the user’s request or the application’s rules. The surrounding application should enforce the access boundary; a sentence in a retrieved page should not be able to redefine it.
2. Decide what a run is allowed to spend.
Every workflow needs a stopping condition. Success is one condition, but it is not the only one. A time limit, a tool failure, a missing permission, an exhausted budget, or insufficient information can all be legitimate reasons to stop and return a clear state.
Make the distinction between retrying and reconsidering explicit. A transient network error may justify another attempt at the same operation. An ambiguous customer request may require clarification instead. Repeatedly calling a model does not turn missing information into an authorization.
The following JSON illustrates the shape of a bounded workflow. It is a fictional configuration, not an API contract you can send to an existing service. The values are examples, not recommended limits for every workload.
{
"workflow": "support-resolver",
"version": "2.4.1",
"context": { "collections": ["help-center"] },
"tools": ["search_articles", "draft_reply"],
"limits": {
"max_steps": 8,
"timeout_ms": 15000,
"max_cost_usd": 0.08
},
"escalation": { "account_changes": "human_review" }
}A budget should be tied to a useful unit of work. Here, the unit is one support-resolution execution. The policy names a maximum number of steps, a wall-clock timeout, and an illustrative cost ceiling. An application implementing this contract would need to enforce those limits outside the model and return a clear result when a limit is reached.
Tool contracts matter just as much. Define required inputs, allowed operations, and repeat-call behavior. An action that creates a record should not silently create another record when a request is retried. Design the service boundary around that possibility rather than assuming a workflow will only call the tool once.
3. Promote evidence with the change.
An agent release is more than a new prompt. The model route, retrieval configuration, tool permissions, policy revision, and surrounding application code can each change the outcome. A useful release record names the pieces that moved together.
Before promotion, compare the candidate against a small, maintained set of examples that represent the work. Include ordinary cases, incomplete requests, requests outside the workflow’s authority, and cases requiring a person. Review the behavior you need, not only whether the output sounds polished.
Attach those results to the exact candidate configuration. A passing evaluation from a previous version is not evidence about a newly expanded tool permission. If an important dependency changes, decide which evidence must be refreshed before the release proceeds.
Also write down the rollback boundary. Restoring a configuration may stop new runs from using it, but it does not necessarily undo actions that have already happened. A release plan should distinguish prevention, recovery, and compensation rather than treating all three as one rollback button.
4. Make the handoff somebody’s responsibility.
A workflow that escalates to “human review” still needs a real handoff. Who receives the work? What information travels with it? What is the safe state while it waits? What happens when the reviewer is unavailable?
Give each workflow an owner and each failure state an understandable meaning. “Timed out before action” is different from “action accepted, confirmation unavailable.” The distinction affects what a person should do next and whether another attempt could cause an unwanted duplicate.
Carry a stable execution identifier across the handoff. Include the workflow version, the step that stopped, and the relevant tool result. Do not make the reviewer reconstruct the entire history from screenshots or unrelated logs.
Keep operational records proportionate to the task. A complete account of the decisions does not always require storing the full sensitive content involved in each decision. Define retention, access, and redaction with the people responsible for the application and its data.
One workflow is enough to start.
Choose a workflow with a clear owner and a limited set of actions. Write its context boundary in one paragraph. List its tools. Define its success, stop, and escalation states. Name the release evidence you will review, and the identifiers you will need during an investigation.
Then run a small set of examples through that contract. When something is unclear, improve the boundary before adding another instruction to the prompt. The resulting design may be less dramatic than an all-purpose agent, but it will be easier for another engineer to understand, test, and operate.
The goal is not to predict every possible model response. It is to make the system around those responses explicit enough that the next decision has a safe, observable place to happen.