DMA AI Revenue System

Start with one message from one visitor and follow it. Almost everything in this document is visible in that single turn: how the message is handled, what the agent can and cannot reach, when qualification happens, and what has to be true before anything is written down or sent.

Three things worth reading off it

The visitor's words and the operating instructions never travel together. The message arrives on the content channel as quoted data; the policy — who the agent is, what it may do — arrives separately and cannot be amended by anything a visitor types. That separation, plus a tool list fixed before the turn starts, is the whole of the containment story: the agent's reach is the seven tools in that box and nothing else, no matter how persuasive the message.

Qualification is not a stage somebody declares. It runs after every single turn. The transcript is re-read, A03 pulls out services, scale, timing, authority and budget signal — each one stored with the sentence it came from — and a scorer written in code, not a model, turns those facts into a number and a tier. Nobody has to notice that a visitor became interesting; the threshold does, on the turn it becomes true.

The fast path and the committing path are deliberately different. A reply is checked for unresolved claims and shown in seconds, because a prospect will not wait. Anything that changes state — a Nutshell write, a hot-lead alert, a booking, a hand-off — becomes an intent and queues for the gate, where it is re-validated against live state before it commits. The visitor is never waiting on the gate, and the gate is never rushed by the visitor.

That loop is not special to first contact. It repeats at every stage: something arrives, an agent proposes, the gate decides, a person sees the result. What changes from stage to stage is which agents are involved and how much the gate is willing to let through on its own. The stages themselves are the part to check against how DMA actually sells — if a step is missing, out of order, or never happens the way it is drawn here, that is worth saying before anything is built on it.

Three things to take from the map

The top row is the only part anyone outside DMA sees. Everything else — fifteen agents, a scoring pipeline, a mirrored database, a nightly reconciliation — exists to make those six boxes happen reliably. That is also why almost none of this system has a user interface, and why this arrived as a set of documents rather than as a demo: the parts that decide whether it works are not the parts a demo can show. Part Two, section 00 makes that case.

The gate is a single line every action crosses, not a step in a sequence. Drafting an e-mail, writing a CRM field, sending a proposal and charging a deposit are wildly different actions, and all four are re-validated, checked against DMA's rules and committed exactly once by the same piece of code. It is the first thing I would build and the thing most likely to be quietly missing from a system that demos well.

The bottom band is where the money is. Before a dormant record ever becomes a first contact, it has been read, scored, tiered and given a reason to be worth contacting today. Thirty thousand records are the fastest path to real revenue, which is why that work comes first in the build sequence rather than the website chat.

A field schema is only half the answer. The other half is a list DMA gives me: for each field, what this system is permitted to do to it. "The AI writes to Nutshell" is far too coarse a statement to build against, and I would rather be handed the boundary than infer it. It is one short document, it is yours rather than mine, and once it is signed off the gate simply enforces it. Each field carries three properties:

• May the system write it at all — deal value, close date and owner are candidates for people-only, and saying so up front is cheaper than discovering it after a bad write.
• At what autonomy — write freely, write only with approval, or propose and never write.
• What happens on collision — whether a human value is protected, and for how long.

That last property is the one that matters most in practice, and it is the mechanism behind the human-priority rule in section 07. When a person edits a field the system also writes, that field becomes theirs. The system stops writing it, keeps computing its own value, and shows the two side by side rather than overwriting. It is the honest behaviour: a rep who corrects the AI once should not have to correct it again on Thursday.

The obvious version of this leaves the lock in place forever, and over a 30,000-record database that quietly strangles the system — a year on, a third of your records are frozen by corrections nobody remembers making. So the lock has a life: it holds until the account's next substantive human touch, or a set number of days, whichever comes first. When it lapses, the system does not resume writing. It proposes, with the human value shown next to its own and the date the lock was set. The person keeps the last word; they just do not have to keep saying it forever.

The Canonical routes all seven triggers to Josh, and reading it closely that is a heavier load than it first appears: Josh also takes every trust-building video call, by a standing rule set outside the seven triggers. One person as the sole destination for every exception is a bottleneck, and the failure is silent — the escalation fires, that person is mid-call, and the deal sits.

The fix is small and it is a mapping, not a process. Each of the seven triggers points at one or more destinations, and that mapping is a setting in the Control Plane that DMA edits directly — no deploy, no ticket to me. That is the entire extent of what the system needs to know.

Deliberately, it knows nothing more. It does not track who is on holiday, run a timer, chase an acknowledgement or re-route to a backup, because Nutshell and Slack already do the human half of this better than a rule I would write in advance: the opportunity is flipped to Escalated and assigned, and from there people tag each other, watch a colleague's queue while they are out, and hand things on. Encoding coverage rules into this system would freeze an arrangement your team changes every week, and it would quietly become another place to keep up to date.

What the system owes you instead is visibility, which costs nothing to provide: escalated opportunities are a state in Nutshell, so "what is escalated and how long has it been sitting there" is a saved list rather than a feature. If DMA later wants a clock on that, it is a Nutshell automation over a field that already exists — not something to build here now.

One route does need to be populated at all times, and it is the only hard requirement: the prospect who asks for a human. That trigger has no confidence threshold and no deferral, so its mapping cannot be empty. Everything else can be left to the team.

These are estimates, and I want to be exact about what kind. The unit prices are published list prices. The token volumes per task are my engineering estimates for work of this shape, not measurements — I have not run your data through anything. The monthly volumes are assumptions about DMA, and you should correct them. Everything below can be recalculated once any of those three change, which is the point of showing the arithmetic rather than a single number.

Two model tiers, chosen per task. A cheap, fast model does the bulk reading — 30,000 records, transcripts, inbound replies, classification. A stronger model writes anything a prospect will read. Mixing them is not a cost trick; sending a reactivation email through the cheap model to save a third of a cent is a bad trade against the reply rate.

The textbook answer is an idempotency key: attach a unique token to the write, and the far end guarantees it applies once no matter how many times you send it. If Nutshell supports that, we use it and this problem is over.

It may not, and most CRM APIs do not. The failure that matters is narrow and specific: we send a write, the connection dies before the response arrives, and we genuinely do not know whether it landed. Retrying blindly gives your prospect two identical notes, or two tasks, or a duplicated activity. So the adapter carries its own answer. Every created object gets a deterministic fingerprint derived from its content and the run that produced it, written into the object itself. Before any retry, the adapter looks for that fingerprint. Found means the first attempt succeeded and the retry is recorded as a no-op. Not found means it genuinely failed and the write proceeds. For field updates the problem is easier — if the field already holds the value we meant to write, we are done.

I am flagging this rather than assuming it away because it is exactly the kind of thing that works perfectly against a simulator and then does not survive the real API.

Change notifications are treated as signals, never as data. A webhook tells us a record is worth looking at; it never tells us what the record now says. The system goes and reads the live record before doing anything with it.

That one rule disposes of a whole family of problems at once. Events arriving out of order stop mattering, because whichever arrives last still triggers a fresh read of the same current truth. A replayed or duplicated event costs one redundant read and is otherwise inert, and duplicates are dropped on event identity anyway. And a notification whose payload is stale — which is normal under load — can never roll a record backwards, because we never trusted the payload.

Our own writes come back as notifications too. The activity log knows what the system just wrote, so an echo of our own change is recognised and consumed silently rather than waking an agent. Without that, the system responds to itself, and a small loop becomes a large one very quickly.

Everything above assumes we are told when things change. Assume we are not. Notifications get dropped, a polling window gets missed, someone does a bulk import, an integration nobody mentioned writes to the same fields. Any working mirror of a system you do not control needs a reconciliation loop, and it needs to do something when it finds a problem.

So a full pass compares the mirror against Nutshell nightly, and a continuously running sample checks a small slice throughout the day — because a bad deploy at 9am should not have until midnight to do damage. Discrepancies are sorted into two kinds, which matter differently. A value we wrote that no longer matches means a person changed it and we missed the notification: the mirror is corrected and that field becomes theirs, exactly as if we had seen the edit. A value neither side can account for is a genuine integrity problem and is the one that should make somebody nervous.

Drift is measured per field class rather than per record, because the thresholds are not the same: a percent of contact-detail churn overnight is ordinary, while the same drift in deal stages or values is not. When a class passes its threshold, writes for that class pause automatically and the queue holds rather than drains. Nothing is dropped, nothing is lost, and someone has to look before it resumes. The alternative — a system that keeps confidently writing into data it has quietly lost track of — is how a CRM integration turns into a data-recovery exercise.

"Undo" is the first thing anyone asks for and the word covers two very different things, so it is worth separating them plainly.

Writes into Nutshell can be put back — but not by Nutshell, and I checked that rather than assuming it. Nutshell's own Audit Log is an Enterprise-plan admin screen covering logins, bulk edits and list exports; it cannot be exported and has no API behind it. Its change feed is more promising but stops short of what an undo needs — Nutshell's own guidance is to treat a change notification as a prompt that an entity moved, not as a description of what moved, and the sample payload ships an empty changes array with only the entity's current state. Nothing in Nutshell can tell you what a field held before it was overwritten. So prior values have to be retained on our side, and the only real design choice is how much apparatus that justifies.

My answer is: almost none, because the Canonical already requires the expensive part. Every AI decision has to be traceable and costed, which means the Control Plane keeps an activity log regardless — one entry per action, with the agent, the rule that allowed it, the cost and the outcome. The gate already pulls the live record immediately before it writes (step 1), so the outgoing value is in hand at that moment and simply travels with the entry. Undo is then not a feature with a subsystem behind it: restoring a field means re-applying the prior value from its most recent entry, and that restore goes back out through the gate like any other write, so it re-checks live state and is itself logged. One log, read two ways.

What this deliberately is not is a version-history product. There is no timeline to scrub, no diff view, no branching. It answers one question — put this field back the way it was before the system touched it — at the granularity of a field, the run that changed it, or a named batch. That is the whole scope, and it is enough.

Anything that left the building is not. An email a prospect has received cannot be unsent, a proposal cannot be unseen, a charge cannot be unmade — only refunded, which is a different event with its own escalation. For those, the hold window in step 9 is the only real undo, which is precisely why it exists and why outbound gets a longer one than a CRM field update. After that window closes, recovery is a compensating action taken by a person, and the system's job is to make that easy and to have logged enough that they know what they are compensating for.

Claiming both are the same thing would be the comfortable answer. It would also be wrong, and you would find out at the worst possible moment.

Every agent gets the smallest set of tools that lets it do its one job, and its reach is exactly the union of those tools — nothing more, regardless of what it is persuaded to attempt. The public-facing agent is the one to look at hardest.

Untrusted text is data, never instruction. A visitor's message and the contents of a fetched web page are handled as quoted material with a clear boundary, and neither is ever concatenated into the part of the context that carries policy. Operating instructions come from one place, on a separate channel, and nothing that arrives from outside can extend or amend them mid-conversation.

The toolset is fixed before the conversation starts. An agent cannot acquire a capability during a conversation, because tool grants are configuration attached to a specific agent version, not something negotiated at runtime. There is no sequence of messages that gets the website chat an email tool.

Least privilege goes all the way down. Each capability group holds its own credentials against the database and against Nutshell, scoped to what it actually needs. A flaw in the component that handles public chat does not become read access to your 30,000 records, because that component was never able to read them.

There is a weak version of a pricing guardrail and a strong one, and the difference is worth being explicit about because they sound alike.

The weak version lets the model write a number and then checks whether that number is allowed. It mostly works. It also means a figure exists, inside the system, that no rule produced — and the entire safety of the arrangement now rests on the validator being complete. Every gap in it is a price nobody approved.

The strong version removes the model from the job. It decides what the prospect needs: these services, this scope, this term. Code turns that into money, line by line, from the rate card, applying the discount ladder. The number is computed, reproducible, and attributable to a specific version of a document DMA wrote.

The engineering that enforces this is unglamorous and effective: the model's output schema has no price field. It cannot emit what it has no slot to emit. And on the public website surface there is no pricing capability at all — an inbound visitor asking "what would this cost?" gets a range only if approved public ranges exist for that service, delivered by code, or gets a conversation about scope and a booked call. Nobody has to trust the agent to be careful with your pricing, because it was never handed it.

Asking a model "does this seem unprecedented?" is unanswerable, because the model has no reliable memory of what DMA has approved before and every incentive to be agreeable. So the system does not ask it.

Instead, every autonomous commercial action has to resolve to a precedent record. A deterministic classifier reduces the action to a key made of a fixed set of attributes — service mix, deal-size band, contract term, payment terms, contract template version, discount rung, and any non-standard scope flags. The model's only job is to fill those slots from the conversation; it does not get a vote on what the slots mean. The gate then looks the key up in the approved-precedent table, which is seeded in Discovery from your historical closed-won deals and your written pricing policy.

• Key found — this shape of deal has been approved before. Proceed autonomously.
• Key not found — escalate to Josh, naming the attribute that had no precedent. Nothing is sent.
• Josh approves — the key is added to the table with the approver's name and the date on it. The next deal of that shape proceeds without an escalation.

That last line is the important one. The system starts conservative and becomes autonomous as a direct function of decisions a human actually made, rather than as a function of how confident a model happens to sound. And because the table is data, you can look at it, argue with it, and take entries out.

All of the above is only as good as the change control around it. A discount floor that any one person can quietly edit is a suggestion. So every load-bearing setting — the guardrail registry, the precedent table, the escalation routing, the field permissions, and the agents' own instructions — is treated as code rather than as configuration: an edit is a proposal that sits inert until a second named person signs it off, and it carries that person's name for as long as it is in force. Authorship and authorisation are never the same signature, mine included.

Two properties follow that matter more than the rule itself. Settings are effective-dated rather than merely current, so a decision taken in March is replayed against the floors and terms that were in force in March — without that, your audit trail explains what happened using rules that did not yet exist. And because each signed-off state is retained, withdrawing a bad change is a one-line operation with a name attached, instead of a conversation about what the number used to be.

This is also the Canonical's human-reviewed model changes requirement, which asks that the system never silently rewrites its own sales strategy. Made concrete, that is exactly this: a change to the strategy is a reviewed commit with an author, an approver and a date.

The gate in section 07 governs everything. These four apply only to the transaction path, because the cost of getting them wrong is different in kind.

• What was approved is what goes out. The approved document is fingerprinted at the moment of approval and checked again at the moment of sending. If anything about it changed in between — a regenerated draft, a rate card edited underneath it — the send stops and returns for approval. An approval is for a specific artefact, not a general blessing.
• Whoever requested it does not release it. On anything that binds DMA or moves money, the person who asked and the person who approved are two different people. This is the same separation as the rule changes in section 09, applied where it matters most.
• The provider tells us, and we check anyway. Signature and payment callbacks are verified as genuinely from the provider before anything acts on them, and a reconciliation job asks each provider for the current state of anything that has been open too long. A callback that never arrives is a normal event, not an exception — designing as though it cannot happen is how a paid deal sits in Negotiation for a fortnight.
• Card data never touches this system. Payment runs through the processor's own hosted checkout. This is not primarily a cost decision; it keeps DMA's compliance surface where it belongs.

I want to be plain about this because it is where I expect my answer to differ most from a competing bid. Having the transaction path working is not the same as trusting it with your customers and your bank account. Autonomy gets raised as a deliberate, reversible ramp, per capability, and the ramp is measured in weeks of real deals rather than a date on a plan.

Agents do not name a model. They declare a task class, and a router resolves that class to whatever provider and model DMA has bound to it. The split into classes is not a cost trick — it is that reading 30,000 records and writing an email a prospect will read are different jobs, and the second is where quality converts. Which engine does each job is a separate question, and it is DMA's to answer.

The three classes below are a property of the work. The binding underneath them is configuration: a hosted frontier model, a different vendor, a model on DMA's own cloud tenancy, or something self-hosted on DMA's hardware. Changing a binding is a policy change in the Control Plane, not a deploy.

What follows is the binding I would start with and the one the cost estimates in Part Two, section 05 were computed against. It is an illustration of how a binding is expressed, not a recommendation you are locked into — every row is a value in a config table.

Nutshell does not retain prior field values, so they have to be retained here. The gate re-reads the live record immediately before it writes, so the outgoing value is already in hand; it travels with the entry. Restoring a field means re-applying the prior value from its most recent entry — and the restore goes back out as an ordinary intent, so it re-checks live state and is itself logged.

The custom fields written back to Nutshell are set out in full in Part Two, section 03 and are not repeated here. Two implementation notes: every one is governed by a field_permission row before the gate will write it, and ai_run_id carries the run.id that produced the values, so any field a rep is looking at opens the activity log entry behind it.

The failure that matters is narrow: we send a write, the connection dies before the response arrives, and we do not know whether it landed. Blind retry gives a prospect two identical notes.

A full pass compares the mirror against Nutshell nightly; a rolling sample checks a slice throughout the day, because a bad deploy at 9am should not have until midnight to do damage. Findings sort into two kinds, and they matter differently.