Business problem
A marketplace has a back office whether or not anyone has designed one. Buyers have to be invoiced for calls that actually met their settlement terms. Publisher-reported volume has to be verified before it is paid. Payouts have to be computed, bank activity has to be reconciled against both receivable and payable records, referral and commission statements have to be produced, disputed statements have to be investigated, callers have to be traced backwards through routing when something looks wrong, and dropped or misrouted calls have to be explained to the partner who noticed.
Doing that work by hand is not hard in the sense of being intellectually difficult. It is hard in the sense of consuming days: exporting, cross-referencing, attributing calls across buyers, verticals and pay cycles, and rebuilding the same context every month. In a company where the person doing the reconciliation is also the person defining the product, that time is the binding constraint on everything else.
The obvious response is automation, and the obvious automation is wrong. These workflows end in irreversible external actions — an invoice sent to a customer, a payment released, a locked billing value overwritten. Handing those to a system that is fluent and occasionally wrong is strictly worse than doing them slowly.
Why this was difficult
Financial work has no partial credit. An analysis that is 95% right is not 95% useful; it is an invoice that has to be retracted and a customer relationship spent on an apology.
Sources disagree, routinely and legitimately. The platform’s own records, the bank, the accounting system and a partner’s statement will all describe the same month differently — because of timing, because of disputes, because of how each system defines a conversion. Resolving that is not a lookup, it is a precedence rule, and if the rule is left implicit the agent invents one.
An agent that guesses is worse than no agent. The failure mode is not an error message; it is a plausible number in a spreadsheet cell that a human then treats as verified because it looks like everything else.
Irreversibility is asymmetric. Reading is free, drafting is cheap, sending is permanent. The operating model has to draw its boundary at that asymmetry rather than at some notion of task difficulty.
Knowledge decays. Entity maps, pay cycles, partner terms and account mappings change. A knowledge base that was accurate in May and unmaintained in July is a confident source of stale answers.
PII is present throughout. Caller numbers, recordings and partner data run through these workflows, and the handling rules cannot depend on the agent choosing to be careful.
My responsibility
I designed the operating model and I am the human inside it.
That means I authored the durable business knowledge the agent works from — entity maps, account and pay-cycle mappings, partner terms, the definitions of each financial concept — and the source-precedence rules that say which system wins when two of them disagree. I wrote the task playbooks: the ordered, repeatable procedure for an AR close, an AP verification, a payout computation, a bank reconciliation, a commission statement, a reverse caller-ID investigation, a routing forensic, a performance report and a statement dispute. I defined the PII handling rules and the financial guardrails, including the two prohibitions that define the whole system.
And I am the approver. Every write the agent performs is one I reviewed. Every invoice is one I sent. Every payment is one I made.
Constraints
- AI may not send external communications. No invoice, statement or message leaves this business under an agent’s authority.
- AI may not move money. No payment, no release, no transfer, at any confirmation level.
- AI may not overwrite locked billing values. Financial records that have been finalized are not writable by the agent under any playbook.
- Writes are limited to specifically allowed OPEN or draft records, after approval. The agent’s most privileged action is creating something a human must still act on.
- Evidence or escalation. Where the sources do not support a conclusion, the agent escalates rather than estimating.
- Everything is documented. Each engagement leaves a record of what was asked, what was read and what was approved.
Architecture
The system is a stack of things the agent is allowed to know and do, and it is deliberately front-loaded: most of the design effort went into the layer beneath the agent rather than the agent itself.
At the base sits durable business knowledge — entity maps, operating rules, task playbooks, source-precedence rules, PII rules and financial guardrails — plus the MCP tool surface that provides read access to the marketplace, billing, telephony and accounting systems. That layer is what makes a request like “close June receivables” resolvable at all: it defines which population of calls counts, which term qualifies a conversion, which buyer each call attributes to, and which source wins when the platform and the accounting system differ.
The agent operates over that base to produce analysis, reconciliation and draft work. Then it reaches the preview and escalation boundary, which is the load-bearing part of the diagram. Nothing crosses it implicitly. On the far side, an approved and specifically permitted OPEN or draft record may be created — and after that, a human sends, pays, or performs the reserved action.
Important decisions
Source precedence is an explicit rule, not a heuristic. For every financial concept there is a defined winner when sources disagree, written down before the disagreement happens. This is the single change that made agent-produced reconciliation trustworthy, because it converts a judgement call into a documented rule that I can be wrong about visibly rather than the agent being wrong about silently.
The write ceiling is an OPEN record. The most the agent can produce is a draft that a human must still act on. There is no configuration in which that ceiling rises, which means no incident can begin with “the agent was allowed to send it”.
Playbooks are versioned artifacts, not prompts. A close is a procedure with steps, sources and checks. Writing them down made the work repeatable, made the agent’s output comparable month to month, and turned improvements into edits to a document rather than tribal memory.
Refusal is a specified behaviour. When the evidence does not support a value, the agent escalates. Later, a roughly $21.1K line could not be verified from the available sources and the system declined to assign it a value rather than produce a defensible-looking estimate. That was the designed outcome, and it is the behaviour I would keep if I had to give up every other control.
Read-only by default; writes are the exception. Most engagements never propose a write at all. Investigations, forensics and reporting — the majority of the work — carry no mutation risk and therefore carry no approval overhead.
Every engagement is documented. The record is what makes the model auditable and what makes the 88-engagement figure a count of real work rather than an impression.
AI and agent usage
The agent works through the internal operator MCP described in the agentic AI case study — roughly 120 typed tools over production marketplace, financial and diagnostic data, each scoped and permissioned, with mutations subject to two-turn confirmation and audit logging. DCE-Ops is the operating discipline layered on top of that tool surface: the knowledge, the precedence rules, the playbooks and the human authority boundary.
The division of human attention across the ten-week window is the honest summary of what this system does. Read-only investigations — why did this call not route, which publisher does this caller belong to, what does this buyer’s disposition data actually say — typically cost me a few minutes of attention. Write-related workflows, where I review a proposed OPEN record before approving it, typically cost 10–15 minutes of review and approval. What used to be days of my sequential effort became a request, an interval in which I was doing something else, and a review.
Results
Across the measured ten-week window there were 88 documented operational engagements, roughly nine per week, spanning buyer AR close and invoicing, publisher AP verification, payout computation, bank reconciliation against both receivables and payables, referral and commission statements, reverse caller-ID forensics, dropped-call and routing investigations, partner performance and disposition reporting, statement reconciliation and communications drafting.
The June accounts-receivable close is the clearest single example.
Manual operating model
Export call data across buyers, verticals and pay cycles. Determine which calls met each buyer’s settlement terms. Attribute conversions to the correct buyer, campaign and period. Cross-check against the accounting system and the bank. Assemble per-buyer invoices by hand. Days of sequential work, most of it mine, with the accuracy of the result depending on my attention at the end of it.
AI-native operating model
One request against the playbook. Autonomous read and analysis across the call population and the financial sources. A preview of the proposed close, per buyer, with the qualification logic visible. My review and approval. Creation of OPEN invoices only. Then I send them myself.
That close covered 14,457 calls analyzed, 3,114 converted and billable calls, 19 invoices and $48,423.37 in total receivables.
One precision worth stating plainly, because it is the claim most portfolios in this territory overstate: the elapsed time of these workflows is not always minutes. Analysis over a full month of call data takes as long as it takes, and a close still spans a working session. What compressed to minutes is my personal attention — the portion of the elapsed time that requires me. That distinction is the entire economic argument of this system, and inflating it into “a multi-day close now takes minutes” would be the kind of plausible-sounding overstatement the rest of this portfolio exists to avoid.
What I learned
The knowledge layer is the product. I initially thought the leverage was in the tools. It is not — the tools were the easy part. The leverage is in the entity maps, the precedence rules and the playbooks, because those are what convert a capable model into a colleague who knows how this specific business works. They are also the part that decays, and maintaining them is real recurring work rather than a one-time setup cost.
Refusal was the feature. The most valuable behaviour this system exhibited was declining to produce a number it could not support. Fluency makes an unsupported value indistinguishable from a supported one at a glance, and the only durable defence is a system designed to stop rather than to fill the cell.
Reserving actions is cheaper than governing them. For sending and money movement I considered a heavily gated flow with confirmations and ceilings. Removing the capability entirely turned out to cost me a few minutes per cycle and removed an entire category of risk, along with the ongoing burden of proving the gate still works.
What I would change. I would build the engagement log as a first-class artifact from day one rather than reconstructing the count later, and I would put explicit freshness dates on every entity map and playbook, so that stale knowledge announces itself instead of being discovered in the middle of a close.