Agents that act in your systems, under your authority.

Who it’s for

This engagement is for teams with a defined process that ends in actions in business systems. The job might involve reconciling records, preparing a response or moving a case through internal tools. We start with the process owner and the authority required to do that job.

• You might have a useful pilot that now needs controlled access to production systems.
• You might need to see the evidence behind an agent’s proposed action before approving it.
• You might have a workflow whose next step depends on what it finds, with people handling the exceptions.

A broad request to “add AI” is not enough to define this build. Scoping needs a job, an owner and a way to decide whether the result is useful.

What gets built,
and where it stops.

The build centres on a bounded agent loop: inspect a case, decide what information is missing, propose a tool action and carry it through the agreed controls. Tool adapters expose narrow operations with typed inputs and scoped credentials. The model does not receive standing administrator access.

The scope includes an authority model, an approval queue with the evidence needed to decide, an action log, an evaluation suite and a pause control. For each write action, we document verification, retry behaviour and the available recovery path before enabling execution.

This service excludes general-purpose agents without a defined job, consumer chatbots and training a model from scratch. Payments and irreversible external commitments require a human decision and human execution. A request that depends on unrestricted credentials needs a different design.

If an agent needs company knowledge, that retrieval tool can be scoped with a RAG knowledge system. The deployment boundary belongs in the scope too; private AI infrastructure covers the environment your team will operate.

Compare private AI deployment options before deciding where the model and its supporting data should run.

When a simpler
alternative is better.

• A fixed path and structured inputs: use a workflow or script. Define the branches directly and keep execution easy to inspect.
• A fixed path with a judgment step: use a workflow with a bounded model call. Validate its output before the next step.
• A path that depends on discoveries: consider an agent, with an explicit tool set, stopping rules and authority limits.

We recommend the workflow when it fits the job. Scoping should establish why the process needs an agent before committing to one.

Prerequisites

• A documented API, scoped service account or another agreed access path to each target system. Browser and desktop access need their own session, permission and recovery design.
• A named process owner who can define a correct result and resolve ambiguous cases.
• Representative past cases, including incomplete inputs, duplicate requests and awkward exceptions.
• A person available to approve during the pilot, plus an escalation owner for unresolved cases.
• A written list of prohibited actions, sensitive data boundaries and conditions that should stop the run.

Separate intent
from execution.

The model proposes an action; a separate execution layer checks whether that action is allowed. Case state, approvals and tool results live outside the model’s conversation. A resumed run reads durable state rather than reconstructing authority from a prompt.

An approval binds to a specific operation, its inputs and its target. Changing the recipient, amount or proposed record diff invalidates that approval. The execution layer checks the current policy again before using a credential.

Illustrative example: an agent prepares a record correction from an incoming request. The approver sees the request, the source record, the proposed diff and uncertainty notes. If the record changes while approval is pending, execution stops for a fresh review.

Authority is a policy.
Failure needs a path.

Start with approval on consequential writes. Define action classes, allowed targets and the evidence an approver needs. An expired or rejected approval leaves the proposed action unexecuted and sends the case to its owner.

Retries and reconciliation

Each proposed write gets a stable action key. Where the target supports idempotency, the adapter passes that key through. Otherwise, the design needs a durable execution record and a way to reconcile the target state. An ambiguous timeout goes to reconciliation before a retry; an action key alone cannot make a remote operation safe.

After execution, read the system of record and compare it with the intended change. A successful tool response is not the acceptance evidence by itself. Record the observed state, a discrepancy or an unresolved result, then route the case accordingly.

Rollback and compensation

Deployment rollback restores a previous version of the agent’s software or configuration. It does not reverse an action already taken in another system. Action compensation is a separate, domain-specific operation: restore a prior field value after a conflict check, issue a correction or ask a person to repair the record.

Some effects cannot be reversed. A delivered message cannot be recalled by reverting the agent deployment. Scoping records those limits, assigns a human owner and keeps actions outside the agreed recovery boundary behind human execution.

Stop conditions and untrusted inputs

Set tool-call, rate and spend limits per run. Define what happens when a budget is exhausted or a dependency is unavailable. The client’s named operator holds the pause control; the runbook explains how to stop new work, inspect in-flight actions and resume after review.

Treat retrieved documents, messages and tool outputs as untrusted data. They do not grant new permissions or change policy. Narrow tools, input validation and checks outside the model form the control boundary; prompt instructions alone are not a sufficient defence.

Read how to design approval for AI agents for approver evidence, absence, execution checks and the audit record.

Deliverables
and handover.

The handover includes source in your repository, infrastructure definitions for the agreed environment, the authority model and the action-log schema. The log links a case to its proposed action, policy decision, approval, tool execution, verification and recovery outcome. Sensitive payloads and retention are defined during scoping.

Runbooks cover pause and resume, credential rotation, investigation of a failed case, controlled replay and adding a tool. The evaluation suite and an operator walkthrough complete the handover. A replay follows the same policy and duplicate-action controls as a new run.

What your team
operates.

Your team owns the approval queue, escalation decisions, pause control and credential lifecycle. It reviews log samples and runs the evaluation suite before a prompt, model, tool or policy change. The queue needs an owner and a coverage pattern agreed during scoping; human review time depends on the process and its exception load.

A new tool or broader permission is a change to the authority boundary. Review it, extend the evaluation cases and record the decision before releasing it. Ongoing support is agreed per engagement.

Agree the evidence
before the build.

Begin in shadow mode: the agent proposes actions while people perform the work. Compare proposed actions with the decisions made by the process owner, including the cases that should stop or escalate. Keep a held-out set separate from examples used to tune the system.

• Agree task-success criteria on the held-out cases, including incomplete and contradictory inputs.
• Require no unauthorised actions in the acceptance run. Test prohibited operations, expired approvals and changed inputs deliberately.
• Trace each executed action back to its policy decision and required approval. Inspect rejection, timeout and partial-failure records too.
• Exercise the agreed recovery path for each enabled write class. If recovery is unavailable, verify the human execution boundary instead of implying an undo function.
• Test the pause control, dependency failure, budget exhaustion and an ambiguous execution timeout.

A class moves from approval on each action to greater autonomy only after the agreed evidence is reviewed and the policy change is authorised. Passing a case set establishes evidence for that scope; it is not a guarantee about future cases.

Use the printable scorecard for acceptance evaluation for AI systems to agree the pass rules and who signs them.

What to prepare

Bring a short process description, representative past cases with sensitive details removed, the systems and access owners, the prohibited-action list and the approver’s name. Include a difficult failure you want the system to handle. Exact case coverage and access arrangements are settled during scoping.

Start with
the process.