The Jobs Agents Can Hold

Summary

Discussion of agents in enterprise software tends to operate one level too abstract — arguing about autonomy in general when the practical questions are specific to a job. Sorted by role, the picture resolves. Five jobs are open now in a regulated environment: reconciling records against a source for human approval, harmonising inbound data against a controlled vocabulary, watching a signal for drift, drafting a document a person then reviews, and answering a question about the organisation's own data on that organisation's behalf. Each has a different failure mode, a different cost profile, and a different architectural requirement. Three jobs are closed, and not because the technology is immature: deciding what the system should do, carrying accountability for a regulated decision, and making a judgement that has no computable answer. The distinction that predicts which is which is not difficulty. It is whether the job produces an artefact a human can check before it takes effect. Where it does, an agent can hold it under a validated process and a named machine identity. Where it does not, the job is a human one and will remain so. The common failure in practice is not agents doing work badly; it is agents holding a job nobody defined, in a system that cannot say what the agent did or why.

1. Sorting by job, not by capability

"Can AI do this?" is not answerable in the abstract, because the constraint in a regulated environment is rarely capability. It is accountability, and accountability attaches to specific acts.

So: enumerate the jobs. For each, ask what the agent produces, who checks it, what breaks if it is wrong, and what the system must provide for the arrangement to be inspectable.

That reframing does most of the work. A job whose output is a draft, reviewed before it takes effect, is a fundamentally different proposition from one whose output is an action, taken and then discovered.

2. Five jobs that are open

2.1 The reconciler

The job. Compare a set of records against an authoritative source, identify discrepancies, and propose corrections for human approval.

Why it works. The output is a proposed change list — an artefact that exists before it takes effect and can be reviewed in full. The reviewer sees exactly what would change and approves or rejects. Nothing happens on the agent's authority alone.

Failure mode. Plausible-but-wrong corrections that pass review because the reviewer is approving a long list under time pressure. The risk scales with list length, and the mitigation is presentational: cluster by kind, surface the unusual, and make the count of near-identical items obvious so attention lands where it should.

Architecture required. A defined authoritative source. A change-list artefact that persists. Approval as a recorded event with an author. An audit trail that distinguishes agent-proposed from human-approved.

2.2 The harmoniser

The job. Map inbound data expressed in someone else's conventions onto a controlled vocabulary.

Why it works. This is translation with a defined target. The controlled vocabulary bounds the output — the agent is not inventing categories, it is selecting among known ones — which makes both verification and failure detection tractable.

Failure mode. Confident mapping of an ambiguous input to a plausible wrong category. Worse than a rejection, because a rejection surfaces and a wrong mapping does not.

Architecture required. An actual controlled vocabulary, versioned. A confidence signal, so low-confidence mappings route to a human rather than through. A remediation loop for inputs that cannot be mapped, so failure has a path other than silence.

2.3 The watcher

The job. Observe a signal over time and raise attention when it departs from expectation — a temperature trace, a delivery estimate, a queue depth, a rate.

Why it works. The output is an alert, not an action. Watching is also the job humans do worst: it is continuous, mostly uneventful, and attention degrades precisely as duration increases.

Failure mode. Alert volume. A watcher that raises too much trains its audience to ignore it, which is worse than no watcher — the organisation now believes it has coverage.

Architecture required. An explicit threshold, versioned and reviewable, so "why did this alert" has an answer. A record of alerts not raised, or the absence of an alert cannot be distinguished from the absence of a watcher. Routing to someone with authority to act.

2.4 The drafter

The job. Produce a document a person then reviews, edits, and signs — a summary, a report, a correction notice, an assessment.

Why it works. Drafting is the clearest case of an artefact that exists before it takes effect. The human remains the author in every sense that matters, and the agent has removed the blank page rather than the judgement.

Failure mode. Anchoring. A well-written draft is harder to disagree with than a blank page, and reviewers correct less than they would have written differently. This is a genuine risk to the quality of the review and it is not solved by better drafting.

Architecture required. A record of what was drafted versus what was signed. Provenance in the document itself. And a review path that makes rejection as easy as acceptance — if approving is one click and rejecting requires an explanation, the arrangement is biased.

Regulatory note. A 2026 FDA warning letter concerning AI use in drug manufacturing applied existing cGMP accountability to AI-assisted work rather than establishing a separate framework.¹ The signal is that agent-drafted output is treated as the organisation's output, which is the correct reading and the one to design against.

2.5 The queryer

The job. Answer a question about the organisation's own data, asked in natural language, on behalf of a user who is entitled to the answer.

Why it works and why it is different. The agent reads rather than writes, so the blast radius is bounded by access control rather than by correctness. And it is the one job where the agent may reasonably belong to the customer rather than the vendor: given a documented interface, an organisation can point its own agents at its own data.

Failure mode. Confident answers to questions the data cannot support — a plausible number derived from a misread of what a field means. The user has no way to detect this, which makes it the most dangerous of the five failure modes despite being read-only.

Architecture required. The same access controls and audit trail as a human user, with no exception for the agent. A documented interface rather than a vendor-specific toolkit — otherwise the capability is rented rather than held. And provenance on answers: which records, which fields.

3. Three jobs that stay closed

Not because agents are not capable enough. Because of what the job is.

Deciding what the system should do. Determining the workflow, the validation rules, the thresholds. This is design, it carries organisational consequence, and it is subject to change control precisely because someone must be answerable for it. An agent can draft a proposed change — that is §2.4 — but the decision is not a drafting job.

Carrying accountability for a regulated decision. Approving a disposition, releasing a batch, signing a validation report. Regulation requires a named person who accepts responsibility. This is a legal property, not a technical one, and no capability improvement touches it.

Judgements with no computable answer. Whether a temperature excursion compromised a sample given what it will be used for. Whether an ambiguous consent covers a proposed use. These are not hard computations; they are questions where the inputs do not determine the answer and someone must exercise judgement they can defend.

The test that separates open from closed is not difficulty. It is whether the job produces something checkable before it takes effect. Reconciling produces a list. Drafting produces a document. Approving produces nothing until it is the effect — and that is why it stays human.

4. What every open job needs

Four requirements, common to all five.

A named machine identity. The agent acts as a specific, identifiable actor — not as the user who triggered it, and not anonymously. Every action is attributable to that identity, and the identity is subject to the same access controls and periodic review as a human account.

A validated process, not a validated model. What is qualified is the process the agent operates within: what it may do, what it produces, who reviews, what happens on failure. This distinction matters because a model may change while the process does not, and the process is the inspectable artefact.

An artefact that precedes effect. The reviewable thing must exist and persist. If the agent's output goes straight to effect, none of the above helps.

Logic that exists before runtime. The reason to refuse agents that generate decision logic at execution time is not distrust of the logic. It is that logic produced fresh at runtime leaves nothing to validate before it runs and nothing to inspect afterwards. The artefact requirement applies to the reasoning as much as to the output.

5. What goes wrong in practice

Not the failures people anticipate.

The undefined job. An agent is introduced to "help with" something without a defined role, boundary, or review path. Nobody can say afterwards what it was supposed to do, so nobody can say whether it did it. This is the most common failure and it is a governance failure, not a technology one.

The review that is not one. An approval step exists on paper and is a click in practice. The artefact is produced, the reviewer approves everything, and the arrangement has the form of human oversight without the substance. Detectable: measure the rejection rate. A reviewer who never rejects is not reviewing.

The silent watcher. A monitoring agent that stopped working. Nobody notices, because the absence of alerts is indistinguishable from things being fine. This is why §2.3 requires a record of non-alerts.

Capability that turns out to be rented. An organisation builds process around an agent capability that is a vendor feature rather than an interface. When commercial terms change, the capability changes with them. The defence is holding the interface rather than the service — which is the argument for §2.5 belonging to the customer.

6. Scope of the claim

Where the claim applies, and what it costs.

Five jobs is a convenient number and not an exhaustive one. These are the roles that recur in operations work. Other domains will have others, and the taxonomy is a starting point rather than a complete map.

The "artefact before effect" test is cleaner than reality. Some outputs are artefacts in principle and effectively actions in practice, because reviewing them properly is infeasible at the volume produced. A change list of three thousand items is technically reviewable and practically not. The test needs a volume qualifier.

The anchoring problem in §2.4 is unresolved. Drafting improves throughput and may degrade review quality. Anyone deploying a drafter should assume review quality falls and design compensation, rather than assuming the draft is a free improvement.

The closed list may be shorter than it looks. Two of the three are closed by regulation rather than by anything intrinsic, and regulation changes. The argument holds under current rules and is not a claim about permanence.

7. The question worth asking

Not "should we use AI here." That produces an argument about technology.

Better: what job would it hold, what would it produce, who checks that before it takes effect, and what does our audit trail say happened?

A job that survives those four questions is one an agent can hold. A job that does not is either closed, or open once the missing piece is built — and the missing piece is nearly always the artefact, the reviewer, or the record, rather than the agent.

Appendix — The five jobs compared

This paper argues from mechanism and from the structure of regulated accountability rather than from measured deployment outcomes. §6 sets out where it is weakest. No claim is made about any specific product's agent capabilities, including our own.