Four agent specialties, one job description each
Handling a case is four jobs: receiving and sorting, reading each document, checking the case, talking to your systems. We give them to four agent specialties rather than to one AI. Each has a job description written with you, and knows who to hand over to.
What splitting the work into specialties lets you do
They come from the split, not from an AI’s power: each agent knows what it does and where it stops. They are set transaction by transaction, with no development.
Require different documents depending on the transaction
Each transaction declares the documents it expects. The case agent says what is missing before the file is opened.
Check one value against another document
The name on the bank details against the one on the request, the address on the proof of residence against the one on the form. The discrepancy is named, not merely flagged.
Set automation field by field
A confidence threshold per field: above it, the agent decides alone; below it, it opens a named task. The dial is in your hands.
Name who takes over
An escalation points at a work queue and a team, not at “the business”: every undecided case has a written recipient.
Cross-check with your systems, both ways
Reference data, business databases, scoring or identity APIs, and a robot where no API exists. Every answer is recorded, status code included.
Reuse one reading across every transaction
A document agent is written once, then called on by every transaction that requires it.
The four specialties, and the passing of the baton
An inbound flow crosses four specialties, in this order. A specialty is a job; an agent is the one exercising it over a given remit. Each guarantees one precise thing to whoever comes next, the last one to your own systems — and it is that guarantee, not a scheduler, that holds the chain.
| Post | What it does | What it hands over | What it guarantees |
|---|---|---|---|
| Flow agent | Receives, splits, names | named documents | Nothing moves on before it has been named. |
| Document agent | Reads a document, extracts the data | values and doubts | Its result is written once, then called on by every transaction that requires it. |
| Case agent | Checks, cross-reads, decides | the decisions | It does not improvise, it applies a written job description. |
| Integration agent | Cross-checks, calls, injects | the result, in your systems | No outbound call is lost: each one leaves its status code behind. |
| The person responsible | Receives whatever the case agent did not decide. | their own decision | Whatever the agent did not decide reaches them by name. |
Flow agent
Receives, splits, names
- Receives the email, the scanned mail or the online upload.
- Splits the bundle and recognises each document, one by one.
- Opens the case, or finds the one that already exists.
- Sets aside what it cannot name, instead of guessing.
Nothing moves on before it has been named.
Document agent
Reads a document, extracts the data
- Extracts from the document what the business asked for, field by field.
- States what it is unsure of, instead of filling the gap.
- Locates each value on the page and the line it came from.
- Writes its result once, dated and attributed.
Its result is written once, then called on by every transaction that requires it.
Case agent
Checks, cross-reads, decides
- Checks completeness against the documents the case requires.
- Cross-reads the documents against one another and flags the gaps.
- Decides what can be decided inside its remit.
- Names who will decide the rest, and above which threshold.
It does not improvise, it applies a written job description.
Integration agent
Cross-checks, calls, injects
- Cross-checks values against your reference data and business databases.
- Calls your third-party APIs — scoring, compliance, identity checks — and records what they answer.
- Drafts the chaser in your own wording, and waits for a person to approve before sending.
- Injects into your IS or DMS, drives a robot where there is no API, and returns its status code.
No outbound call is lost: each one leaves its status code behind.
The job description: five lines, and they cannot lie
An agent without a job description is an automaton you hope is well tuned. It fits in five lines, written with you during scoping.
- 1
The remit
What the agent is responsible for, and above all what it is not.
- 2
The documents received
What it reads, where it comes from, and what it does when it is missing.
- 3
The decision produced
What it writes at the end: a value, a finding, a request, a refusal.
- 4
The escalation threshold
The point at which it stops and hands over rather than deciding.
- 5
The person responsible
Who receives what it did not decide — by name, not “the business”.
The job description is the configuration
There is not a document describing the agent on one side and a configuration running it on the other: they are the same object, and no path modifies one without the other. Only the fifth line, the person responsible, is read without being executed.
An operations note, by contrast, drifts from what it describes: six months later the two no longer match, and nobody notices before the audit. Here, what you read is what runs.
How an agent is measured
An agent is not judged on a global average, where the one field that slips disappears into the others. Every piece of information it produces is counted separately, and those counters set its threshold.
What is counted, field by field
How many values proposed, kept as they were, corrected, typed in by hand. And with what confidence: the average, and the lowest observed.
What those numbers set
The confidence threshold of that field, and that field alone — without touching the other fields or the other agents.
What it makes visible
An agent that degrades shows up on its own counters, down to the field. Durations follow the same rule.
98.1 % of the documents in a bundle are settled without anyone reopening them. The second level says which field sent the remaining 1.9 % for review.
| Field | Share of reviewed documents | Share of all instances |
|---|---|---|
| Address | 24 % | 0.46 % |
| Gross amount | 17 % | 0.32 % |
| Signature date | 14 % | 0.27 % |
| Policyholder name | 12 % | 0.23 % |
| IBAN | 11 % | 0.21 % |
| Payment method | 9 % | 0.17 % |
| ID document · validity | 8 % | 0.15 % |
| Contract number | 5 % | 0.10 % |
One transaction in production. Another transaction, another corpus or another threshold setting will read differently.
The operating views, on your own transactions
Volume, people, timing, what blocks. A few examples among others — the figures are yours.
The flow of a queue
What comes in and what goes out, week after week.
How it spreads over people
Who carries what, in the team’s own order — to dispatch, not to rank.
Handling times
The current, and the tail.
Why a case stops
What stopped a case, named by the agent that met it.
The automation rate
How it moves, against the threshold you set.
Confidence, field by field
Where each field sits, and which one needs a tweak.
Nowhere near a complete list: every counter an agent produces can be read, crossed and tracked, on your transactions, your queues and your thresholds.
Specialization, at two scales
The same reasoning holds twice: once for the model, once for the arrangement of the posts.
On a narrow domain, specialization counts for more than size
On a narrow document domain, size is not the accuracy lever it is assumed to be: specializing buys seven times what doubling the size buys, for around a hundred times less compute.
A narrow post can say what it is unsure of
An agent that reads one document, and one only, can say what it is unsure of; an agent that did everything cannot locate its own doubt. Hence twenty-nine agents for a back office, one hundred and eighty-four for an admission campaign, drawn from the same catalogue.
Splitting a bundle, reading a document, comparing two documents, chasing, cross-checking against your databases, injecting into your systems. You assemble the ones your transaction needs, and set them. Nothing to build.
More than two hundred agents work together for a single customer, on a single use case. Each keeps its narrow remit: that is what lets you add more without breaking anything, and scale as high as the process needs.
A model trained on your documents is seven times more accurate than one that is merely bigger. The same logic one level up: four narrow posts do better than an agent meant to know everything.
Footprint and cost, at scale
A specialized model is a small model. That is what keeps the bill predictable and the footprint bearable as the number of agents grows.
A compact model, so a compact bill
Around a hundred times less compute than a large general-purpose one. A single graphics card is enough, and nothing is billed per token.
Adding an agent does not add a model
The catalogue skills are shared by every agent: compute follows the volume of cases, never the number of posts declared.
Compute stays where your data is
Nothing travels to a remote service to be processed. Hosting in France or on your own premises: frugality and sovereignty, one architectural decision.
Have the job descriptions of your own process written
Thirty minutes with a Letxbe expert to break one of your business transactions into specialties and escalation thresholds.
Book a conversation