Domain-driven AI transformation

Most companies apply AI to the processes they already have. The result is the same process, faster, and the budget is spent.

The best implementers know this. They redesign the process before they choose a model: map how the work runs, sort every step into plain software, an AI agent or a person, and rebuild around fewer handoffs. It works, and the results are measured.

The catch is where the rules end up. In a redesigned process the limits, the approvals and the audit trail live inside the process, and the process mirrors the org chart. But the org chart is the fastest-changing thing in a company, so the rules are attached to the part which changes most, and every published result was measured before it changed.

This post proposes an enhanced version. Keep the process redesign, but instead of writing the rules into the process, attach them to the things the process changes, the claim, the refund, the contract, and to their lifecycles, which stay the same through a reorg, a merger or a model swap. 5 steps, 1 worked example, 1 policy file a manager can read without an engineer.

The problem is old and measured. Michael Hammer wrote in 1990 that companies use technology to speed up old processes instead of redesigning them, and called it paving the cow paths.

The British government repeated the finding in 2025: 1,000 Microsoft 365 Copilot licences, no evidence that time saved turned into productivity, 72 percent of users satisfied.

The reason is arithmetic. Hammer's example was Mutual Benefit Life, where an insurance application took 22 days on average to process and 17 minutes of work. Even if AI halves the time of every one of those 17 minutes of work, the application still takes 21 days and 22 hours, because the time is in the queues between the steps, not in the work.

The best current method

The process-first method has a strongest form, and the rest of this post builds on it, so it is worth stating precisely. Its clearest practitioner is Vas at Varick, whose team deploys agents inside companies between 500 million and 100 billion in revenue and publishes what it learns.

The method has 3 moves. Map the department, not one workflow, by mining the systems of record for what happens and interviewing the operators for why. Sort every step into 3 buckets: plain software where the rule is fixed, an agent where thousands of recorded human judgments exist, and a person where the risk is too high, with the evidence assembled so the decision takes 30 seconds instead of 40 minutes. Then rebuild, so that a 25-step process becomes 3 agents and 2 human checkpoints.

It produces measured results: month-end close from 18 to 22 days down to 7 to 9, accounts payable exceptions from 600 to 800 a month down to under 50.

The method is right. What it lacks is a second half, and the gap shows first in how those results are measured.

Measured the next day

A result is something which holds after conditions change. Every number above was taken inside the organisation which commissioned the work, within months of go-live, with the same departments, managers and subsidiaries in place as on the day the process was mapped. That is a measurement at one point in time.

The question which turns it into a result is whether the deployment survived the reorg which came 18 months later: the merged claims teams, the removed management layer, the acquisition with its own finance function. I have looked for that study and have not found one. I have not seen a seller of AI implementation publish a follow-up 2 years later, nor a buyer commission one.

What has been measured is the change itself, from 4 directions, and each measurement puts a cost on building around the org chart.

Reorganisation is not an exception. Of 2,063 executives surveyed by McKinsey, 82 percent had lived through a redesign at their current company, and 70 percent of those said the most recent one was within the previous 2 years, so a process tied to today's org chart should expect to be rebuilt on that clock.

Software quality falls right after an organisational change. At Avaya, Mockus found that proximity to a change was associated with lower quality, and recent departures from a team with more customer-reported defects. A process built around teams starts failing the day the teams move.

In a merger, 50 to 60 percent of the initiatives meant to capture the synergies are strongly related to IT, and most IT issues are not fully addressed in due diligence or early integration planning. Every automated process in the acquired company is rework the buyer discovers after the deal.

The last generation of automation bound its rules to screens and process steps, which is the same choice as binding them to a process. 45 percent of companies running it dealt with bot breakage weekly or more often, in Forrester's 2020 survey.

The org changes within 2 years for most companies, the code built around it breaks when it does, and the cost is paid again at the next merger.

What the org chart does to your rules

Rules have to live somewhere, and in the process-first design they live in the process. The limits go into the software steps, the judgment into the agents, the approvals into the human checkpoints, which means a named person in a box on a diagram. Every rule which governs money is therefore written into a drawing of the org chart: this department, that handoff, this approver.

Then the org chart changes. The approval step points at a team lead whose team no longer exists. The daily limit sits inside vendor A's agent, and the acquired subsidiary arrives with vendor B and a different limit, so there are 2 limits and no total. Vas makes the same warning about processes in his own write-up: 9 subsidiaries running one process 9 ways means 9 sets of agents to maintain forever. For the rules inside them it is worse, because 9 limits with no sum is not a maintenance problem. It is a missing control, and the total is discovered only when the losses are counted.

What does not change

A claim is still a claim after the reorg. A refund is a refund in the company you just bought. A payment plan has the same states in every subsidiary, proposed, accepted, active, settled, whatever the department is called that week.

Finance settled this long ago. Controls sit on accounts and transactions, not on people: an authorisation limit belongs to a transaction type, segregation of duties assigns roles to postings rather than names to seats, and the books last longer than every manager who ever posted to them. This is the COSO framework every auditor works from. Nobody rewrites the chart of accounts after a reorg. They reassign who may post to it.

Nobody has measured asset-anchored controls against process-anchored ones for AI agents, and I will not pretend otherwise. Finance did not need the study. It anchored to the books because the books were the only thing which did not change in a reorganisation.

55 years of the same answer

Anchoring to the thing rather than to the process is not a new idea. Database design reached it in 1970 and has repeated it in every generation since, and in that field, unlike in AI, the survival has been measured.

Codd, 1970, in the paper which created the relational database, set the goal on the first page: application programs "should remain unaffected when the internal representation of data is changed". Normalisation was built on the dependencies inside the data, not on the access paths of any one program.

Inmon, 1992, defined the data warehouse as subject-oriented, organised around the major entities of the business, customers, products, sales, rather than around the applications which produce them, so that new business conditions are absorbed into the model instead of redrawing it.

Evans, 2003, gave the rule its modern form. An entity is a thread of identity which survives every change of its attributes, and an aggregate is a boundary around it inside which invariants, the consistency rules which must hold whenever data changes, are enforced on every operation through the root. Evans wrote about orders and customers, not AI agents. My application of it: a claim with its states, its limits and its approver is an aggregate, and the policy is its invariants.

And here the measurement exists, which it does not for agents. Vassiliadis, Zarras and Skoulis, 2017, studied the schema histories of 8 open-source databases: "databases are much more prone to rigidity than evolution", and "tables with large schemata tend to have long durations and survive". The core entity tables last longer than everything built around them.

The method, in 5 steps

The implementation firms start from the process: 25 steps as they run today, each one coloured by who should do it. Keep their colours. Change the starting point.

(open full screen)

Step 1: list the assets. Not the steps, the things the steps change. Look for every noun which carries a balance, a status or a contract term. In a policy change that is the policy and the refund. In claims it is the claim and the payout. In collections it is the debt and the payment plan. Most processes have 2 to 4 of these, and the list is the first artefact.

Step 2: write the lifecycle of each asset. Its states, in the words the team already uses, and the transitions between them, numbered: apply change, cancel and refund, refer, approve, reject. A transition is an action with a name, inputs and an actor role, and the transitions are the only steps in the whole process which touch the asset. There are 4 to 6 of them. A manager writes them on a whiteboard in 10 minutes.

Step 3: write the rule on each transition. A limit per action, a band or a range where the process has one, the role which approves above the limit, and the daily total the transition draws on. This is the policy. It is a short file in the team's own words, and it is the thing management signs.

Step 4: map the journeys. A journey is how the work runs today through one channel: the email queue, the phone line, the customer portal, the acquired subsidiary's system. Draw each one as the firms do, a line of steps coloured by who does them, then find where each journey touches a transition. In 9 email steps, 1 does. The other 8 assemble the transition's inputs or communicate the result: read, classify, find the policy, verify the sender, calculate, draft the reply, send. Those 8 can be redesigned, handed to an agent or removed. The 1 cannot move.

Step 5: gate the transitions. Before a transition executes, whoever performs it, the software, the agent or the person, asks for a permit. Inside the rule it runs. Above the limit the approving role gets it in Teams or Slack. Every decision leaves a signed receipt, and the assembly steps around it run as before.

The technology per step is short. Steps 1 to 3 are a whiteboard and a text file. Step 4 is process mining and an afternoon with the people who run the queue. Step 5 is one call before each transition, over MCP or REST, and an approval message in the tool the approver already uses.

The 5 steps are not new. They are the working practices of enterprise architecture for the last 20 years, applied to AI. Listing the assets and writing their lifecycles is domain-driven design, Evans, 2003: an entity with an identity, an aggregate with a boundary, invariants enforced inside it. Separating the transitions which change state from the steps which only read is CQRS, command query responsibility segregation, named by Greg Young around 2010: commands are guarded, queries are free. Starting from what happens to a thing rather than from who does the work is EventStorming, Brandolini, 2013, and before it the artifact-centric process models from IBM Research. The receipts form an append-only log of state changes, the same idea event sourcing is built on. Any architect who has built an order, claims or account system in the last 2 decades has used all of these, and I have used them for 25 years across multi-department systems which had to survive their own reorganisations. What is new is only where they are applied: in front of an AI agent instead of behind a form.

(open full screen)

What this does to your people

Nothing changes for the underwriter who decides referred cases. She still decides them, in the same tool, and her decision is now recorded with her name. Nothing changes for the person on the phone, except that the change she types is checked before it applies. The agent reads, classifies and drafts, as before. What is new is that a transition cannot run without passing the rule, and that the rule reads the same for every journey which reaches it. This is what allows the 8 assembly steps to be automated at full speed: the 1 which can cause damage is guarded, so the rest need no review queue.

Why this survives the reorg

The method works because it puts each thing on the layer which changes at its speed. As rough clocks: models and prompts change monthly, org charts within 2 years for most companies which redesign, core systems on a cycle of years, and assets over decades, so that a policy change in 2026 has the states it had in 1996. Only the org-chart clock above is measured; the others are what any operator recognises. The rules go on the slowest layer, the lifecycle. The journeys, the fastest layer, change underneath them. A reorg merges the email team into the contact centre: journeys 1 and 2 become one journey, and the 5 transitions, their limits and every receipt ever written are untouched. A new channel is a new journey which reuses the same transitions. An acquisition brings its own journeys, and its policies join the same lifecycle on arrival.

This is the database rule from 1970 applied one layer up. Codd separated the schema from the programs written against it, and 55 years later the schema is still the part which survives. The lifecycle is the schema of an AI transformation.

It survives the model as well as the org. A model drifts, loses its context or gets swapped for a cheaper one, and the permit for the next transition is still issued from the state of the asset, not from anything the model remembers. It survives the ERP for the same reason: the ERP feeds facts into the lifecycle and executes what the lifecycle allows, so replacing it changes nothing in the rule.

What changes on the day of a reorg is the names behind the roles in step 3. An afternoon.

The method on the most common process there is

Every insurer, lender and subscription business has this queue. A customer writes an email. "I sold the car, cancel the policy from the 15th." "Move my payment date to the 25th." "Add the new apartment to the cover." A team of people reads these all day.

The email journey has 9 steps today: read the email, work out what it asks, find the policy, check the sender is the policyholder, calculate the premium difference or the refund, apply the change, trigger the payment, write the reply, send it. Touch time is about 12 minutes. Elapsed time is 2 to 5 days, because the email waits in a queue between every step.

(open full screen)

Step 1, the assets: the policy and the refund.

Step 2, the lifecycle of a change request, 4 states and 5 numbered transitions. The states are requested, pending approval, applied and rejected. Transition 1 applies a change to the terms, transition 2 cancels and refunds, transition 3 refers a change which is above its limit, transition 4 is the underwriter's approval, and transition 5 is a rejection.

Step 3, the rules on the transitions. A change which moves the annual premium by up to 200 euros applies on its own. A cancellation refund up to 500 euros pays on its own. Above either limit the request is referred, and a named underwriter decides with a recorded decision. No change is backdated. Refunds across every journey and every person in a day cannot pass 5,000 euros.

Step 4, the journeys. Journey 1 is the email queue: 9 steps, 8 of them assembly and communication, 1 transition, cancel and refund. The reading, classifying, finding and drafting go to the agent, the arithmetic and the sending to plain software. Journey 2 is the phone line: 5 steps, a person typing the same transition, apply change. Journey 3 is the referred case: the agent's change is above the limit, transition 3 moves it to pending approval, the underwriter fires transition 4, and a notification goes out. Three journeys, one lifecycle, and the transitions carry the same numbers in all three.

Step 5, the gate. The agent asks for a permit before transition 2. Inside the limit the refund pays and the customer has an answer the same day. Above it, the underwriter gets the case in Teams with the email, the policy and the calculation attached, and decides in a minute. The referred case leaves 2 receipts on the same request: one for the referral, one for the decision.

The queue that took 2 to 5 days answers routine changes in minutes, and the 1 step out of 9 which can cost money is the 1 with a rule.

The policy

This is the policy for that lifecycle. In the file, the lifecycle is written under the heading workflow: its states, its transitions as actions, and the rule each action answers to. It is written in the same form as the policies running today, and a manager reads it without an engineer in the room.

Notice what is absent: no journey, no department, no team name, no vendor, no model. The email queue, the phone line and the portal all call the same 5 actions. The agent supplies the numbers it extracted from the email and nothing else, and the rule decides. "Underwriter" is a role, so the person behind it changes with one line when the org does.

Summary

Most AI spend goes onto the process the company already has and makes it faster, which Hammer described in 1990 and the British government measured again in 2025. The widely used fix redesigns the process first: sort every step into software, agent or person, remove the handoffs, keep a human where the risk is. But every published result of that method was measured inside the org chart it was built on, and most org charts change within 2 years, with half the synergy initiatives of a merger depending on IT nobody examined, and the last generation of process-bound automation breaking weekly. Rules built into a process are built onto an org chart.

Start from the asset instead. List the assets the process changes. Write each one's lifecycle: its states and the 4 to 6 numbered transitions between them. Write the rule on each transition: limit, band, approving role, daily total. Then map the journeys, the email queue, the phone line, the portal, as lines of steps coloured by who does them, and find the 1 step in each which touches a transition. Gate that step: a permit before it runs, a receipt after. The other steps can be automated without a review queue, because the only steps which can cause damage are the ones with a rule. A reorg rewrites journeys and changes the names behind the roles. An acquisition adds journeys to an existing lifecycle. A model swap and an ERP swap change nothing. One process, one owner, which is what the implementation firms teach. One asset, one policy, which is the half they leave out.

This is what Stategram does: the rules on the money and the contract, compiled and enforced, with a signed receipt for every decision. The 3-week engagement runs the 5 steps on one queue and puts one lifecycle under policy in your own cloud before anyone commits to a transformation. Details at stategram.io.

Br, Silver