Engineering Scenario
IllustrativeAgentic Workflow Automation
An engineering scenario for automating a multi-step business process with AI agents that plan, call tools and act under policy checks, human approval and a full audit trail.
The problem
Consider an operations team that handles a steady flow of requests, each of which requires reading an unstructured message or document, looking up records in several internal systems, applying judgement against a policy and then updating one or more systems. The steps are well understood, but the inputs vary too much for a rule-based workflow to cover.
A language model can read the input and decide what to do next, which makes it tempting to give an agent access to the systems and let it run. Without constraints, such an agent can take a wrong action with full confidence, repeat an action after a failure or be steered by instructions hidden in the content it reads. The engineering problem is to obtain the flexibility of an agent while keeping the predictability of a controlled process.
Requirements the design must meet
- The agent must be able to act only through an explicit set of tools, each with a defined schema and its own permission scope.
- Any action that changes data, moves money or contacts a customer must pass a policy check, and high-impact actions must wait for human approval.
- A workflow must survive process restarts and model errors, and must resume without repeating a completed action.
- Content read by the agent must be treated as untrusted data and must not be able to change its instructions or permissions.
- Every plan, tool call, approval and result must be recorded so that a run can be reviewed and replayed.
- Spend and run time must be bounded per workflow, with a clear hand-over to a person when the agent cannot proceed.
The design
Components
Reason
- 01
Trigger
Event, schedule or user request
- 02
Plan
Break the goal into bounded steps
- 03
Tool calls
Read-only lookups via typed tools
- 04
Draft action
Proposed change with its evidence
Act under control
- 01
Policy check
Limits, permissions, risk rating
- 02
Human approval
Required for high-impact actions
- 03
Act
Idempotent write to target system
- 04
Verify
Confirm the result, retry or roll back
- 05
Audit
Every step logged and replayable
Trigger and intake
Workflows start from an event, a schedule or a user request, and each start is recorded with a unique run identifier. Intake normalises the input, extracts attachments and classifies the request type. Requests outside the supported types are routed straight to a person instead of being attempted.
Durable workflow engine
A workflow engine holds the state of each run and records every step as it completes. If a worker crashes or a model call times out, the run resumes from the last completed step. Timers, retries with backoff and waiting for a human are all expressed as ordinary workflow steps.
Planner and agent runtime
The agent receives the goal, the available tools and the relevant policy, and produces a plan as a bounded sequence of steps. The runtime limits iterations, tokens and elapsed time, and stops the run when a limit is reached. The agent proposes actions; it does not execute writes directly.
Tool gateway
Every tool is a typed function with a validated input schema, exposed through one gateway. Read tools and write tools are separated, and each call runs with the narrowest credential that will work. Write tools require an idempotency key derived from the run and step, so a retried step cannot apply twice.
Policy and guardrail layer
Proposed actions are evaluated by deterministic rules outside the model: value limits, allowed targets, required fields and a risk rating. Inputs and tool results are checked for injected instructions and for sensitive data before they reach the model. The outcome is one of three: allow, require approval or reject.
Human approval
When approval is required, the reviewer sees the proposed action, the evidence the agent gathered and the reasoning behind it. They can approve, edit or reject, and their decision is recorded against their identity. Requests that are not reviewed within a set time are escalated, not auto-approved.
Audit and evaluation
Each run stores its inputs, plan, tool calls, model responses, policy decisions and approvals as a trace. The same traces form a regression set: recorded cases are replayed against new prompts or models before they are released. Reviewer edits and rejections are tracked as a signal of where the agent needs improvement.
Trade-offs
Design decisions
| Decision | Why |
|---|---|
| A constrained agent inside a workflow, not an autonomous agent | Full autonomy handles novel cases and is difficult to test or bound. Placing the agent inside a defined workflow limits what it can attempt and gives up some flexibility, in exchange for behaviour that can be reasoned about, evaluated and explained after the fact. |
| Policy enforced in code, outside the model | Instructions in a prompt are guidance that a model usually follows and can be talked out of. Limits and permissions are therefore checked by deterministic code that the model cannot influence, which means some rules are stated twice, once as guidance and once as enforcement. |
| Human approval scoped by risk, not applied to everything | Approving every action removes most of the benefit of automation and trains reviewers to click through. Approving nothing is unsafe. Rating actions by impact keeps people involved where a mistake is costly and lets low-risk, reversible actions proceed. |
| Durable execution with idempotent tools | Agent runs are long, and model and network calls fail routinely. A workflow engine adds infrastructure and a programming model to learn, and it is what prevents a retry from sending the same payment or email twice. |
| Read tools and write tools separated by credential | A single broad credential is simpler to configure. Separate scopes mean that an agent misled by malicious content during the evidence-gathering phase holds no write access at that point, which contains the effect of a prompt injection. |
Intended outcomes
- Routine cases completed without manual handling, with exceptions routed to people
- Actions that stay within defined limits regardless of what the model proposes
- Runs that can be reviewed step by step and replayed for testing
- Reviewers who see evidence and reasoning alongside each request for approval
What the design is built to achieve. Illustrative, not measured results from a client project.
Representative technologies
- Python
- FastAPI
- TypeScript
- LLM APIs
- Durable workflow engine
- PostgreSQL
- Redis
- Kafka
- Kubernetes
- OpenTelemetry
Have a system that needs to work in production?
Tell us what you are building. An engineer will read it and reply within two working days.