Human HUM·APL·01
Accounts payable lead
approves payments, owns supplier relationships
Foundation
Agentic AI engineering
We build AI agents for companies that answer to regulators, auditors and their own customers. Each one is scoped like a new hire, tested before launch and watched in production.
Workflow first
We use an agent only where the path cannot be written down in advance. Everything else becomes a workflow: a fixed sequence of model calls and code, cheaper to run and easier to audit.
In a regulated process, the workflow is the default and the agent has to earn its place.
In stage 01 we ask whether a person can draw every branch of the process on a whiteboard. If they can, we build those branches. If the next step depends on what the last document said, and the branches are too many to list, an agent can earn its extra cost.
Five patterns we use
Chain
Use it whenThe task splits into fixed steps, each checkable before the next starts.
Router
Use it whenRequests fall into clear types that need different handling or a different model.
Parallel checks
Use it whenIndependent checks run at once, or several runs vote on one answer.
Orchestrator and workers
Use it whenThe subtasks only become clear once the work has started.
Evaluator and optimiser
Use it whenA second model grades the output against criteria written in advance.
Most systems combine two or three. Atrium, our accounts payable prototype, passes each invoice through five role-bound agents: reading, matching, supplier language, fraud and compliance, and exceptions. An agent that is unsure stops and opens a decision request for a person.
The agent persona card
Every agent gets a card before we write code: its job description and the contract it runs under. Your accountable owner signs it. The card is our own working method.
| Field | What it says |
|---|---|
| Role | The job in one sentence |
| Reads | What it may see, and never sees |
| May | What it does on its own |
| May not | What stays with a person, whatever the model could do |
| Hands over when | The triggers that stop it, and the named role that receives the case |
| Proves | What it logs, so every decision can be reconstructed |
| Autonomy | Its rung on the autonomy ladder |
Agent AGT·INV·01
Invoice agent
Autonomy · rung 3 · Act with approval
- Role
- reads, matches and prepares supplier invoices for payment
- Reads
- invoices, purchase orders, goods receipts, the supplier master record; never payroll or employee bank data
- May
- match an invoice to its order and goods receipt, code it, flag mismatches, draft the supplier query
- May not
- release a payment, change supplier bank details, approve its own exceptions
- Hands over when
- the amount is above CHF 10,000, the supplier’s IBAN has changed, or a document is missing
- Proves
- every step logged with the documents it used and the rule it applied
The autonomy ladder
The evaluation shows what the model can do; autonomy is the permission your organisation grants.
Rung 1 of 4 · Invoice agent
Assist
- Invoice agent
- reads each invoice and drafts a match summary
- Person
- does the matching and coding
- Decides each case
- Person
At every rung, releasing payments and changing bank details stay with a person. Your accountable executive chooses the rung; an agent moves up only when its evaluation results support it, and down after an incident.
The evaluation comes before the build
In stage 02 we collect cases from your process, including the ones that went wrong, agree with your experts what a correct outcome is, and freeze the set before the prototype exists. We grade the outcome, whatever the wording, and run each case several times: an agent that fails on the third run has not passed.
| Case | Run 1 | Run 2 | Run 3 | Result |
|---|---|---|---|---|
| Case 01 | Pass | Pass | Pass | Passed |
| Case 02 | Pass | Pass | Pass | Passed |
| Case 03 | Pass | Pass | Fail | Not passed |
| Case 04 | Pass | Pass | Pass | Passed |
| Case 05 | Pass | Pass | Pass | Passed |
For the Invoice agent, the set would include a duplicate invoice sent twice under different numbers, a partial delivery and a changed IBAN in an otherwise routine email. AI guardrails describes how sets are built and graded.
Tools and context
Tools are designed like an interface for a new colleague: clear names, narrow scope, and answers that carry only the fields the next decision needs. Each tool has the narrowest permission that does the job, so a tool that reads purchase orders cannot write to them. Documents are retrieved only when a step needs them, and personal data never enters the context. FoodHalo’s coach follows the same rule: it looks up nutrition figures through tools and may not state a figure it did not retrieve.
Guardrails
Tools carry the narrowest permission that does the job.
Personal data is removed or aliased before it reaches a model, and restored only on your side.
Instructions inside documents and emails are treated as data, never followed as commands.
Payments, bank details and anything irreversible pass through a human approval queue.
Every agent has a stop control a named person can use, and each stop is logged.
Running it
Once live, you see the dashboard we see: traces of every run, cost per completed task, handover rate and drift against the evaluation set. A rising handover rate is often the first sign that suppliers, documents or rules have changed. Every quarter we review whether the agent still pays for itself and whether its rung should change.
Built in the lab
| Build | Label | What it shows |
|---|---|---|
| Atrium | Working prototype | Five role-bound agents for accounts payable, a human decision queue, a duplicate-invoice check that uses past work as memory |
| kredis | Beta | Agents draft counterparty risk assessments; nothing cleared or rated without a recorded human approval; key actions need two people |
| Allergen evaluation harness | Internal build | 117 adversarial cases, including euphemism and social-engineering classes; 100% pass rate to merge |
| Anonymise before inference | Internal build | Aliases replace personal data before any model call; an independent check fails the run on a leak |
| A multi-channel AI concierge | In production | Five channels, cost-aware routing across model providers, a staff dashboard estimating cost per channel |
In the six stages
Agents are designed in stage 01, evaluated in 02, engineered in 03, piloted in 04, extended in 05 and operated in 06. The persona card is drafted in stage 01, tested in 02, signed before go-live in 03 and reviewed every quarter.
Used by
Questions
When do you recommend an agent instead of a workflow?
Only when the path through the task cannot be written down in advance. If the steps are known, a workflow of model calls and code does the job more cheaply and is easier to audit. In regulated processes the workflow is our default.
Who decides how much an agent may do on its own?
Your accountable executive chooses the rung on the autonomy ladder and signs the persona card. We recommend a rung from the evaluation results, and an agent moves up only when new results support it.
Can an agent release a payment or change master data?
Not on its own. Payments, bank details and anything that cannot be undone pass through a human approval queue at every rung of the ladder.
Which models do you use?
The one the evaluation supports for each step, within the hosting option agreed for your data. The model sits behind a provider abstraction, so a successor can replace it once it passes the same evaluation set.
What happens when the model provider updates a model?
The new version runs against the full evaluation set before it handles live work. If it regresses on any case that matters, the current version stays in place until the regression is fixed.
Related
Have a process an agent could take on?
In 1-2 weeks you know whether an agent, a workflow or neither is the right answer.
See the AI Opportunity Assessment