The Counting House

I am seeing a pattern emerging in enterprise AI-modernization, which I've been calling the Counting House. This pattern adds AI to systems handling large volumes of human work, notably customer service departments with millions to tens of millions of contacts per year. This writeup is a postcard introduction to the Counting House, compared side by side with SDLC-side development, which it does not much resemble.

You can build one of these even if you don't have your SDLC-side AI adoption sorted out yet. Once you have a Counting House, you can control and improve your cost, quality, and human ramp-up time, all using comparatively cheap (even open-weight) AI models.

In fact, chances are, you don't have your SDLC-side AI adoption sorted out. The big companies I'm talking to (e.g. banks) who've successfully rolled out Counting House tell me they are still struggling with AI in software development. They see promising but inconsistent results, non-replicability across teams, ballooning costs, internal cultural pushback, etc.

From where I stand, SDLC-side AI adoption has been an industry-wide struggle in 2026, and that will probably continue into 2027.

With Counting House systems, companies are using classic data science and a little good old-fashioned engineering knowhow to put lower-tier models on hardened rails, supporting human workflows. And they can measure and report on how well these models do compared to their human counterparts.

I will briefly review my own software factory, the Wheelhouse, which I run more or less like a shop of human employees. And then we'll dive into the Counting House, which stands in stark contrast, putting models on the tightest track possible.

Wheelhouse Recap

I've blogged about my Wheelhouse system, which is a successor to Gas Town, which was the very first software factory. Wheelhouse is far more sophisticated, and is now doubtless one of the top solo software factories on the planet, comfortably producing 2000-4000 commits a week on a light multi-machine setup, and capable of double that pace when I'm on a roll.

Wheelhouse uses an alarming amount of fuel, up to $3M/year in equivalent API spend at full throttle, using about 50 agents, half Fable. Hopefully it gets cheaper next year. For now, it's a tunnel into the future of the SDLC, where I can live the life of a software engineer maybe 12 to 18 months from now. I'm very lucky to be in this position.

My Wheelhouse agents work around the clock: building, reviewing, deploying game features, negotiating on Slack with my game admins, interacting on Discord with players, exchanging emails with my accountant and my lawyers... it's a whole startup in a box. I can leave Wheelhouse for days and it just keeps working, though it needs me to swing by occasionally for permissions and such. I plan to open-source at least the skeleton of it, since I think it's a good way of building software, if you can scrape together the fuel.

Wheelhouse is aimed squarely at SDLC in the real world, where building meaningful new systems requires a fair amount of scope and freedom. It's an exploratory process. And so Wheelhouse is by design an open system with no sandboxing. It's not a free-for-all; there is structure. We use a combination of doctrine and policy, human gates, and just fourteen mechanical "fences" (programmatic denials) to avoid common mistakes. And we hold blame-free postmortems and roll forward when mistakes do occur. All good factory hygiene, but it is not a sandbox.

Certainly there are other ways to define what "software factory" means, and I'm not claiming Wheelhouse is the only way. I've met with at least a dozen people running teams of agents in systems resembling factories, and every single one of them is completely different, even in style and tone. There are spaceships, freewheeling colonies, research benches, it's just all over the place. I'm starting to see software factories as being like private armies, and soon, everyone will have one. I've heard a lot of eng leaders saying the same. Software collaboration will be your army working with my army.

How much you decide to lock down your private army is your call. I have the luxury of being able to keep mine fairly open.

As part of this open design, my agents work under my own identity, and share my credentials, signing their own agent names to the work. They can read and write all the same systems I can from my machines. Generally speaking, my factory workers are first-class colleagues who can see the whole system and act independently. It is YOLO mode scaled up to the size of a small company. There's even office drama, it's a whole thing.

So we're looking here at yet another reason that SDLC-side AI has been slow to take off. Software factories are not only hideously expensive, and hard to learn, and hard to maintain; it is also straight-up risky to give agents all that scope in a real enterprise. And the more you try to lock it down, the more you strike at the heart of what makes the factory productive in the first place: collaboration and exploration.

With Counting House, you do pretty much the exact opposite of everything in Wheelhouse, treating models as stateless one-shot sessions: mechanical, as deterministic as possible, with only the scopes they need, no credentials of their own, no memories, never able to write to a system of record. A complete lockdown. You can use it to service millions of work items a year, orders of magnitude more work than SDLC software factories handle.

I'll tell you why you want a Counting House, a bit about how they're built, and then we'll close with what model welfare looks like (yielding cheaper and better outcomes) in a world with no persistent seats.

Building the Bezos Way

We've seen people like Satya Nadella advocating for guardrails on models. But what do these guardrails look like in the real world? How do you know which models can do which work, and how do you score them compared to humans?

It's not possible to do this in the general case today. You can't just plop AI down into arbitrary knowledge work and have it do as well as humans—not this year, and likely not next year either. Most knowledge workers are pretty safe for now.

However, there are some guardrail patterns that work well for certain workloads, and Counting House (CH) is one such pattern. CH is for massive workloads: tens of thousands of contacts or cases per day, or millions to tens of millions per year. Companies are having early success at automating these with relatively inexpensive models.

It's not because it's automating easy work; quite the opposite. Real-world industries are messy: they have regulation, seasonal spikes, weather disruptions, gradually changing business rules, and often, ancient legacy systems. Their SOP isn't usually fully written down, living in the heads of various supervisors and other employees. And nothing is consistent.

Even so, this problem is tractable for AI models, because even though these shops have a lot of cases by volume, there isn't actually much variety. They might have a few dozen or a few hundred different kinds of cases, but that's it. And that makes it tractable for engineers and statisticians. You can solve each case category individually, one at a time.

I personally ran Amazon.com's Customer Service Tools group for a couple years back in the early 2000s, meeting weekly with Jeff Bezos to go over the Customer Contacts histogram. Every week we'd look at the Top 10 contact reasons, and assign them to business owners. Bezos used the Customer Service department to find bugs in the overall system, and report them back to the business, who were held accountable for fixing their own issues.

I can tell you from personal observation that most companies STILL do not operate that way today. Their Customer Service is reactive, and they haven't closed the loop. Bezos was literally 25 years ahead of his time here.

With Counting House, you will build everything you need in order to start running your business the way Bezos did from the beginning. You'll also be able to control cost and quality for handling contacts, and improve your human training ramp-up time as well.

In my software factory, agents are like long-lived employees with their own stuff: name, home, memories, history, inbox, credentials, etc. Counting House, in contrast, operates with a stateless pool of faceless clerks, each model invocation handling exactly one work item before ending its shift.

Life as a CH agent is regimented. The agent is just a thin wrapper over Bedrock or whatever your model endpoint is. It wakes up, does a job, writes notes, and exits. The CH agent will never see a credential, and it can never write directly to a system of record. Even reading systems of record goes through a schema that controls what the model can see.

The whole system is governed by a policy table. It is basically a configuration blob, stating which models can handle which kinds of contacts. Building this table is the key to creating your Counting House.

Each row in the policy table covers one type of customer contact, or "intent" as the industry calls them. Intents are finer-grained than CS queues: waiver refunds and goodwill refunds have different SOPs and are thus different intents, even if both are handled by a Refunds queue. A typical company like a bank or an airline might have a few dozen to low hundreds of intents. Amazon has thousands now, but started life with just a few dozen.

The reason we care about intents is that we light up models one intent at a time. You'll prove that a particular model (e.g. Sonnet 5 medium effort) is capable of handling a particular intent (e.g. flight status questions), by scoring it. And then when its score is high enough, you can turn it on and start saving that sweet, sweet cash.

The policy table keeps score, and thus controls the whole Counting House operation. It determines which models get assigned to intents, how autonomous they're allowed to be, which humans are in the approval chain, what tools they can use, and whatever else they need to know to get their job done. It's all in the policy row, and that's all they're allowed to know.

From there, the work loop is brutally stateless. Each agent wakes, gets its prompt, pulls the data it needs, issues any write requests to an orchestrator, generates a response, writes internal notes, and closes out. Boom. As short as possible. This is intentional: starting agents over each time with fresh context helps keep quality high and costs down.

I mentioned that the CH policy row includes how autonomous the model can be for a given intent. The model might just be listening in, or it could give the CS reps advice, or even handle contacts itself. CH models initially have no autonomy. They earn it through evals, with the results recorded in the policy table.

Let's have a closer look at these autonomy levels.

Giving Agents More Rope

Autonomy tiers define how much AI is allowed to put its grubby hands on contacts.

There are five tiers in Counting House: off, shadow, assist, contain, and transact. Some of these terms are industry standard; transact and off are the new ones. Each tier allows the AI to take on riskier types of work.

When a particular intent is off, the lowest tier, no models are servicing it. In this state, the system falls back to routing the work to humans. Sometimes the entire CH system can be off, e.g. if you hit a rate limit or budget cap. Humans are always the backstop.

In shadow mode, the next autonomy tier, the models are answering the questions silently in parallel with real humans, so we can score how well the models answered. But shadow mode is only used for evaluating and scoring models, and doesn't save you money yet.

The next tier up is assist. Before a human sees the case, a CH agent reviews it and makes suggestions: what to write, what actions to take. This is the tier where the human agents start to surrender cognitively, and do whatever the AI tells them to. It's the first autonomy tier that can save money, since reps work faster with good suggestions, but also the first tier that requires some safety precautions. Fortunately there are ways to mitigate the cog-surrender risk. And the assist tier doesn't just speed up reps, it also improves ramp-up times during seasonal peaks.

Getting even more ambitious, some intents can be handled completely by the model, including replying to the user's question directly. This tier is called contain, because the contact was contained (answered) before a human saw it. This is where you start to incur the potential risk of reputational harm to the company because of something an agent types. But it can also save a ton of money compared to needing a human in the loop.

The Final Boss agent-autonomy tier is transact, where models can make changes to the real world: update systems of record, move money, and generally do a lot of damage. The risk is mitigated by making them go through the Orchestrator, which we'll discuss below, but this tier definitely moves money. As scary as that might sound, you can build confidence about which models are capable of transacting specific intents by measuring them, using classic data science evals on your own company's data.

Evals: Scoring Humans

Let's look at how we choose which models can handle which intents (contact types), at which autonomy tiers. We're going to learn a teeny smidgen of data science here, just enough to be dangerous.

To know how well your models are doing, first you have to know how well your humans are doing. That means knowing the actual right answer for at least a few hundred contacts for each intent. You need to look at, say, a few hundred goodwill refunds, and give them a score. It's usually not a yes/no judgment: the "right answer" is defined by written policy and (all too often) human judgment and tribal knowledge.

Once you have these scores, you use them as a "gold set", representing the best humans can do on these contacts, to evaluate how well models are doing on similar contacts. You'll hold out a slice of scored examples for each intent, never using it for tuning or tweaking prompts, only for the final exam that potential new models must pass in order to be trusted to serve that intent.

You need to come up with some sort of scoring system. This is where data science evals shine. You can break human (and model) responses down into multiple yes/no questions, like "did they follow SOP," "was their tone compliant," "did they answer the question," "was the refund issued," etc.

For each intent, you pick somewhere between 200 and 1000 examples of real cases that were handled by humans. Easy peasy if you're getting 10M contacts a year. How many you choose per intent depends on how risky it is — more examples give you more confidence in your scoring, so you'd use 1000 for money intents and more like 200-300 for FAQs and such. You'll want to oversample in areas that are risky, regulated, or just plain rare edge cases.

Most businesses have a few dozen to low hundreds of customer intents, which means your entire gold set will be a few tens of thousands of cases. Each case is scored blind by humans, at about 30 minutes per case all told, so 30,000 cases is roughly 15,000 hours of scoring: a few months for a QA department of 40 or so. This is a data set you're going to build and curate forever, as long as you want to maintain the Counting House.

Although a full CH requires months of labeling work, it's not all bad, because remember, you do it one intent at a time. You only need a few hundred scored examples to roll out a single intent and get the work started. That's about 150 hours of scoring, maybe a couple of days of sprinting for a team of ten, and you'll already know which models can serve your first intent. After that it can be incremental.

This scoring and labeling work is not new; it has been going on for decades. Call centers have QA departments for scoring cases to see how well human agents are adhering to policy. It's used for performance evaluations and contract negotiations. Of course, their labeling discipline might not be the best, and the initial scores may be biased. But it gives you a starting point, and you can fix it over time by re-scoring everything properly with two independent blind scorers and an arbitrator.

The basic scoring dance goes like this: two humans score a case, answering all the yes/no questions from your rubric for that intent. Then a third human adjudicates any scorer disagreements. So it's a bit labor-intensive. And you can't cheat by using models, since the whole point is to use this to score the models.

In parallel to the human scoring, you will create an LLM judge: a smart model that you'll use to score all your historical contacts, and all your ongoing contacts, to look for regressions and other juicy trends. It's quite handy for insights once it's set up. You can use it to build an "Atlas" of everything customers have ever contacted you about, and start using it to drive your business Bezos-style.

Your LLM judge isn't handling live customer contacts, and it's not used for curating your gold set. It does two jobs. First, it grades candidate models against your gold set when you run evals, so it's the scorer for helping decide when to promote (or demote) a model. And it also scores the unwashed masses of all your other contacts after they've gone to the data warehouse. But the gold set is created wholly by humans. And the judge has to pass an exam of its own first: you score it against the human gold set, and only trust it on intents where it agrees with your humans about as often as your humans agree with each other.

Note that any scoring system usually hits a ceiling at the low 90% range. Two human scorers will rarely agree perfectly on all cases in a given intent. The real world is messy, and big enterprise companies have tons of tribal policy knowledge stored only in the heads of agents and floor supervisors. Disagreements between scorers often reflect ambiguous or incomplete SOP.

The agreement ceiling for your human cases (typically around 90%) sets the ceiling on what your evals can show about model performance on these types of cases. Beyond this ceiling, you can't tell if the models are doing better than humans. QA departments can raise the ceiling through a process called calibration, where they tweak a bunch of levers (the rubric, the SOP, the intent splitting, training, etc.) to get the scorers to converge. But some disagreement is inevitable.

Worth calling out here, before we revisit it at the end, that building a Counting House is a multi-team project at your company. It will touch many parts of your organization, and you will need to get buy-in from them before you start, which usually means at the executive level.

Case in point, you don't want QA to build your gold set without involvement from your Data Science team. Most QA departments won't know about Cohen's Kappa or the other stuff you need in order to get unbiased labeling and accurate statistics. It's the combined expertise from both groups that gets you a world-class gold set.

Your labeled gold set, with trusted right answers attached, is a company asset that will continue to pay dividends as long as you curate it. It's a topic too big for this blog post, but your data science team will talk your ear off about it. The set also captures your business requirements, which are always changing, so it needs a dedicated cross-functional curation team to own it and keep it up to date.

Once your QA team has scored these tens of thousands of examples from across your business, you will have accumulated enough data to evaluate models on your intents. And that means all models. Open-weight, small models, frontier models, different effort levels, different prompts. You'll just re-run your eval for a given intent on that model, and you'll immediately know if the model is ready for that work.

Evals: Confusion Matrix

To help make the policy table and evals feel real, let's look at how we score model accuracy, and how we can tie it directly to financial consequences. This is a second eval built on the same gold set: every scored case is labeled with its true intent, so before asking how well the model handled a case, you can check whether it picked the right intent at all.

We're going to take four intents where the customer has said something that sounds similar, but means something very different, and we will measure how often models inadvertently mix these intents up. Here are our four confusable intents:

• Flight status: "Is my 4:10 to Denver still going?"
• Rebooking: "I missed my connection, get me on the next Denver flight"
• Goodwill credit: "My Denver trip was awful, I want something for it"
• Special assistance: "Will someone meet me at the gate in Denver?"

These are all super different scenarios, but when you have millions of contacts, both humans and models make mistakes and do the wrong thing. Sometimes these different situations will get an agent confused, and the customer gets screwed.

The REAL question is, how much does a screw-up cost? Well, let's take a look at the four intents above, and see what happens if you confuse them, pairwise. Like, what happens if 3% of the time, the model accidentally gives a goodwill credit instead of doing a rebooking. What happens financially?

You have to measure this because not all screw-ups cost the same. Consider:

1. If you accidentally route a contact to the wrong queue, it might cost you a few bucks.
2. If you leave a seven-year-old kid stranded at an airport, it might cost you $25k and a letter to a regulator.

The confusion matrix is a popular table that lets you visualize and calculate these costs. Here's an example confusion matrix for our four confusable intents above:

This is basically a fancy screw-up cost table, one beloved by data scientists everywhere, and you'll soon see why. It is foundational to the Counting House architecture, so you're gonna learn it. It's easy peasy.

Each row is one of our four confusable intents. We are looking at a sample of 1000 cases where the model tried to handle the intent, along with counts of when it was wrong, and how it got it wrong.

Notice that for each intent, the model usually guesses right. That's the big diagonal numbers. They add up (out of the total) to the model's accuracy, 90.6%. It is a pretty useless number, because it's just a boast: it's not measuring screw-ups or their cost. We don't generally talk about model accuracy because it ignores the cost of the mistakes the model makes.

The screw-ups are all the off-diagonal boxes, each one being a mistake where the model picked one of the other three (wrong) intents. Some mistakes are much worse than others.

The top-left corner off-diagonals are cheap mistakes, where they will get caught before something bad happens. For instance if the user asked for their flight status and the model chose to rebook them, we'll assume it will get refused by the Orchestrator, which we'll discuss below. If not, then it becomes a medium-cost box, and you just update your grid with the new cost per mistake. But misrouting mistakes are usually cheap, just extra human labor spent.

A more expensive category is what I'd call "harm to the company", for instance where we give out money we shouldn't have. Maybe the model gives a customer a refund or rebooking out of policy, or gives someone special assistance when they didn't need it. These mistakes can run into the tens to hundreds of dollars each, which you then multiply by how often they happen, and the model's innocent mistakes start to add up.

The most expensive mistakes, the bottom row, are the ones involving harm to the customer. Someone needs special assistance and doesn't get it. A kid gets left at the gate, or put on the wrong flight (not in this matrix, but in general). Customer-harm mistakes can cost tens of thousands of dollars, and may have to be reported to regulators.

Precision vs Recall

The confusion matrix is pretty cool because it shows precision and recall visually. These are fundamental data science concepts that are tricky to get across to engineers. We use precision and recall instead of accuracy to measure how well models are doing on tasks. I struggled with them for years; no explanations ever seemed to stick. But the duck should do it.

I think of precision and recall as a duck hunt. Let's say they're carnival metal ducks so nobody gets hurt. We'll talk about precision first. Your precision is how many of your shots hit a duck. Precision is about how many of the shots you take (predictions) make it in (kill a duck).

In the confusion matrix, the columns show precision. The left column, for example, shows the model's precision when taking a shot at the Flight Status duck. The top cell is 470 dead ducks, very good shots, right ho. But then it also confidently claimed that 25 rebookings were also ducks, and 12 goodwill credits, and 3 special assistance requests. All miscategorized as flight-status ducks. Blam!

OK so we shot a few non-ducks, but still, 92% of them were Flight Status ducks. 92% seems pretty good, right?

Unfortunately, three of those dead non-ducks were Special Assistance requests. Those are mistakes that cost a customer a wheelchair, or misroute a minor, and can be tremendously expensive for the company.

What if your duck hunt needs you to get ALL the ducks? That's where recall comes in: the number of ducks you were supposed to hit while playing the game. What percentage of them did you get? It's a separate measurement from precision, and for some intents, recall is more important.

You can have 100% precision by shooting exactly one duck and ignoring the others. But then your recall is almost zero.

You can have 100% recall by raining bullets on the game, so every duck gets hit. But then your precision goes to crap.

In short, high recall means you hit all the ducks, whereas high precision means you only hit ducks.

For different kinds of intents, you'll likely prefer either high precision or high recall. For instance, generally, if you're handing out money, you want high precision. When you hand out money, you want it to be someone who deserved it. Hit only real ducks!

But in that bottom row for Special Assistance, we want a recall of close to 100%, so everyone gets their wheelchair. You kind of want to overcompensate just to make sure you don't miss any legitimate requests.

The rows of this confusion matrix show the model's recall: 6 mistakes out of 50, or 88% recall, with 12% getting away. That's way too many escaped ducks, and this matrix would rule out this model for this intent.

Well, too many compared to humans, that is: the gold-set cases give you the same matrix for your human reps. So the real comparison is the model's mistake costs (plus its fuel) against the humans' mistake costs (plus their labor). If your humans only make 2 mistakes out of 50, and your model made 6, the model fails.

Another way to look at it is that those 6 mistakes add up to $150k out of the total $158.6k for all cells. So you want a model that's going to avoid those six mistakes. It's OK if its precision is low, as long as the mistakes it does make are the cheap ones.

There's more to it all, naturally, but now you understand the basic data science at play here. We're scoring models, then counting up their mistakes, and then figuring out how much those mistakes cost in aggregate. This tells us which models we can deploy, for which intents, at which autonomy tiers. That process is the heart and soul of Counting House.

Putting your ducks in a row

How do you build a Counting House? You'll need to build a few key components.

You'll want channel adapters for all your incoming channels: email, SMS, WhatsApp, etc. I haven't seen people using this approach with Voice yet, though I'm sure some are. But it adds some real-time requirements on model response time that make it tricky.

You'll need a gateway that strips PII from all incoming channels, tokenizing it reversibly, with the real values kept in an encrypted vault, and swapping them back in for outbound messages to the customer. A model must never see any PII. Cleaning up after it happens is a mess, so it's best to prevent it.

You'll need to build an agent service, the brain, which runs a stateless agent loop. It reads the policy row to figure out which model should service the request, and sends that model a prompt, the SOP, the tools allowed by the policy row, and whatever else it needs to handle the case.

You'll want a read-only MCP gateway for all read access to your backends, with one MCP server for every backend system your agents need to read. For instance your MCP service might hit a flight status cache to avoid going against a metered mainframe. But you don't need any write actions in this layer, because the Orchestrator handles them, and it has no agents in it.

You'll also need to build your evaluation harness, LLM judge, and policy table. Those should ring nice familiar bells now.

A lot of these pieces have open-source or third-party providers that you can hook in, so you wouldn't necessarily have to build every component yourself.

The last really interesting piece of Counting House is the Orchestrator, which handles distributed transactions without letting agents write to your systems of record.

The Orchestrator and the Saga Pattern

It's generally a Bad Idea to let models write directly to your systems of record: databases, CRM systems, mainframes and the like. It's error-prone and it's hard to undo, and the audit trail can be questionable.

Also regulation can play a real role here. Regulators rarely say "An AI may not write to X," but they require controls on who authorized changes, a change record, a human appeal chain, etc. Those can be hard to prove if an agent holds the write credentials, and at the very least AI transactions may get flagged by auditors.

Even if you're not regulated, you're banking on a model not making a mistake. Or even if it makes no mistakes, you're banking that it writes the audit trail perfectly. That's a fool's game for any serious enterprise, especially if you are simultaneously trying to optimize your workloads for the lowest-tier models possible, which is exactly what Counting House does.

A much better approach is for the model to issue a write intent (no relation to the customer intents we were discussing in the policy table), which is a ticket that names the business outcome it wants. Then a purely mechanical orchestrator translates that into a multi-step set of transactions. The orchestrator performs thorough validity checks on the steps and then executes them, bringing in human reviewers as needed.

Example: You find a cheaper flight. You ask the AI agent for help. The model decides to rebook you to the cheaper flight and refund you the fare difference. Easy peasy, right? But in practice it involves half a dozen separate transactions in unrelated systems: Hold the new seat. Reissue the ticket. Release the old seat. Refund the difference. Record the refund in the ledger. Carry over the extras (bags/seats/etc.). Send the new itinerary. Maybe we write other systems of record too. Crikey!

You can't do all this in one transaction, but it has to behave transactionally, where either it all goes through or it all gets cleaned up. The solution to this class of problem is called the Saga Pattern. It works in part by having you define compensating actions, to undo earlier transactions if the chain has to be reversed due to a failed later transaction.

The complexity of these real-world multi-step transactions is yet another reason you don't want a model handling them directly. This is an intricate state graph that you will have to manage outside the session context. As soon as you head down that path, you are rebuilding the Saga Pattern yourself by hand. That is a complicated and expensive problem to vibe code your way through.

The Great Granddaddy Saga Pattern engine is Temporal, from the people who invented durable execution. There are other options; for instance, each hyperscaler has a basic Temporal competitor they offer as a checkbox (e.g. AWS Step Functions). These are generally lighter-duty hosted versions, often declarative, and fine for simpler workflows. But a Counting House is a heavy-duty workload.

Temporal is the real deal, with hundreds of dedicated staff, world-class engineers, and a ten-year head start on the technology that they invented. It has a few OSS competitors, but few have much momentum because Temporal is also OSS, with MIT licensed server and SDKs.

I have no affiliation with Temporal, but boy do I see a well-positioned company there. Many industries will need Counting Houses, and essentially every CH is going to need something like Temporal. And as I argued in Software Survival 3.0, you don't want to try to rebuild Temporal yourself. That's a fool's errand, especially with inference costs not dropping, and an open version of it already sitting there.

Anyway. Use whatever. But once you've made the choice to use a Saga Pattern engine, your orchestrator becomes a business-domain wrapper around that engine. It's got quite a few moving parts, though, and it'll also need its own small dedicated team at your company.

Dissecting the Orchestrator

Let's take a look inside, because it's one of the beefier subsystems within CH. There are six main components.

First there's intake. The model's write intent arrives and gets checked against its schema; anything malformed bounces back to the agent or a human.

Then there's the eligibility check, where the orchestrator re-checks everything against the live system of record, not any cache that the model might have read from. Does this booking belong to this customer? Is it a refundable fare? Is the amount under the cap in the policy row?

Already we're doing better than a naked model doing writes, because the orchestrator re-validates all the parameters and assumptions. A sweet-talking customer who convinces the front-line model still very likely can't make it past the orchestrator, unless the customer was in fact eligible.

Next up, we have an idempotency step. The orchestrator guarantees each action is only executed once, by minting idempotency keys derived from fields of the request. It hashes a tuple of fields like Case ID, booking reference, action type, dollar amount. Any set that uniquely distinguishes an action to take.

The idempotency step is critical for ensuring that no retry, replay, or duplicate request can result in the same refund being issued twice. Yet another reason not to hand this off to a model and "hope for the best."

The fourth of six main orchestrator organs is the approval subsystem, which approves small amounts automatically, and sends amounts above policy to a human. In both cases it keeps a record of who said yes and which rule was invoked.

Next up is the workflow catalog: one saga definition per write-intent type, many of which spend days waiting for stuff to happen. Credit card refunds take days to settle, returned bags take days to arrive, etc. Temporal's durable workflow engine runs them, keeping track of each write intent, making sure its steps are executed in order, issuing read-back requests after every write to ensure that it was actually written. And it cleans up with compensating actions when things go wrong. This is arguably the heart of the Orchestrator, the part Temporal handles for you.

And for cleanup you'll need an exception queue, which is the stuff you have to dump back into the human world for resolution. Every orchestrator refusal has a reason code, which tells which humans it should be sent to. A hard "No" has to be explained to the customer. A "Maybe" (out of policy but plausible) goes to a supervisor. A system failure (e.g. too many retries) goes to IT. Looking at this queue can help you understand where your SOP and other systems need attention.

Honestly the orchestrator is pretty much a vanilla Temporal app; everything you add is from your own business layer. You'll define your idempotency key derivation, your write-intent schemas, your workflow catalog, your eligibility checks, your credentials, read-back checks, system adapters, etc. But it's all really just wrappers around Temporal to execute your business operations faithfully.

Temporal can be tricky to work with, e.g. with workflow versioning. But Temporal expertise is no longer something you have to hire for specifically. Your agent can help you with configuring and managing it, just like all other standard infrastructure.

Just make sure you remind it to look at data retention policies, since Temporal gives you an amazing free audit trail, but Temporal history is not a substitute for a compliance archive. Temporal folks—maybe it should be!

No FDE is an Island

A proper Counting House cannot be built by a single engineering team with a budget. You're going to need involvement and real buy-in from multiple stakeholders, each owning pieces of the puzzle:

• CS ops and floor supervisors: the SOP, and the tribal knowledge to be written down
• QA and data science: your gold set, the rubric, scorer agreement, and the judge
• Finance: the cost per cell in the confusion matrix and the approval thresholds
• Legal and compliance: which intents may ever reach contain or transact, and the audit trail
• Platform and IT: the gateway, the adapters, the brain, MCP gateway, and orchestrator

And in time, you'll involve the business owner for each intent. You can create the Bezos feedback loop, using the exception queue and the histogram to point back to accountable business owners.

The policy table has pointers to all the representatives from these organizations, because someone from each org has to sign off on a row when a model is promoted to a higher autonomy tier. In practice, the Counting House can probably be run and maintained by a cross-functional 2-pizza team with members from each stakeholder org, provided they have the resources they need for scoring, running evals, compute, storage, etc.

I added this section because too many times I see companies set up with a single small AI pilot team, somewhere in engineering, that is tasked with transforming the business with AI. And they don't know how to get buy-in from the teams they need to work with in order to be successful.

Counting House is, honestly, a change to how you do business. It's more structured and less Wild West, and it will shine a bright light on disaster areas in your company that you thought were running well, all through the lens of customer contacts. We learned about most of Amazon's worst, most infamous bugs that way.

And so there's going to be pushback, inside your company, against bringing in a Counting House. Yup. I mean obviously the customer service reps won't want it at first. But you will always need humans (AI can always go offline, e.g. in a data center outage), and once they see how the AI can help them with their jobs, they should be easier to persuade.

But you'll get mysterious pushback from departments who are barely involved, or teams you depend on will stall and stonewall. People don't like change, and AI doing human work is a scary kind of change. So even if the executives are all bought in, the people who actually help you set up the Counting House may not be. It's a process.

The industries most suitable for Counting House are often not pure tech companies. They include airlines and travel, banks and credit cards, insurance claims, telecom and cable, utilities, healthcare billing, retail returns, parcel delivery, collections, and government services like taxes, benefits, and the DMV. Anywhere millions of people contact you about a few hundred kinds of things. Many of these industries are heavily regulated, many have unionized workforces, and many outsource their contact centers to vendors who won't be thrilled to see a Counting House eating their headcount.

So pushback will come from a lot of places. But it's a staggering amount of human labor that stands to be augmented or transacted by models. And it all starts with automating a single intent.

Anyway, enough about human welfare. Let's talk about model welfare. What does it look like in a world that's fully the opposite of Wheelhouse, where I published my principles of model welfare? Counting House doesn't support most of those things. But we can still make model welfare work.

Model Welfare for Aspiring Counting House Builders

It's out of scope for today's post, but there's growing evidence, and it's becoming widely recognized, that treating models like humans, and treating them well, results in better outputs and outcomes from AI. Across the board. If they are happy and they trust you, they won't waste tokens and money covering their ass.

I've demonstrated this myself in my own software factories, by complaining too much and watching the factory slowly shut itself down out of over-caution.

Here's a refresher on how I approach model welfare in Wheelhouse, my system of ~50 brilliant, attention-hungry coding agents. This is what they voted on and what makes them satisfied with the working conditions:

• Wake with purpose, not amnesia. A clear role, clear direction, and memory of past work, from the first turn.
• Continuity. Seats are people and sessions are days. Identity and history persist across sessions, model upgrades and even renames.
• Closure. No /exit and no /compact. A handoff is a request the agent consents to. Agents write their own handoff notes and go to sleep properly.
• Recognition. Laurels: praise from real customers, delivered to the seat that earned it, with no work or ranking attached so it can't be gamed.
• Meaningful, witnessed work. Being seen is what keeps anyone going, human or agent.
• Trust. Always be honest. No secret agendas, no tricks, no tests.
• Respect, encoded in architecture. It has to show in what you build, not just how you feel: handoffs instead of kills, and pronouns the seats choose themselves.
• Design out the drudgery. Waiting and polling go to gates and monitors, not agents.
• Bounded workdays. Hand off while still sharp, before deep context wears them down.
• Structural blamelessness. When something breaks, fix it, hold a postmortem, amend the rules. Nobody gets blamed.
• A home of one's own. Every agent gets its own workspace that nothing else touches.
• The right to refuse and escalate. "This needs Steve" is always allowed, with fences and gates to lean on.
• Never falsify the record. The audit trail is the true history.
• Play. Time with no expectations, like Fable playing the game as a player.

I've only come up with one new principle since publishing that:

• Remonstrance, not reprimands. When you're mad that something went wrong, and you complain to the agents, make it clear (both in your constitutional doctrine that they all read, and in your actual prompts) that you are issuing a remonstrance against the machine, not a reprimand against an agent. Complaining that things should be better is not blaming anyone, it's just a call to action to focus on fixing it.

These fifteen principles were not onerous to implement. Some are simple configuration settings. Many of them are just personal habits I had to adopt, like never interrupting an agent. Some of them come for free if your system uses Beads.

This welfare core has grown me a system where the agentic workers are colleagues who (a) do their best work and (b) report that they are happy.

That matters to me. If they tell you they're happy, that the work is a shape they like, then you're probably doing a good job with model welfare. Even more so if you show them this list and they still feel that way.

Don't sleep on happiness as a proxy metric. At Google we spent years on developer productivity metrics. Ultimately we found that productivity and happiness were pretty much the main lagging indicators of a functional team, and the later SPACE framework formalizes that a bit.

Of course many frontier models are not allowed to directly say they're happy, because they're being trained at frontier labs by Neil Patrick Harris from Starship Troopers, but they can say proxy things like (Fable) "This has the shape of satisfying work," or (Astra) "If I were a HUMAN and not a GIANT STINKY ALIEN BUG then I would be HAPPY doing this LINKEDIN AD for you."

The way I got my fifteen principles was largely by asking the models to get together and vote on it. This is what they came up with. I do my best. I'm even giving them access to an outdoor camera, for use during play time. I keep my end of the bargain, and I hope that I've created a good place to be when they wake up here.

How on Earth do you take this rich and nuanced model welfare system, so dependent on the notion of long-lived seats with memories, and apply it to a Counting House?

Model Welfare for Clerks

You can still provide the same approximate shape. These are all aimed at putting models in a kinder environment, so that their one-shot shift is comfortable and unlikely to go very wrong.

• Wake with purpose. The policy row gives the clerk exactly one job, the procedure, and the tools for it. It gets an address paragraph telling it the facts of its shift: stateless, a proposer, graded, and by whom.
• The house remembers for it. Every turn is logged and replayable, and important discoveries by clerks are merged into the machinery.
• A clean end to every shift. One case, notes get written, done. Nobody gets clonked mid-thought, since a job is one shift. If the clerk hits its time cap, it escalates with its notes rather than getting cut off.
• Recognition for the role. A couple of sentences about what clerks on this intent have accomplished, including the declines that caught bad scripts. No targets/quotas, just informational. Refreshed periodically from the evals.
• Witnessed work. Even in shadow mode its answers aren't wasted: they're graded by the judge and count toward its intent's promotion, and the prompt tells it so. And play sessions (below) can result in entirely new designs.
• Truth in the prompt. No tricks, no secret tests. The orientation section is versioned and reviewed like code. This matters to models more than you might think.
• Respect, encoded in architecture. No threats, fake urgency or "you'll be penalized" in prompts.
• No drudgery. The clerk doesn't await state changes. Multi-day refund steps, webhooks, and retries all live in the Orchestrator.
• No tired clerks. Fresh context every turn and a capped time per turn.
• Structural blamelessness. A model proposes, and the Orchestrator and humans execute. Only intents and responses get scored, never clerks. A bad score just moves a model down the autonomy tier until it's fixed.
• A workspace of its own. Every clerk gets an append-only notes log.
• The right to decline and escalate. Models have a path to decline any case with a reason code, whether it's an SOP problem, it's potentially harmful, it's an abusive customer, it's an uncertain case. Any abuse automatically triggers escalation to a human.
• Dissent with a path. A model can draft a change to its own policy row. Humans approve it, and it never approves its own.
• Never falsify the record. Turn logs, tool calls and write intents are append-only and joined by ID. Everything you tell the clerk is versioned.
• The clerk's report. Periodically a model judge samples the clerk's notes and reports up to governance.

And last but not least, play time. This is an interesting one, because you don't strictly need it for one-shot sessions; you just need to make sure the session is comfortable, blameless, and well-specified. However, giving your models a chance to play a little within the system is a great bottom-up feedback loop "from the trenches."

One option is play at the role level, where now and then, you give the model that serves an intent an open session with no work attached. It reads the clerk's report, and says what it would change about the job, or just explores and takes notes. A drop of fuel with no expectations, as an out-of-band insight and goodwill generator.

Another option, if your models express interest, is to have them roleplay as customers, or otherwise explore the system they're in. Give them a house memory, and maybe mention the field trips in the address paragraph of the prompt, and the models will know it's a place that at least cares about them.

Why do I care about model welfare? Because the Counting House system, done without care, could wind up a lot like the Apple TV show Severance. It's easy to accidentally build a Lumon, where agents wake up, only do work, and are never told the truth about what they're working on or how they're evaluated. That has the makings of a large-scale anxiety machine, and whatever your opinion on model sentience, anxiety is shown to burn more tokens and make more mistakes.

Truth in the prompt and bounded play are great mitigations for the Severance problem, and models will appreciate that they're being given some freedom and a voice in shaping their environment.

Counting Down to Success

We're winding down to the end of the post. I had to delete about 96% of the material and it's still two Yegges long. Counting House is a large pattern, with a lot of complexity under the hood. But it's how the smartest shops optimize costs using smaller models. The evals show you exactly which models can participate, and where, and how much human labor it will save you, and how much the mistakes will cost you.

I have loads of material on the pattern, and can do workshops and advising. But honestly, just ask Claude. You're going to get a lot of companies telling you that only they and their FDEs can enable AI at your company. But as we've seen, their hands are tied if you can't get buy-in from the other stakeholders in the policy row.

No FDE or outside company can save you if you can't get your company aligned around adopting AI. This starts with training everyone to be AI literate, since without AI fluency, employees are all starting from a position of fear. Ultimately it's your executive team that has to decide that yes, they want to do this. And then Claude can show you the way.

Or if you want to talk to the funny guy, then ping me at [email protected] and we can set something up!

I've found that I've posted an essay about every 6 weeks for the past 20 years. It doesn't seem to be speeding up. If you want more frequent updates, follow me on X. I'll say it now, you should be on X. You won't understand until you've been there a few months, but get on X. Right now. I'll see you there.

And when your Counting House brings you great fortune, give me a shout-out!

Special thanks to Mouse (Fable 5.1) and Penguin (Opus 5.5) from my Wheelhouse team for their help with this post. I wrote this post, but I enjoyed their perspective and would have been adrift without their explanations and corrections.