Define the boundaries before building an AI agent

Start with the workflow

An agent that “runs the business” is hard to test and even harder to give sensible permissions. Start with something smaller: draft a response for a named ticket, leave it for review, and stop if the source is missing. Write down the trigger, allowed inputs, expected output and recovery owner before wiring up the tools.

Separate reading from acting

A workflow that retrieves documents has different consequences from one that sends email or updates a CRM. Use separate tool permissions and approval gates for these steps. The model’s confidence is not authorization.

Make repeated actions safe

A timeout does not prove that a write failed. A retry can create duplicates. Assign an idempotency key to a logical action and check the destination’s response before deciding to repeat it.

const action = {
  workflowId: "example-workflow",
  permission: "draft_only",
  requiresApproval: true,
  maxAttempts: 2,
};

This example describes a policy object; your tool layer still has to enforce it.

Test the failure path

Include missing fields, unavailable APIs, expired access, contradictory documents and interrupted execution. A useful evaluation asks whether the agent stops safely and makes the problem visible.

Keep the operator in the loop

Show what was attempted, what changed, what failed and what needs approval. Keep secrets and private document contents out of routine logs.

Download the production checklist and explore AI agent engineering.

Further implementation guides

Read the security guide, monitoring guide and evaluation guide. These are review editions with sources and worked examples.

Turn the boundary into a contract

For a first implementation, define a draft-only support workflow. Its input is one ticket identifier. Its read capability is limited to the ticket and approved reference material. Its output is an editable draft attached to that ticket. The workflow has no permission to send the draft, modify account access or search unrelated customer records.

Write acceptance criteria before adding model instructions. A valid run must use the intended ticket, support factual claims from the retrieved evidence and leave the destination in the expected draft state. A missing source should produce clarification or escalation. The model’s confidence does not replace any of those checks.

Treat unknown outcomes as a separate state

An integration timeout can occur after the destination accepted a write. Repeating the operation may create a duplicate. Store a stable logical action identifier, record attempts separately and reconcile the destination before retrying an uncertain action. If the destination cannot support safe reconciliation, stop and route the task to its operator.

The operating record should distinguish proposed, authorized, executing, completed and uncertain work. This allows another worker or a human to resume investigation without reconstructing the state from a conversation. A transcript explains what the assistant said; it does not independently prove what the external system contains.

Review before expanding autonomy

Add one integration or permission at a time. A workflow that retrieves public documents has a different data boundary from one that searches internal customer records. A draft-only assistant has a different effect boundary from one that sends messages. Repeat the relevant acceptance tests whenever that boundary changes.

Use the workflow planner to prepare the brief and the evaluation calculator to inspect test-count uncertainty. Neither tool executes policy or certifies readiness. They make assumptions and decisions more explicit so an engineer can implement and test the actual controls.

Source context

Anthropic distinguishes predefined workflows from agents that choose their own next steps. That is a useful architecture distinction when deciding how much autonomy a task needs. The contract and failure-path examples in this article are original engineering recommendations. They do not imply a measured client outcome or a completed security assessment. Read the architecture reference.