Most enterprise AI programmes start with the wrong shape of work. They look for tasks that are repetitive and well-defined, automate those, and then find that the repetitive well-defined tasks were already automated years ago by someone with a rules engine. The residue — the work that consumes the actual headcount — is case work: items that arrive incomplete, involve several systems and several people, and end in a judgement.
A complaint. A service incident. A disputed charge. A supplier onboarding that failed screening. A benefits appeal. Each one is a small investigation with a deadline attached.
This is the natural home for AI agents in enterprise operations, and also the place where a badly designed agent does the most damage — because a case management system is a system of record, and anything an agent writes into it becomes evidence.
Where the time actually goes in a case
Ask a case handler where their day disappears and the answer is almost never “deciding.” Deciding takes a minute. The rest is:
Reconstructing the file. The relevant facts are spread across a CRM record, an email thread, a scanned attachment, a note in a core system, and a policy document that has been revised twice since the case opened. Assembling that into a coherent picture is the bulk of the effort on any non-trivial case.
Establishing what is missing. Half of case work is discovering that a required document was never received, that a field contradicts another system, or that the customer answered a different question from the one asked.
Chasing. Requesting the missing item, waiting, following up, re-checking whether it arrived.
Restating. Writing the summary the next handler, the approver, or the regulator will read — usually reconstructing the picture already assembled at step one, because it was never captured durably.
Every one of those is retrieval, comparison, extraction and drafting. Every one is work an agent can do well. The judgement in the middle is the part that should stay where it is.
The agent workflow that works
A case-handling agent design that survives contact with production tends to look like this.
Intake and classification. The agent reads whatever arrived — a form, an email, an attachment, a call transcript — and proposes a case type, priority, and applicable policy or product. Classification is proposed, not asserted: the case type drives the deadline and the obligations, so a silent misclassification is a compliance failure, not an inconvenience.
Evidence assembly. The agent pulls related records from the systems it is permitted to read, extracts the fields the case type requires, and builds a structured file where every fact carries a citation back to its source. This is the step that repays the effort, and it depends entirely on private retrieval over the organisation’s own documents rather than on the model’s own knowledge.
Completeness and conflict checks. Against the case type’s requirements, the agent reports what is present, what is missing, and — the genuinely valuable output — where two sources disagree. A conflict between the amount on the claim form and the amount in the ledger is exactly what gets missed at volume and is trivially detectable by a system reading both.
Drafted actions. The follow-up request to the customer, the internal note, the recommendation with reasoning. Drafted, queued, and — depending on the consequence tier — either sent under policy or held for a human.
Escalation with a decision attached. When the agent hits a boundary, it raises the case to a human with the assembled file, the reason for escalation, and the specific question being asked.
Note what is not in the list: deciding the outcome. The agent’s job is to make the decision cheap, fast and defensible. It is not to make it.
Escalation is a design problem, not an exception handler
Most agent deployments treat escalation as what happens when the agent fails. That framing produces escalations that are useless — a case dumped on a queue with a note saying the agent could not proceed, so the human starts from nothing.
Treat escalation as a first-class output with its own contract. Four categories are worth distinguishing, because they go to different people:
Evidence escalation — the agent needs something it cannot obtain: a document only the customer can supply, access to a system it is not permitted to read, a clarification. Goes to whoever can obtain it.
Judgement escalation — the file is complete but the decision falls outside what policy determines mechanically. Goes to the case owner, with the file assembled and the specific ambiguity named.
Authority escalation — the indicated action exceeds a threshold: a value limit, a customer segment, a remedy type. Goes to the approver, and this is a human approval gate rather than a request for help.
Anomaly escalation — something about the case looks wrong in a way the agent cannot characterise: a pattern inconsistent with the case type, a source conflict it cannot resolve, a possible duplicate. Goes to a supervisor or a risk function.
Each should carry the case state, the reason code, the recommended next step and the reviewer’s decision options. An escalation that a human can action in thirty seconds is a working control. One that requires the human to rebuild the case is a queue.
The deadline clock changes the design
Case management in regulated environments runs against externally imposed timeframes — complaint handling deadlines, incident notification windows, contractual response times. This has a design consequence that is easy to miss: the agent must treat the clock as a first-class input, not a reporting metric.
Practically: the deadline is known at classification time, escalation thresholds tighten as it approaches, and at-risk cases surface before they breach rather than being reported after. An agent that produces a beautifully assembled file two days after the response window closed has automated the wrong property of the work.
It also means the escalation ladder needs a timeout. An unactioned judgement escalation is not a safe state; it is a breach forming quietly. The escalation contract should say what happens when nobody responds.
Governance: the case file is the audit trail
Because a case is a record, agent involvement in a case has to be recorded with the same rigour as human involvement — and this is where many pilots fail their first internal audit.
Three things need to be reconstructable for any case, months later:
What the agent saw. Which documents and records were retrieved, in which versions. A recommendation based on a policy that has since been superseded is defensible if you can show which version applied at the time, and indefensible if you cannot.
What the agent did and proposed. Every tool call, every extraction, every draft, with the reasoning attached. The decision record is not a debugging artefact here; it is part of the case file.
Where the human intervened. Which proposals were accepted, modified, or rejected and on what grounds. This is also the most useful quality signal the programme will produce — rejection rate by case type tells you where the agent’s coverage is thin.
The EU AI Act’s human oversight expectations point the same way for systems that materially affect individuals: oversight has to be effective, which means the reviewer must have enough context to disagree. A reviewer who can only approve or reject, with no visibility into the basis, provides the appearance of oversight rather than the substance.
Why this workload belongs inside the boundary
Case files concentrate exactly the material an organisation is most careful with: complaint correspondence, health details, employment matters, investigation notes, customer financial history. Agent-assisted handling requires the agent to read the whole file — that is the entire point of it — so the file necessarily passes through the model and the retrieval layer.
Running that on infrastructure the organisation controls keeps the material inside the security, retention and access boundary that already governs the case management system. It also removes an awkward category of question from the design: whether an external processor’s retention schedule aligns with the case retention schedule, whether cross-border transfer applies, and what sits in an inference provider’s logs. Those questions do not need better answers if the data never leaves.
How VDF AI supports case management workflows
VDF AI runs agents, models and retrieval entirely within the customer’s environment. Case agents are built as governed workflows: retrieval is scoped to the sources a given case type and role may read, tool access to case management, CRM and core systems is explicitly granted rather than inferred, and approval steps are configured per action and value threshold rather than assumed. Every execution produces a record of what was retrieved, which tools ran, what was proposed and where a human intervened — available to the case file and to audit. Escalations are modelled as workflow outputs with routing and timeouts, so an unactioned escalation surfaces rather than sits.