At a glance
What you need to know.
An agentic workflow uses a model to choose useful steps while application code controls what can actually happen. Start with one bounded process: inspect permitted information, prepare a proposal and request approval before a consequential action. This reference design explains the execution boundaries and recovery behavior to establish before giving an assistant access to business systems.
How the system fits together.
A reference flow to adapt to your data, users and operating constraints.
- 01
Scope the request
Identify the requester, permitted records, intended outcome and workflow limits.
- 02
Gather evidence
Read approved sources and retain references needed to review the proposal.
- 03
Prepare a proposal
Validate structured tool arguments and describe the expected business change.
- 04
Obtain approval
Show the specific action to an authorized reviewer when its consequences require approval.
- 05
Execute and record
Apply the accepted operation through a scoped connector and save its outcome.
- 06
Reconcile exceptions
Inspect uncertain results, recover unfinished work and escalate unresolved failures.
Choose a process with a clear stopping point
Begin with a request that has an identifiable owner and an observable result. An illustrative support workflow reads a permitted ticket, finds approved guidance and prepares a reply for review. The model can select relevant evidence or suggest a next step. A state machine decides whether that step is available, whether the requester may take it and when the workflow must stop.
Compare this design with an ordinary rules-based workflow before adding a model. Fixed invoice routing or scheduled data synchronization may need predictable automation alone. AI becomes useful when interpreting varied language or selecting evidence requires judgment. Set limits on attempts, processing time and resource use. A missing fact, unavailable source or conflicting instruction should produce a review task rather than an endless chain of tool calls.
Make tools enforce the actual permissions
Expose narrow operations such as reading an assigned ticket or preparing a draft, instead of general database or shell access. Enforce authorization and argument validation in the connector and downstream service for every call. Separate reading, drafting and sending capabilities. Retrieved documents and messages provide evidence; they cannot grant permission to change policy, access another tenant or select an arbitrary destination.
For a consequential step, present the exact target, proposed change, relevant evidence and likely effect to an authorized reviewer. Bind approval to that operation and its version, with an expiry. Changing the recipient, amount or record after review requires a new decision. Recheck current permissions when executing: a recorded approval does not preserve access that has since been revoked. Keep cancellation available while an operation is still pending.
Store business state outside the conversation
Keep a durable operation record with the request identifier, current state, proposed arguments, approval receipt, connector attempt and external result reference. A conversation transcript is useful context but should not be the authoritative ledger. Distinguish prepared, awaiting approval, executing, completed, failed and outcome-unknown states. Workers can then resume an unfinished operation after a restart without reconstructing permission from model output.
Queues can deliver a message more than once. Reuse a stable operation identifier and the downstream API’s idempotency mechanism where available. A timeout does not prove that a remote write failed: query its receipt or reconcile the affected record before retrying. Set an attempt limit and expose exceptions to an owner. When reversal is possible, define a separate compensating action with its own checks rather than silently rewriting history.
Evaluate decisions and operational recovery separately
Create representative tasks with expected evidence, permitted actions and stopping conditions. Include misleading retrieved instructions, missing data, unauthorized records, changed approvals, duplicate delivery and connector outages. Evaluate the proposed action separately from successful execution. A plausible draft with an incorrect target is a failure even if its API call works. Compare completion, reviewer corrections, escalation and processing cost against the existing manual or deterministic process.
Record actor, tool, policy version, decision and outcome identifiers so an operator can explain what happened without retaining unnecessary sensitive content. Make pending approvals and uncertain results visible in the review queue. Start with read-only or draft-only operation, then enable narrowly scoped writes after acceptance checks and a recovery exercise. Assign owners for source updates, connector incidents and model changes; re-run the evaluation set when those dependencies change.
Before you start.
- Define one process owner, success condition and stopping policy.
- Separate read, draft and execution permissions.
- Bind approval to the exact operation and recheck access.
- Persist operation state and reconcile uncertain remote outcomes.
- Test permission failures, duplicate delivery and manual recovery.
Common questions.
Does every agent action need human approval?
No. Permitted reads and bounded low-risk steps can follow an agreed policy. Consequential writes should have the approval required for their impact. Define that policy before rollout and enforce it in execution code.
How should a workflow recover after a tool timeout?
Record the outcome as uncertain, check the downstream receipt or current business record, and retry only when safe. Keep the operation identifier stable and escalate unresolved ambiguity rather than assuming the action failed.