Xero shipped agentic compliance. Here's the supervisor for it.

In March 2026, Xero and Anthropic announced JAX — an agent built on Claude, accessible to all 4.5 million Xero subscribers as of May. JAX can do many things, but the headline feature is this: JAX can submit MTD ITSA updates to HMRC on behalf of Xero users. A reasoning model, exposed as a tool-using agent, with a direct line to a national tax authority. This is real engineering, and the team behind it knows what they're doing. But there's a question that hasn't been publicly addressed, and it's not a small one: who supervises JAX? The Xero terms of service disclaim responsibility for AI output (you'd expect that). The Claude Acceptable Use Policy disclaims it too (you'd expect that). The user — a sole trader with a Xero subscription — is theoretically responsible, but in practice they didn't write the prompt, they didn't choose the model, they didn't audit the categorisation logic, and they cannot reasonably be expected to inspect a submission before it goes to HMRC. The supervisor question for agentic compliance is open. This article explains how we've architected an answer at Spearhead Finance, and why we think every agent crossing into consequential domains will eventually need the same shape of answer. What JAX actually ships JAX is built on two things: Claude's reasoning, and MCP — Anthropic's Model Context Protocol, the open spec for connecting AI models to external tools and data. Xero exposes its data and operations (read transactions, categorise, generate VAT return, submit MTD update) as MCP endpoints. Claude consumes them as tools. The composition is JAX. In practice this means a Xero user can ask JAX "what's my Q1 MTD ITSA position?" and JAX will read their transactions, categorise the ones that aren't categorised, compute the position, draft the submission, and — with user confirmation — submit it. The user reviews a summary. JAX does the work. The two-way MCP integration, the productionised rollout to 4.5 million users — none of it is small. It should be taken seriously. But there are three things JAX doesn't do, and the third matters. First, JAX doesn't synthesise across multiple bookkeeping accounts. A contractor with personal SA + Ltd + property SPV has multiple Xero organisation files; JAX operates within one at a time. (That's the synthesis-gap problem; out of scope here.) Second, JAX doesn't expose a calibrated confidence score that a downstream system can act on. The model's output is the model's output. There's no formal mechanism for "I'm 92% confident; submit anyway" versus "I'm 71%; ask the user." Third — and this is the one — JAX has no qualified human supervisor in the loop for HMRC submissions. "User confirms" is the wrong shape of answer to the supervision question. The supervisor problem When an AI agent takes a consequential action, someone bears the consequence if it goes wrong. This is the part of agentic systems that doesn't compile away. In ordinary software, the user owns the action. They clicked the button, they signed the form, they hit submit. The code that ran is treated as a tool — the user remains the responsible party. This works because the user understands what they clicked. In agentic software, the user often doesn't understand what they clicked. They asked the agent to do a thing. The agent reasoned, called tools, transformed data, and produced an output. The user reviews — maybe — a summary. The mapping between the user's intent and the action the system took goes through a reasoning step the user didn't perform. For consequential actions — submitting to a regulator, moving money, sending a legal notice — this gap matters. Three parties theoretically share responsibility, and in practice none of them adequately holds it: The user can't realistically supervise something they didn't compute. The platform (Xero, OpenAI, Anthropic) disclaims liability in terms of service. The model provider disclaims liability in the model licence. The legal default in the UK is that the taxpayer remains liable for accurate submissions. But this is exactly the kind of "user takes the risk" framing that breaks at scale. If JAX makes a categorisation error that triggers HMRC enquiries across 50,000 sole traders, you can't realistically say "each of them should have caught it." That's not a supervisor. That's distributed disclaim. Real supervision has three requirements: identity attribution (we know who acted), qualified judgement (the actor is competent to assess the action), and regulatory liability (the actor carries insurable, enforceable responsibility). Without all three, "supervised by an AI agent" is a misnomer. The Authority Levels We architected TaxSync's agentic surface around four Authority Levels. Each corresponds to a class of action and carries an explicit confidence threshold. Above the threshold, the agent may act. Below, it must escalate. Level 1 — Read. No threshold. Surfaces information. Notifies that a deadline is approaching, that a client's quarterly figures look anomalous, that a tax position has shifted. Pure information; no state change. Always permitted. Level 2 — Recommend. Confidence threshold 0.65. The agent may suggest categorisations, draft text, propose actions — but the suggestion appears in a queue for human review. Below 0.65, the agent doesn't surface the suggestion at all. The threshold is chosen to keep the queue free of low-quality noise; 0.65 maps empirically to a "more likely right than not, worth a glance" recommendation. Level 3 — Prepare. Confidence threshold 0.85. The agent may take state-changing actions that are auditable and reversible — categorising a transaction, drafting a submission, posting a journal. 0.85 maps to roughly the threshold at which a competent senior reviewer would have accepted the agent's action without flagging it. Level 4 — Submit. Confidence threshold 0.95 plus per-action human approval. This is the only level that takes an irreversible external action — sending a submission to HMRC, in practice. The 0.95 is necessary but not sufficient; an authorised practice user must explicitly sign off on the specific submission. Cryptographic signing happens at this step. Three things about this architecture aren't obvious. First, the thresholds aren't model-output confidence in the naive sense. A model emitting "0.85" doesn't necessarily mean 85% probability of correctness. The thresholds are calibrated against held-out ground truth. We track agent outputs against accountant-supervised outcomes; when the agent says 0.85, it is empirically correct ~85% of the time on the population of tasks at that confidence level. Calibration drift is measured monthly and triggers re-calibration. This is genuine probabilistic calibration, not vibes. Second, why 0.95 plus human, rather than human-always? Because a human approval gate that asks the human to assess everything — including obvious slop — gets rubber-stamped within a week. The 0.95 threshold means the system asks the human to approve only submissions the system itself believes are ready. A submission scoring 0.78 doesn't get a "please approve" prompt; it gets escalated back to Level 3 with a request for more data. The human gate is reserved for the genuinely close-to-correct cases where qualified judgement is most valuable. Third, Level 4 is structurally different from the rest. It cannot be reached by confidence alone. The human approval step is a hard gate — there is no organisational override, no "trusted user" bypass, no enterprise tier that disables it. Every submission to HMRC requires an authorised practice user to actively approve. The agent prepares; a qualified human submits. The reason this is structurally different: HMRC submission is the action that creates legal exposure. Calibration alone can't carry that exposure. Only a qualified human can. The cryptographic audit chain When a Level 4 submission goes to HMRC, three things happen that don't happen in a typical SaaS application. First, the submission payload is signed with an Ed25519 private key held in HSM-backed storage and scoped to the supervising practice. The submission record stored in TaxSync includes the signature, the payload hash, and the public key identifier. Anyone — HMRC, a regulator, an auditor, the practice itself — can verify cryptographically that the submission came from the claimed practice on the claimed date. This is non-repudiation : the practice cannot later claim "we didn't authorise that" ; we cannot later claim "we didn't send that" ; the signature binds the action to an identified party. Ed25519 specifically (rather than RSA-2048 or ECDSA-P256) because it is fast on commodity hardware, has well-studied security properties, is resistant to common side-channel attacks, and produces compact signatures suitable for inclusion in audit logs without bloating storage. Second, the submission event is inserted into a hash-chained audit log . Each event references the SHA-256 hash of the previous event's content. The log forms a tamper-evident chain: altering any past event invalidates all subsequent hashes, and the alteration becomes detectable on next verification. The chain itself is signed periodically by a TaxSync platform key, providing an external anchor for its state at known timestamps. This is not a blockchain in the consensus sense. There is no distributed consensus and no need for one — TaxSync is the trusted operator of the log. The hash chain provides tamper detection, not Byzantine fault tolerance. It's the right shape for the problem. Third, the entire state at the time of submission is replayable from the event log . The categorisation history, the data sources used, the model version that did the reasoning, the confidence scores at each step, the user who approved — all reconstructable. If HMRC opens an enquiry in 2031 about a 2026 submission, the full provenance is available. The point isn't theoretical. If a Level 4 submission is contested by HMRC or by the taxpayer, the burden of proof shifts . The submission is signed. The chain is verifiable. The reconstruction is exact. The conversation moves from "let me try to remember what I did" to "here is the cryptographic record." Why accountants are the natural supervisors The fourth requirement of meaningful supervision — qualified judgement plus insurable liability — points to a specific class of supervisor: UK practising accountants. This isn't an accident of who we partnered with. It's a structural feature of the regulatory regime. Practising accountants in the UK are members of professional bodies — ACCA, ICAEW, AAT, CIMA. Each body imposes continuing professional education, an ethical code, and disciplinary procedures. Each requires members to carry Professional Indemnity insurance, typically £2 million minimum coverage per claim. Each has a complaints procedure that members of the public can invoke. HMRC operates an agent authorisation framework (the 64-8 mandate and the Agent Government Gateway). When an accountant is authorised to act on a taxpayer's behalf, HMRC's regulatory infrastructure treats the accountant as the responsible party for submissions. The legal liability and the professional liability already exist; they have for decades. This is the supervisor layer that agentic compliance has been missing. Not "a human in the loop" generically — there's no professional standard for a generic human. A qualified, insured, regulated human, operating under an existing professional framework, in a relationship that HMRC already recognises. TaxSync's Level 4 approval requirement maps onto this directly. The user who can approve a Level 4 submission is, by configuration in the system, a member of the practice with named agent authorisation against the client's HMRC record. Their approval action is cryptographically signed by the practice's keypair. Their professional body's disciplinary jurisdiction applies to the action. Their PI insurance covers the consequence. This shifts the supervision question from "can the AI be trusted?" to "can the supervisor be trusted?" — which is a question with an answer the regulatory system has been working on for a century. MCP — the integration layer TaxSync exposes its capabilities as an MCP server, conforming to Anthropic's published protocol specification. This is the same protocol JAX uses to consume Xero. The MCP surface is split by Authority Level. A token issued to a calling agent (Claude, GPT, Gemini, JAX, or another) carries an Authority Level claim. Read tools ( getTaxPosition , listDeadlines , getSubmissionStatus ) are available at Level 1+. Recommend tools ( suggestCategorisation , draftFinalDeclaration ) at Level 2+. Prepare tools ( commitCategorisation , prepareSubmissionDraft ) at Level 3+. Submit tools ( submitToHmrc ) are not exposed via MCP. They are reachable only via the authenticated practice portal, with the human-approval workflow inline. This is the architectural answer to "what if an agent tries to call Submit directly?" The answer is: the tool isn't there. There is no MCP path to HMRC submission. The supervisor gate is enforced at the protocol surface, not at runtime. For agents reading from TaxSync — JAX, or a third-party agent platform doing tax research — Authority Level scoping means the agent gets all the synthesis benefit (multi-entity beneficial-owner view, accurate categorisation, audit-chain reads) without inheriting any submission authority. Read tools are powerful; submit tools live behind the human. The MCP server is listed in Anthropic's tool registry. Comparable manifests are planned for OpenAI's Agent ecosystem and Google's Gemini extensions. The broader pattern Tax is the immediate domain because it's the business we're in. But the pattern generalises. Any agentic system that takes a consequential action — submitting to a regulator, transferring funds, sending a legal notice, modifying a medical record — eventually faces the same three requirements: identity attribution, qualified judgement, regulatory liability. The shape of the answer is the same: calibrated confidence in the AI, cryptographic non-repudiation of the action, a domain-qualified human supervisor. The interesting question is which domains already have a professional supervisor framework that can be plugged in (medicine, accountancy, law, certified financial advice) versus which don't yet (most B2C agent flows). For domains that don't, the supervisor layer needs to be constructed — and constructing it from scratch is harder than wiring into an existing one. Tax is, in this sense, an unusually clean domain to start with. The professionals exist. The regulatory framework exists. The liability infrastructure exists. The integration is the engineering work — which is what we're doing. JAX is real. JAX is good. JAX will get better. But every agentic system reaching HMRC, the FCA, the bank, the patient, the court eventually arrives at the same question: who supervises? The answer needs to be a name, a credential, a signature, a chain. That's the layer TaxSync is building. Not as a competitor to JAX — as the layer JAX, and every agent like it, will eventually need. This is the engineering shape of agentic compliance. The full technical paper covers the protocol specification, calibration methodology, key management architecture, audit chain verification protocol, and Authority Level scoping rules in detail. [Download the technical deep-dive (PDF) →] We publish engineering updates roughly monthly — protocol changes, calibration data, integration patterns. Subscribe if this is the kind of work you want to follow, or to do. [Subscribe to engineering updates →]