back-office agents
AI agents that clear your queues, live in 14 days
Somebody in your company reads a ticket, opens three systems, copies fields between them and writes a note. That is work an agent does well, and we build it: typed tool calls into Salesforce, SAP, Jira, your AS/400 or your own API, an approval step on anything that writes, and a log per decision showing what it read and why it acted. The first workflow takes fourteen days, and the second is faster because the adapters are already there.
14 days for the first workflow; the second is faster because the adapters exist
The RPA script is struck through because it breaks the day a vendor moves a button. Adapters go through APIs, and where there is no API we build one.
Manual queue
People triage tickets, copy between systems and follow a runbook that lives as a PDF.
- ticket queuehumans triage
- copy-paste between systemsmanual
- runbook.pdftribal knowledge
- RPA scriptbreaks on redesign
Gated agent
One agent, typed adapters, an explicit approval step, one audit line per decision.
- agentGo · tool calls
- system adapterstyped
- human approvalexplicit gate
- audit trailper decision
14 days for the first workflow; the second is faster because the adapters exist
How the work goes
- 01days 1–2
Pick the workflow by arithmetic
Volume times minutes per case, minus the cases that will still need a person. We do that multiplication with you on the first day and start with the queue that pays back fastest.
- 02days 2–5
Write the adapters
Typed calls into your systems, with the failure modes handled: rate limits, half-written records, the endpoint that returns 200 with an error inside the body.
- 03days 5–10
Run it in shadow
The agent proposes, a person decides, and every disagreement goes back into the eval set. Nobody's job changes yet and you get a real accuracy number on your own cases.
- 04days 9–14
Open the gate one action at a time
Actions with a clean record and a small blast radius go automatic first. The rest stay gated for as long as you want them gated, including permanently.
What the platform does, what a person does
| What the platform does, what a person does | Who does it | Notes |
|---|---|---|
| Reading the runbook and the ticket history | Platform | Including the cases that were handled contrary to the runbook, which are the interesting ones. |
| Deciding what the agent may do without asking | Engineer | We recommend per action type. You sign, in writing, before it runs. |
| Building the adapters | Both | Generated from the API contract, then fixed by a person against what the API actually does. |
| Judging shadow-mode disagreements | Both | Automatic where the record shows the outcome, human where two of your experts would argue about it. |
| The audit trail | Platform | Inputs, tools called, decision, approver. One searchable line per case, kept whether the answer was right or wrong. |
| Escalation paths | Engineer | What the agent does when it is unsure, and who picks the case up at 6pm on a Friday. |
The people behind the agents
Dozens of migrations and more than ten years spent connecting systems that were never meant to talk to each other: SAP, Salesforce, Jira, Dynamics, an AS/400, a SOAP endpoint from 2006, a CSV dropped on an FTP server every night. Agents are the newest thing we build. The integration underneath them is the oldest, and it is the part that decides whether any of this works.
Shadow mode is the proof, and it comes before the commitment. The agent runs against your real queue, proposes, and a person decides. At the end you are holding an accuracy number measured on your own cases.
Questions we get from engineers
- How is this different from the RPA we already bought?
- RPA drives the interface, so it breaks on a redesign and understands nothing about the case. An agent calls APIs and can handle the ticket that does not match the script, which is the one your people spend their day on. The trade is that RPA is deterministic and an agent is not, which is why the gate and the eval set exist.
- What stops it doing something expensive?
- It cannot call a tool it was not given, and the tools that write are gated by default. Blast radius is a design decision made per action type, before anything runs, and it is in the document you signed.
- How do we know it is right?
- Days of shadow mode against your queue, an eval set built from the disagreements, and a per-decision log you can open when someone complains about a specific case.
- Do you need our data for training?
- No fine-tuning by default. The agent reads what it needs at the moment of the case, and what it read is in the log. If you later want a model trained on your history, that is a separate decision with its own paperwork.
- What happens when we change a system it talks to?
- The adapter is typed, so a contract change breaks the build instead of failing quietly in production at month-end. That is most of the reason we write adapters rather than let a model improvise HTTP calls.
Send us one queue
Describe the work as a person does it today, including the step where they check something. How many cases a month, and how long one takes. Those two numbers and a day are enough for us to tell you what it would save.
The form asks for case volume and handling time. Those two numbers decide most of it.