// build
Agentic AI for Business: Agents That Act in Your Systems, Under Governance
The model already drafts the right action. Someone in your building now has to decide whether it is allowed to press the button. In which systems, on whose credentials, and how far it can get before a person sees what it did. That decision is the engagement. What we build around the model is permissions, dry-run, an audit trail and a human gate on anything irreversible. The blast radius stays small enough to survive a bad day.
This page covers multi-step systems that act in your CRM, your billing or your ticket queue and choose their own route through them. It is not a chatbot bolted onto a product. That is AI integration, which has its own page. It is not fixed-sequence internal work either. That is our AI automations line, cheaper and more predictable, and we will tell you when it is what you actually need.
The honest version of that second boundary: an automation is governed too. Every system we build that acts on business data gets approval gates, logging and an evaluation suite. An automation’s actions are written down in advance, so its controls are a matching list. Short enough to agree in a scoping call. An agent’s are not. Nobody can enumerate in advance what a system that plans its own route will decide to do. So the controls have to bound an action set instead of annotating one. Credentials scoped per action, dry-run, spend and rate ceilings, and an audit trail detailed enough to reconstruct a decision six weeks later. That work is most of the budget. It is also why this is a separate line and not a bigger automation.
When an agent is the right answer
An agent earns its cost in one situation. The sequence of steps cannot be written in advance, because it depends on what the agent finds. A refund that may or may not need a shipping lookup first. A ticket that turns out to be a billing problem, a bug, or neither. A supplier email that contains a price change, a stock-out, or a question for a human.
If you can draw the flowchart, you do not need an agent. You need a script with a model in one box of it. That is a smaller engagement and we will recommend it.
What the controls have to do here
Five of them, and each exists because the agent’s next move is not knowable when we write the code.
Permissions
Every agent gets its own credentials, scoped to a written list of actions. Never a human’s account, and never an admin token because it was faster on the day. OWASP’s Top 10 for LLM applications lists Excessive Agency as an entry in its own right. That is an agent holding more functionality, permissions or autonomy than its task requires. It is the first thing we design against, because it is what turns a small mistake into an expensive one.
Dry-run
Before anything is live, the agent runs in a mode where nothing happens. It emits the exact call it would have made, with the endpoint, the arguments and the record ids. You read a week of those before we switch anything on. Dry-run then stays in production, because it is also how a prompt change gets tested without testing it on customers.
Audit trail
Every plan, tool call, argument, result and retry is written append-only, and it is readable by the person who owns the business system. An engineer with log access should not be the only one who can read it. When someone asks in six weeks why a customer was credited twice, that answer has to be retrievable in minutes. An agent whose actions cannot be reconstructed afterwards is one your finance team is right to refuse.
Human-in-the-loop where it is irreversible
We classify every action as reversible or not, in writing, before we build. Moving money, mailing a customer, deleting a record, publishing, and anything that reaches a third party are irreversible by default. Those get an approval step routed to the human who owns that system, with defined behaviour on timeout. An approval that quietly expires into a yes is worse than no approval at all.
Blast radius
Rate limits, spend caps, a ceiling on actions per run, and a kill switch a non-engineer can reach. The question we design to is not whether it will go wrong. It is how much it can do between going wrong and someone noticing.
How these systems actually fail
Being specific about this is part of the offer.
Prompt injection. An agent that reads untrusted text can be instructed by that text. Emails, tickets, web pages, supplier PDFs. There is no known general defence. The mitigation is architectural. What an injected instruction can accomplish is bounded by the agent’s permissions, not by its judgement. If reading a hostile email can at worst produce a draft a human rejects, the attack is a nuisance. If it can issue a refund, it is a breach.
Silent drift. A model upgrade, a schema change or an unfamiliar edge case alters behaviour without anything raising an error. This is why the evaluation suite is built from your recorded real cases and runs before every deploy. We keep running it after launch instead of handing it over as a one-off artefact.
Compounding error. A ten-step plan whose steps each succeed most of the time is not a system that succeeds most of the time. Long autonomous chains are where a demo beats production, so we keep chains short, checkpointed and resumable.
Automation complacency. Once the agent is usually right, the human approving its actions stops reading them properly. So the approval screen shows the diff and the evidence, never a bare yes-or-no button. We still expect approval quality to decay. That is a reason to keep the irreversible list short, and not a reason to trust the gate.
Four refusals, in writing
No production write access in the first week, however keen anyone is. Read-only, then dry-run, then the reversible actions, in that order, and each stage has to produce evidence before the next one starts.
If a deterministic script already does the job, we say so and do not build the agent. That conversation belongs in scoping, where it costs a meeting instead of a quarter.
A failure rate is something we measure, not something we quote. Ask before your cases have run through the evaluation suite and what comes back is the measurement plan. The number arrives after the cases do.
And nothing gets handed over that your own staff cannot pause, audit or reverse without calling us. If you need us to turn it off, we built it wrong.
What you get
- An action inventory agreed before any code: every action the agent may take, each classified reversible or irreversible
- Its own least-privilege credentials scoped to that inventory, never a human account and never an admin token
- A dry-run mode that emits the exact call it would have made, used in staging and kept in production afterwards
- An append-only audit log of every plan, tool call, argument, result and retry, readable by the person who owns the business system
- Approval gates on irreversible actions, routed to the owner of that system, with defined behaviour when an approval times out
- Rate limits, spend caps and a kill switch your own staff can reach without calling us
- An evaluation suite built from your recorded real cases, run before every deploy
- A runbook for rollback, replay and what to do on the day the agent is wrong
How it runs
- 01
Decide whether you need an agent at all
If the sequence of steps can be written down in advance, an agent is the expensive way to run a script. We check that first because the honest answer is often a smaller engagement, and finding out after the build is the costly version.
- 02
Write the permission model before the prompt
We enumerate every action, classify it reversible or irreversible, and scope credentials to that list. Permissions decided up front are a design. Permissions decided during debugging are whatever was convenient at the time.
- 03
Shadow, then dry-run, then live on the reversible subset
The agent first watches, then emits the calls it would have made without making them, then acts only where an action can be undone. Each stage answers a different question, and skipping one means finding out in production.
- 04
Widen the blast radius slowly, against evidence
We raise limits and remove approval gates one action at a time, using the audit log and the evaluation suite as the argument. Autonomy is earned per action, not granted to the system as a whole.
Questions we get asked
- How is this different from your AI automations service?
- Automations run a sequence you already know. The steps are fixed, the tool is chosen in advance, and the value is hours removed. Both services are governed. Anything that acts on your data is. But an automation's action list is written at build time, so its controls are a matching list that takes an afternoon to agree. An agent decides its own next step because the sequence depends on what it finds, so the list cannot be written. The controls have to bound what it might do instead. That is the extra cost, and flexibility is the only thing that buys it. If your process can be drawn as a flowchart, buy the automation instead.
- Why not use an off-the-shelf agent platform?
- Use one if it fits. The platforms are good at orchestration and weak at exactly the part that decides whether this is safe in your business. Least-privilege credentials per action, an audit trail your finance team can read, approval routing to the human who owns each system, and a kill switch. We build that layer, and we are happy to build it on top of a platform you already pay for.
- What happens when the agent does something wrong?
- It will. The design question is not whether but how much it can do before a human notices, and whether the action can be undone. Irreversible actions sit behind approval, everything else is rate-limited and logged append-only, and the runbook covers rollback and replay. If an incident cannot be reconstructed from the audit log, we treat that as our defect, not yours.
- Can an agent that reads our email or tickets be manipulated?
- Yes, and there is no known general defence against prompt injection. Untrusted text an agent reads can contain instructions, and models do not reliably distinguish data from instructions. We mitigate architecturally. Prompt wording does not do it. What an injected instruction can accomplish is bounded by the agent's permissions, not by its judgement. Reading a hostile email should at worst produce a draft a human rejects.
- Does it need write access to our production systems?
- Eventually, for the actions you approve, through its own scoped credentials. Not in week one. We start read-only, move to dry-run, and take write access on reversible actions first. Anyone who asks for production write access on day one is optimising for their own delivery timeline. Yours is the risk that pays for it.
- Can you promise an error rate before we start?
- No. We can promise a measurement. We build an evaluation suite from your recorded real cases and report how the agent performs on them before it goes live. It then runs on every deploy. A failure rate quoted before anyone has seen your data is a sales number. It will be wrong in the direction that favours the seller.
- Who is accountable for an action the agent takes?
- You are, which is why the audit trail and the approval gates exist and why you own them. We make every autonomous action attributable to a plan, a trigger and a permission grant. Accountability then comes down to reading the log, and nobody has to reconstruct intent.