Human personaHUM·APL·01
Accounts payable lead
Approves payments and owns supplier relationships
Approves what the agent prepares
Foundation
Agentic experience design
When an agent joins a team, the process has two kinds of user. We design for both: the people whose work changes and the agents that take part of it on.
Two kinds of user
In an agentic process the agent is a second user: it reads your documents, calls your tools and hands cases back to people. If nobody designs its role, it gets one by accident.
So in stage 01, before any model is chosen, we design both sides. We interview and shadow the people in the process, map the work as it runs today, workarounds included, and design the future process with a lane for people and a lane for agents.
Human personas and agent personas
A human persona records what a person is responsible for, what they decide, what slows them down and what they will be blamed for if it goes wrong. In accounts payable: the clerk who matches invoices, the lead who approves exceptions, the supplier who waits for payment.
An agent persona records authority, on a one-page card from our working method that serves as an operating contract.
| Field | What it fixes |
|---|---|
| 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 |
| When access is revoked | What it can no longer do, and who picks up its open cases |
Each agent persona is paired with the human persona it works beside: the Invoice agent prepares, the accounts payable lead approves. If no pair can be named, the agent has no accountable owner, and we solve that before any build.
Paired
Agent personaAGT·INV·01
Invoice agent
Reads, matches and prepares supplier invoices for payment
Rung 3 · Act with approval
Autonomy is a permission
The evaluation measures what a model can do; your organisation decides what it may do. Our ladder has four rungs: Assist, Suggest, Act with approval, Act and report. The accountable executive picks the rung, and the card shows it: “Rung 3 · Act with approval”. An agent moves up when evaluation results and pilot evidence support it, and down after an incident. Agentic AI engineering shows what the Invoice agent does at each rung.
The human-agent service blueprint
Our blueprint has four lanes: the customer or supplier, the people who work on the case, the agents, and the systems of record. Each handoff between agent and person is a state with four properties:
- Trigger: what moves the case to a person, written as a rule a tester can check.
- Package: what the person receives.
- Response expectation: who picks it up, how fast, and what happens if nobody does.
- Record: what is logged about the person’s decision.
A handoff without a response expectation becomes a queue nobody owns, so we also design the escalation for when the named person is on holiday.
The handoff package
A good handoff keeps people alert; a poor one teaches them to rubber-stamp. Every package answers six questions.
| Question | Invoice agent example |
|---|---|
| What did the agent see? | Invoice, purchase order and goods receipt, linked |
| What did it decide? | Matched to the order; quantity does not match the receipt |
| What did it change? | Nothing posted; a supplier query drafted, not sent |
| What could it not determine? | Whether the four missing units were delivered late or never sent |
| Why did it stop? | The supplier’s IBAN differs from the master record |
| What does it recommend? | Hold payment and confirm the bank details with the supplier by phone |
With the package alone, a person should be able to decide in under a minute. In Atrium the operator approves, changes or rejects each decision request from a queue beside the live view of the agents’ work, with a keyboard shortcut for each action.
Trust calibration
We aim for reliance that matches the agent’s measured accuracy. With too much trust people stop checking; with too little they redo the agent’s work and the business case disappears.
| Mechanism | What the interface does |
|---|---|
| Visibility | Shows each step the agent took, with the documents it used |
| Uncertainty | States what it could not determine and how sure it is |
| Intervention | Keeps stop, override and correct one action away, and logs each use |
| Progressive disclosure | Summary first, full trace on request |
Our products follow the same rules: Wellsura’s recommendations carry reason codes from a fixed list, and FoodHalo shows how many signals each verdict rests on.
Agents as users
For an agent, the tool description is the interface, and a vague name or a response full of internal IDs confuses it the way a cluttered screen confuses a person. We give the agent realistic tasks, read the transcripts and note where it picked the wrong tool, misread a response or gave up. If customers or suppliers send their own agents to your systems, clear tool names, narrow scopes and short responses decide whether those agents succeed.
In the six stages
| Stage | Design work |
|---|---|
| 01 · Ground the case | Interviews and shadowing, human personas, draft agent cards, journey map, blueprint with human and agent lanes |
| 02 · Prove the value | Prototype sessions with the people from the personas; handoff screen prototyped; cards revised |
| 03 · Engineer the system | Approval queue, handoff package and stop controls built and tested; cards signed |
| 04 · Pilot in one place | Observation, interviews, override and handoff logs |
| 05 · Scale what works | Blueprint adapted per site; onboarding designed from the pilot |
| 06 · Run and evolve | Quarterly user interviews; cards updated when a rung changes |
Built in the lab
| Build | Label | What it shows |
|---|---|---|
| Atrium | Working prototype | An operator cockpit with a queue of decision requests beside the agents’ live work |
| kredis | Beta | A worklist of what needs a human now; nothing cleared or rated without a recorded human approval |
| Wellsura | Beta | Recommendations with reason codes from a fixed list |
| Tenderix | Live | A Go, No and Watch review in which every No carries a reason tag |
Questions
Is this a separate project from the engineering?
No. The design work runs inside the six stages: discovery, personas and the service blueprint in stage 01, prototype testing in stage 02, the oversight interface in stage 03 and pilot research in stage 04.
What is an agent persona?
A one-page card that defines an agent’s role, what it reads, what it may and may not do, when it hands over and its rung on the autonomy ladder. It is our working method. Your accountable owner signs it before go-live.
Who takes part in the discovery work?
The people who do the work today, the people who approve it and, where possible, the people on the receiving end, such as suppliers or customers. We interview them and watch the process as it runs.
How do you stop people trusting the agent too much?
The interface shows what the agent did, how sure it is and what it could not determine, and keeps stop and override within easy reach. During the pilot we watch override and handover rates to see whether reliance matches the agent’s measured accuracy.
Do you design for agents that call our systems from outside?
Yes. When another company’s agent uses your API or tools, it is a user too, and we review your tool descriptions and responses the way we would review a screen for a new user.
Related
Start with the people
An AI Opportunity Assessment includes the first discovery interviews and a first read of who the system serves. A full stage 01 adds the personas and the service blueprint.
See the AI Opportunity Assessment