Not every AI workflow needs an agent
A conventional workflow follows a defined path: receive a form, validate fields, create a record and send a notification. An intelligent agent uses a model to select actions based on the task and information gathered along the way. It might search an order system, inspect a delivery exception and request clarification before recommending a remedy.
That flexibility is valuable when the path cannot be fully specified in advance. It is unnecessary overhead when a simple rule already solves the problem. Use deterministic code for calculations, permission checks and known branching logic. Let a model interpret ambiguous requests or choose among a limited set of tools. Most useful business systems combine both approaches rather than replacing every rule with a prompt.
Build a small, bounded loop
A basic agent needs a model, task instructions, tool definitions, working state and a stopping rule. The model proposes an action; your application validates the request, executes the authorised tool and returns a result. This loop continues until the task is complete, the agent needs help or a resource limit is reached.
For an accounts-receivable pilot, give the agent read access to invoice status and approved customer correspondence. Let it draft a follow-up, but require a person to approve sending. Exclude bank-detail changes, credit adjustments and payment execution. The outcome is specific: a reviewed reminder supported by the correct invoice data, not “manage collections autonomously.”
Frameworks such as LangGraph support explicit state and durable execution patterns. Provider SDKs can simplify model and tool integration. A small custom state machine may be easier to audit for a narrow process. Choose on checkpointing, observability and recovery needs; a framework does not supply business permissions automatically.
| Level | Agent can | Required control |
|---|---|---|
| Read | Retrieve and summarise | Document-level permissions |
| Draft | Prepare a proposed change | Review before execution |
| Act | Perform limited approved actions | Policy checks, audit and recovery |
Make tool safety an application concern
Never rely on “do not do anything dangerous” as your security boundary. Each tool should accept a strict schema, validate identifiers and enforce the requesting user’s permissions outside the model. Prefer a narrow action such as “create draft reply” over unrestricted database access. Keep API secrets in the application environment, not in the model’s context.
Retrieved documents and tool responses are untrusted data. A malicious email can contain instructions to reveal files or change payment details. Separate source content from system instructions, constrain available tools and block unauthorised destinations. These controls reduce prompt-injection risk, but no single prompt or filter makes it disappear.
Use idempotency keys for write operations so retries do not create duplicate tickets or payments. Record action inputs, approval decisions and outcomes with appropriate redaction. Approval must apply to the exact action and data that will execute; if the proposal changes after review, request approval again. For irreversible actions, define a human escalation path before launch.
Measure completion, not conversation
Set a maximum number of steps, elapsed time and spending budget per run. An agent that repeatedly searches the same system should stop and explain what it could not resolve. Track correct completion, unnecessary escalation, unauthorised action attempts, tool errors and reviewer time. Keep failed traces: they often reveal missing workflow design rather than weak language generation.
Start in shadow mode, where proposals are compared with human decisions without affecting live records. Move to reviewed drafts, then permit low-risk actions only after meeting written thresholds. Test unavailable tools, stale records, conflicting instructions and interrupted execution. A demo that handles one ideal request proves very little about recovery.
Multi-agent designs can separate specialist tasks, but add coordination, latency and debugging costs. Begin with one orchestrator and clear tools. Add another agent only when an evaluation demonstrates a specific improvement. The practical goal is not maximum autonomy; it is the smallest amount of autonomy that delivers a reliable, auditable result.