The slide says the AI capability is delivered. Seats are bought, the usage graph climbs, and someone has drawn a green checkmark next to the third body. On paper, the model is in your pipeline.

Then you look at where the work actually happens. The model drafts, and a person quietly rewrites most of it before anything ships. It suggests, and the suggestion gets read, sighed at, and closed. The tool is open on every screen and the job is being done the same way it was 6 months ago.

That model is present. Present is not the same as in the loop.

Issue 1 named the trap: sequencing.
Issue 2 named the destination: AI-native, not AI-ready.
Issue 3 put the AI capability on the table as one of three bodies that move together.

This week I climb inside that body and ask the only question that matters once the model is bought: is it in the loop, or just in the room?

A model is in the loop only where you would ship its work without redoing it. Everywhere else it is in the room: adopted, visible, paid for and not actually doing the job.

No kit this week. Just the argument and the standing ask: if you have put a model into a real pipeline, subscribe and tell me where I am wrong.

Subscribe now

The model as a build lever

The first thing a model in the loop does is change what is worth building. Not how fast you type. The size of the thing one person can now finish.

Every backlog has a graveyard: the work that was permanently parked because the payback never cleared the bar. The manual review step no one would fund a rewrite for. The migration that needed six months of a team you were never going to get. A model in the loop moves the economics, not just the ergonomics, and some of that graveyard work suddenly clears the bar. The item that was “too expensive to bother with” becomes a Tuesday.

That is the lever. It is quieter than the demos suggest and more consequential. It does not make your existing plan faster. It changes which plan is worth having, which means it reaches straight back into the architecture body and the team body, the same coupling Issue 3 was about. Treat the model as a faster autocomplete and you will use a build lever to shave minutes off typing, which is roughly using a forklift to carry your lunch.

The model as an architectural mirror

The second thing a model in the loop does is show you your architecture, whether you asked or not.

A model can only act where your system lets it act. Point it at a clean seam with a real contract, and it moves: it reads the boundary, does the work, hands back something you can ship. Point it at a tangle where the batch job, the shared database, and the nightly cron all reach into each other, and it stalls, hedges, or invents. It cannot find the edge of the thing you are asking it to change, because there is no edge.

So where the model reliably fails, it is usually not failing. It is reflecting. A model that keeps getting the same file wrong is often telling you that file does three jobs. That is Conway’s law with a faster feedback loop: Melvin Conway said in 1968 that a system’s design mirrors the communication structure that built it, and now the mirror talks back in an afternoon instead of a reorg. The model reads your architecture the way an honest new hire reads it, out loud, on day one, without the tact. Most teams experience that as the AI being bad at their codebase. It is worth asking, at least once, whether the AI is being accurate about their codebase.

The wall chart of the future cannot tell you

There is a genuinely useful map of this territory, and I want to credit it before I argue with it. Amalfitano and ten co-authors, in a 2026 ACM TOSEM roadmap, sort GenAI in software engineering along two honest questions: what is being augmented (your process or your product), and how autonomous it is (does it wait for you, or act on its own).

That gives four clean forms, the Copilot, GenAIware, the Teammate and the Robot. As a shared vocabulary that beats the usual “AI for SE” hand-waving, and I will happily use it.

Then the same paper closes with ten predictions for 2030, and the precision is where it gets funny.

• 70% of boilerplate autonomously generated

• “Prompt Architect” a certified job title

• 40% of job postings requiring it

• 20% of teams in regulated industries carrying a dedicated role.

These are not ranges or scenarios. They are two-significant-figure forecasts for a field that cannot reliably tell you what next quarter’s model will cost. And in the acknowledgments, the authors note the predictions were brainstormed with Claude Sonnet 4.5, off a literature review filtered by two other models. A roadmap for GenAI in software, whose boldest numbers were generated by GenAI.

The taxonomy is real work, so I say this without malice: the map of the future is cheap to generate and getting cheaper, and it will never tell you whether the model is in your loop this week.

The gap between present and in-the-loop shows up one layer down too. Moonshot just released Kimi K3 with open weights, and plenty of people read “open weights” as “we can run this ourselves now.”

The weights are about 1.5 terabytes and need multiple top-end GPU nodes to serve. Downloadable, yes. Runnable on your very expensive macbook or even a server under your table, no.

And a model can top the public leaderboard and still not be the one a team ships with, because fit to the actual work, the cost of a wrong answer, and where it sits in the pipeline decide more than the benchmark does.

Route the cheap work to the cheap model, keep the expensive judgment where it earns its keep, and stop confusing a model you can name with a model that is doing your job.

Present is not in the loop, at the model layer and the org layer both.

The one number

So how do you tell present from in-the-loop without a slide? One number: the acceptance rate of the model’s work. The share of what it produces that you ship without a human redoing it.

Not seats. Not tokens burned. Not “queries this month,” which measures that people opened the tool, not that the tool did the job. Usage is the vanity metric of AI adoption - it goes back to when we started doing BI dashboards and competed which teams had more.

Acceptance is the outcome. A usage dashboard tells you the treadmill is plugged in. Acceptance rate tells you whether anyone is running.

This is not just my framing. Albert Ziegler and colleagues, in “Productivity Assessment of Neural Code Completion” (MAPS 2022, expanded in Communications of the ACM in 2024), found that the acceptance rate of a model’s suggestions predicted developers’ own sense of productivity better than the other metrics they measured. The thing you keep is the thing that counts.

Which is why the one number I carry from the earlier issues is an acceptance number. That manual review step that went from roughly 8% machine-handled to 80% was never “the model was consulted 80% of the time.” It was 80% of cases closed by the model’s output and shipped, no human redoing the work. The 72 points between those two states is the model moving from in-the-room to in-the-loop on that one step. Had the number instead been “80% of reviewers now have the AI tool open,” we would have been measuring furniture and calling it transformation.

Run the in-the-loop test on your own pipeline

You can tell present from in-the-loop in about 3 questions.

1. Can you say your acceptance rate today, for one real step, as a number? If the only figures you have are seats and logins, you are measuring the room, not the loop.

2. Where the model stalls, is that a model limit or an architecture seam? Point it at your worst file and watch. If it keeps missing, the file is probably doing three jobs, and the model just told you which three.

3. What would you ship from the model without redoing it? If the honest answer is “nothing yet,” the model is present, and you have a build-lever and a mirror problem to fix before you have an AI capability.

Run it on your own pipeline before the next planning cycle, not on a vendor’s demo after.

A model is in the loop only where you ship its work without redoing it. Everything else is furniture with a login.

Coming up

Next week, the body nobody puts a number on: the team. What the org chart has to give up for the model to stay in the loop, and why an acceptance rate that climbs for a quarter and then quietly slides back is almost always a team-shape problem wearing a model costume.

More soon. :-]

Sources

Because none of this comes only from my head. Every link checked.

• The taxonomy and the 2030 predictions: Domenico Amalfitano, Andreas Metzger, Marco Autili, Tommaso Fulcini, Tobias Hey, Jan Keim, Patrizio Pelliccione, Vincenzo Scotti, Anne Koziolek, Raffaela Mirandola, and Andreas Vogelsang, “A Research Roadmap for Augmenting Software Engineering Processes and Software Products with Generative AI“ (ACM Transactions on Software Engineering and Methodology, 2026). Peer-reviewed. The four forms are in the classification section; the ten predictions and the note that they were brainstormed with Claude Sonnet 4.5 are in the concluding section and acknowledgments.

• Acceptance rate as the signal: Albert Ziegler, Eirini Kalliamvakou, and colleagues, “Productivity Assessment of Neural Code Completion“ (Proceedings of MAPS 2022, the 6th ACM SIGPLAN International Symposium on Machine Programming), expanded as “Measuring GitHub Copilot’s Impact on Productivity” (Communications of the ACM 67, no. 3, 2024, pp. 54-63). Peer-reviewed.

• The org mirror: Melvin E. Conway, “How Do Committees Invent?“ (Datamation, 1968). The origin of Conway’s Law.

• Kimi K3 open weights and hardware footprint: Moonshot AI’s Kimi K3 open-weights release (July 2026), reported by The Week and others; the roughly 1.5 TB weight size and multi-node serving requirement come from the release and deployment coverage. Vendor release and press, not peer-reviewed.

I make this Substack thanks to readers like you!

Subscribe now

It is wrong before the first bar starts. Not because the order is wrong, but because there is no right order.

The three things on that wall are not three projects waiting their turn. They are one big sociotechnical system, and each part pulls on the other two the moment it moves.

Issue 1 named the failure: sequencing is the trap.

Issue 2 named the destination: AI-native, not AI-ready, and you buy AI-ready by default.

This is the machinery underneath both. The three bodies themselves, what each one is, and what “moving together” looks like on a real roadmap instead of a slide.

Subscribe now

No kit this week. Just the machinery, and the standing ask: if you have run one of these, subscribe and tell me where I am wrong.

Why three bodies, not three projects

Borrow the name honestly. In celestial mechanics, two bodies under gravity have a clean solution: you can write down where they will be forever. Add a third and it collapses. Henri Poincaré showed in the 1890s that the three-body problem has no general closed-form solution. Each mass pulls on the other two continuously, so you cannot compute one path while holding the others still. This is settled mathematics, not a metaphor I am stretching, and it is why we fly spacecraft through these systems with continuous course corrections instead of one equation.

That is your transformation. The three bodies are the architecture (the system you are rebuilding), the teams (the org that owns it: topology, cognitive load, decision rights), and the AI capability (what the model now makes buildable, and how it reshapes the other two). Move one and the other two move, whether you planned for it or not. Rebuild the platform and the team that owned the old one is now shaped for a system that no longer exists. Put a model in the loop and what is even worth building changes, and the team shape with it.

Sequencing assumes you can freeze two bodies while you work the third, then unfreeze them. You cannot. Nothing holds still while you take your turn.

Body one: the architecture

These are your systems being constantly stressed and rebuilt, and it is the one everyone books first because it feels like the foundation. It is also the one that yanks the other two hardest. A real modernization does not just swap the runtime. It changes where work happens, which means the team that grew up around the old system is now organized for a shape that no longer exists, and the AI you were going to add later suddenly has a very different surface to attach to. You cannot finish this body and hand a stable artifact to the next program. The moment it moves, it has already reached into the other two.

Body two: the teams

Melvin Conway said it in 1968 and it has never stopped being true: a system’s design mirrors the communication structure of the org that built it. Move the architecture and leave the org boxes where they were, and the old structure quietly pulls the new system back into its shape. This is the reorg that does not take, the one that gets celebrated at launch and reverts by the next quarter.

Team Topologies (Matthew Skelton and Manuel Pais, 2019) gives this a handle: organize teams around the flow of the work and manage cognitive load deliberately, or the load lands on people anyway, uninvited. The team body is not an HR exercise you run after the platform ships (or worse, an excuse for a reorg). It is the difference between a system that holds and one that erodes back into the org chart that predates it.

Body three: the AI capability

The third body is not a library you consult. It is a capability in the loop where the work actually happens, in how code gets written and reviewed, how a platform validates itself, what a team can take on. And it does not sit politely inside the box you drew for it in FY3. It reshapes the other two. It changes what is worth building at all (that is the architecture body moving again) and how many hands a thing takes (that is the team body moving again). Bolt it on at the end and you get AI-ready: a structure that can hold AI, sitting next to a system that never changed to use it. Put it in the loop from the start and it pulls its weight, and pulls on everything else.

Moving together is a verb, not a Gantt chart

Here is the part the wall chart cannot show. Steering three coupled bodies does not look like three bars in a row. It looks like one program that replans continuously, because every time one body moves you re-solve the other two. A platform decision changes the team plan this week, not next year. An AI capability lands and the backlog it was supposed to accelerate turns out to be the wrong backlog, so you change what you are building.

This is also why the vendor split is so expensive. Run modernization with a systems integrator, the org change with a transformation firm, and the AI with a separate consultancy, and you have handed the three coupled bodies to three parties who each optimize their own and none of whom own the coupling. They do not compound into capability. They compound into dysfunction, on three invoices. The alternative is not a bigger program. It is one operator holding all three, with no hand-offs across the seams where the pull actually happens.

The smallest complete example, the whole thing in motion

The cleanest version I have run looked like this. One mandate that, on a normal roadmap, would have been three projects in a line. We rebuilt a batch platform into one that ran in real time. We restructured the team around the flow of the work instead of the old function boxes. And we put a language model into a manual review step, the kind where people used to grind through a queue by hand, and took it from roughly 8% machine-handled to 80%.

Told as three programs, that is a modernization, then a reorg, then an AI pilot, each waiting on the one before it, and the review step stuck at 8% the whole time while everyone waits their turn. Told as one program, it is three bodies moving together: the platform made real-time work possible, the team shape made the platform hold, and the model in the loop was the thing that made the whole rebuild pay. Not the AI beside the process. The AI as the process, on a platform and a team reshaped to own their flow of work.

Run the coupling test on your own program

You can tell steering from sequencing in about three questions:

1. How many budgets and owners do the modernization, the org change, and the AI sit under, and on whose timeline? Three separate ones, each with its own year: you are sequencing.

2. What happens to the team plan when the architecture slips a quarter? If the answer is “nothing, that is a different workstream,” the bodies are not coupled on paper, which means they will collide in practice.

3. When does the AI capability get to change what you build, not just how fast? If the answer is “after the platform is done,” the third body is bolted on, not in the loop.

Run it on your own program before the next planning cycle, not on a vendor after.

The whole thing, in one line

You do not sequence a system whose parts pull on each other. You steer it. Together, or it does not really move at all.

Coming up

Next week I go hands-on inside one body, the AI capability, and what “in the loop” actually means in the delivery pipeline: the model as a build lever, the model as an architectural mirror, and the number that tells you it is working instead of just present.

More soon. :-]

Sources

Because none of this comes only from my head. Every link checked.

• The physics: the three-body problem’s lack of a general closed-form solution is due to Henri Poincaré (1890s); a standard scholarly treatment is June Barrow-Green, Poincaré and the Three Body Problem (American Mathematical Society, 1997). Scholarly / peer-reviewed.

• The org mirror: Melvin E. Conway, “How Do Committees Invent?“ (Datamation, 1968). The origin of Conway’s Law.

• The team body: Matthew Skelton and Manuel Pais, Team Topologies (IT Revolution, 2019). Practitioner book, not peer-reviewed.

• The operating-model failure mode (callback to Issue 2): Mik Kersten, Output to Outcome (IT Revolution, 2026). Practitioner book.

I make this Substack thanks to readers like you!

Subscribe now

The internal assistant answers a question about the travel policy. The “AI knowledge base” comes up on the big screen and people are genuinely proud of it. A slide says the pilots will save 4k hours/year and that number came out of the vendor’s ROI calculator, which has never met this company’s actual work and is therefore free to be optimistic.

And the delivery pipeline, the thing that turns an idea into software running in production, has not changed a single stage since before any of this was bought.

That company is AI-ready. It believes it is AI-native. The real story of the program is not whether the AI works, it is that nothing about how the company operates changed around it.

Last week I closed with a tell: if your proudest AI artifact is a reference library and your pipeline has not changed a stage, you already know which one you bought. This is that essay, the one Issue 1 existed to set up:

Subscribe now

No kit this week either. Just the argument, and the standing ask: if you have run one of these programs, subscribe and tell me where I am wrong. The interesting version of this idea is the one that survives contact with your actual estate.

AI-ready is what the money buys by default

I keep walking into the same project. A company decides this is the year of AI. It buys the licenses, stands up an internal assistant, writes the knowledge base, runs a few pilots, and puts a number on a slide. On paper it is an AI company now. The paper is doing a lot of work.

Underneath, the operating model is exactly what it was the year before. The estate is the same. The way work moves from idea to production is the same. The AI is sitting next to the system, not inside it.

That is AI-ready: a structure that can accommodate AI. It is not nothing. The licenses are real, the assistant answers questions, the knowledge base is genuinely tidy. But it is not what the buyer thought they were paying for, and it is not where the value is.

AI-native is a difference in kind, not degree

AI-native is an operating model built around AI as a live capability in the workflow. The model is in the loop where the work actually happens: in how code gets written and reviewed, how decisions get made, how the platform validates itself. Not a library you consult. A capability you run.

A word on the words, because a book already uses some of them. I am not trying to claim “AI-native” as mine. Melissa Reeve’s Hyperadaptive: Rewiring the Enterprise to Become AI-Native (IT Revolution, May 2026) is built on the term, and plenty of vendors have discovered it fits nicely on a homepage. The term is cheap. The how is scarce. Own the how, not the label.

Mik Kersten just gave this failure its proper name

Mik Kersten’s new book, Output to Outcome: An Operating Model for the Age of AI (IT Revolution), is out today, and it lands squarely on the mechanism: organizations get very good at producing output and never move the outcome.

AI-ready is that failure with a bigger invoice. You ship more output than ever, an assistant, a knowledge base, a dozen pilots, and the outcome the business actually feels sits exactly where it sat the year before. The victory-lap meeting is a celebration of output. The outcome was not invited.

When I talked to Mik about this essay, he pointed me at Chapter 7, “Matrix to Modularity”, and he was right to. It is this argument run from the organizational end. “AI and agentic solutions can create tremendous output, especially when working within modular structures,” he writes. Most incumbents are not modular. They are a matrix of dependencies, dotted reporting lines, and meeting cadences layered over meeting cadences, and the AI gets bolted onto exactly that.

His answer is a concept called sociotechnical congruence: design the organizational structure and the technical structure to fit each other, on purpose, because “even with the best architectural intentions, a tangled organizational structure will create a tangled technical architecture.” Readers of Issue 1 will recognize this. The sociotechnical wiring I complained was missing from the operating-model textbooks just showed up in one. It went on sale this morning.

Kersten has been pulling on this thread since Project to Product, and this is the sharpest frame I have found for why that meeting feels so hollow. If you are going to read one book on the operating-model side of AI this quarter, make it this one.

Sequencing is how you buy AI-ready twice

The reason most transformations land on AI-ready is that they sequence. Modernize the architecture this year. Reorganize the teams next year. Add AI on top after that. Three programs, three budgets, three sets of consultants, each a success on its own terms. And AI-native falls out the bottom, because by the time the AI arrives, the architecture it lands on is a year stale and the teams are still shaped for the old flow.

You do not get to AI-native by sequencing. The architecture, the teams, and the AI capability pull on each other. Change the architecture and the teams that own it have to change. Put AI in the loop and what is even worth building changes again, and the team shape with it. They move together or they do not really move at all.

For a European buyer the framing that matters is cost and risk, not growth. The cost of AI-ready that looks AI-native is the second migration. You spend the budget, you get the assistant and the knowledge base, and eighteen months later the same gap is still open, because the operating model never moved. Then you pay again. The expensive path is not doing the three together. The expensive path is doing them one at a time and discovering you have to redo the first by the time you reach the third.

The smallest complete example I have

The cleanest version of the alternative I have run looked like this: one mandate that, on a normal roadmap, would have been three projects. We rebuilt the data platform, restructured the team around the flow of the work rather than the old function boxes, and put an LLM into the validation step where analysts used to grind through a queue by hand.

On a good engagement, that one-pass version is the difference between a grinding manual step running at roughly 8% machine-handled and the same step at 80%. Sequenced, it stays at 8% three times in a row, once per budget.

Not three projects in a line. One. The AI was not beside the process. It was the process, on a platform and a team that had been reshaped to hold it. That is AI-native in miniature.

The five-minute tell, ready to run

You can spot AI-ready pretending to be AI-native in about five minutes. Three questions, and you can ask them in any order:

1. Ask to see the proudest AI artifact. If it is a knowledge base or a reference kit, mark it.

2. Ask what changed in the delivery pipeline since the AI program started. Same stages, same hand-offs, same lead time: mark it.

3. Ask where the ROI number came from. A generic calculator instead of a measured before-and-after on real work: mark it.

Three for three and you bought the structure, not the capability.

Run it on your own shop before the next AI budget goes out, not on a vendor after. It is less fun that way, and considerably more useful.

The whole distinction, in one line

AI-ready is a structure that can hold AI. AI-native is an operating model built around it. The invoice looks the same. The year after does not.

The good news is that the fix is not more AI. It is moving the three bodies, the architecture, the teams, and the AI capability, at once.

Coming up

Next week I open up the machinery: the three bodies themselves. What each one actually is, what “moving together” looks like on a real roadmap instead of a slide, and one concrete example of the whole thing in motion.

More soon. :-]

Sources

Because none of this comes only from my head. Every link was checked.

• The frame: Mik Kersten, Output to Outcome: An Operating Model for the Age of AI (IT Revolution, 2026), released 14 July 2026. Quotes are from Chapter 7, “Matrix to Modularity”, in the Kindle edition. His earlier Project to Product (IT Revolution, 2018) started the thread.

• The term: Melissa M. Reeve, Hyperadaptive: Rewiring the Enterprise to Become AI-Native (IT Revolution, 2026).

Both are practitioner books, not peer-reviewed research. That is fine. So are these field notes.

I make this Substack thanks to readers like you!

Subscribe now

An analyst opens a validation queue every morning and works it by hand. Check the figure, check the source, flag the ones that smell wrong, escalate the rest. Skilled work, and most of it deadening.

I got to take that apart in different customers. We rebuilt the platforms underneath it, restructured the teams around the flow of the work instead of the old function boxes, and use AI when needed while prioritizing good software engineering practices. And not a single time we managed to fully automate the processes... we could speed up things, reduce toil... and that is what I want to keep on doing.

Here is the part that matters, and it is not the model.

It never was only about three projects, but always about 1 mandate. Rebuild the systems, reshape the teams that owns it, put AI in the loop when it makes sense and where the work actually happens, all at once… because any one of them alone moves the number by roughly nothing.

Everyone wants to talk about the GenAI model (“open weights is better, while the new claude/gemini/anthropic is this and that”) ... but that is the easy part. The hard part, the part that on a good engagement moves a grinding manual step from roughly 8% handled by a machine over 1 week of work to 80% automagically going in 2h, was that the platform, the team and the model were built to fit each other in a single pass. Do those in sequence, a year apart, three budgets and three sets of consultants, and you get three tidy successes and a number that never budges.

That gap is the thing I keep coming back to. It is the whole reason for this.

Who is writing this

I am Thiago. Twenty years ago I was a statistician in Brazil, then a data scientist, a DBA, a software engineer, data engineer, a hands-on architect, then a CTO… these days a recovering CTO who still writes the code and knows that systems design while keeping myself at the trenches is what makes me happy. The recovering part is that I have run orgs internally, sat as interim head of _fill the gap_, been on the hook for the quarterly number and still never managed to fully close the loop only with tech.

Most of my recent years went into modernization and into getting generative AI into how software actually gets built, not into slides about how software might one day get built.

This is issue one. Every week I am going to work one problem out loud here: architecture modernization, team design, and AI capability as a single program, written by someone still in the code and not narrating it from a stage.

No downloadable kit this week. No five-box framework in a tidy PDF. Just the argument, and an ask. If you have lived this, subscribe and tell me where I am wrong. That is not a growth tactic, it is genuinely half the point, because the interesting version of this idea is the one that survives contact with your actual estate.

Subscribe now

Everybody already has an operating model. Almost nobody wrote it down.

Every company I walk into already has an operating model, whether or not anyone calls it that. It is just how IT creates and delivers value: who owns what, how work moves from an idea to something running in production, where the decisions actually get made versus where the org chart says they do.

Most companies never wrote it down. The ones that did wrote a box diagram, and the box diagram has not been opened since the offsite where it was drawn.

None of that is wrong, exactly. It is just not the part that decides whether you ship. The part that decides is whether the architecture, the teams, and the AI capability were built to fit each other, or merely filed in the same org chart and left to work it out.

The textbooks are winging it too

I went and read the research on this properly, because I wanted to know whether the academics had a cleaner answer than I did.

They do not, and I can point you to the receipt.

In 2025, Suleman, Pekkola, Ralyté and Ahola published a systematic review in Information Systems Management that went through 77 academic and consulting sources hunting for an agreed definition of the IT operating model. It came back without one. The number of components the thing is supposed to have swings from four to thirteen, depending mostly on which consultancy is holding the pen. It is open access, so you do not have to take my word for it: the link is in the Sources at the bottom, go argue with it yourself.

The people whose actual job is to define this cannot agree on what it is or how many pieces it has. I find that oddly reassuring. If you have ever sat in a transformation kickoff quietly unsure what “operating model” meant in that room, relax: neither does the literature.

They drew the box. They skipped the wiring.

Here is the more useful finding from that same review, and it is the one that explains your last reorg.

The research treats the operating model as a structure. Decision-rights grids. Boxes for standardization versus integration. Who reports to whom. All of it about shape.

The one principle that would make the thing actually work is mostly missing: designing the technical side and the human side to fit each other, on purpose, at the same time, instead of optimizing one and inheriting the other. That idea is not mine either. It is called joint optimization, and it has been around since Trist and Bamforth’s coal-mining studies in 1951. Somehow it never explicitly made it from the sociotechnical-systems literature into the operating-model textbooks. Tune the tech, take the team as given. Or reshuffle the team, leave the systems where they were. Either way you optimized one subsystem and let the other one ride along as a hostage.

That is why the last reorg did not take. You moved the boxes and the systems stayed exactly where they were. And it is why the AI pilot is sitting next to the work instead of inside it, technically running, in the sense that a treadmill in a spare room is technically a gym.

There is one idea the academics keep underusing that every engineer already lives: your system ends up shaped like your org chart. Conway named it in 1968, in a paper literally titled “How Do Committees Invent?”. Skelton and Pais turned it into a practice in Team Topologies. Org structure and system architecture are the same problem, which is exactly why you cannot move one and expect the other to hold still.

On AI, the theory has not shown up yet

Now put AI into that picture, and it gets funnier.

The most cited frameworks for an AI-era operating model are not peer-reviewed. MIT CISR put out a research briefing on it in late 2025 (Thorogood and Woerner, “Enterprise IT Operating Models in the AI Era”). The fashionable “agentic operating model” comes from a 2026 California Management Review Insights column (Saini, “Governing the Agentic Enterprise”), which is editor-screened online commentary, not a peer-reviewed journal article. Both are thoughtful. Both are essentially field notes with good production values. Nobody has settled research on how AI actually reshapes the operating model. Practice is ahead of theory here, which is a generous way of saying we are all making it up, and the only real difference is who is keeping honest notes.

That greenfield is exactly what this newsletter walks into.

And it matters more than it sounds, because AI does not stay a tool for long. It becomes an actor in how your organization operates.

When Air Canada’s chatbot confidently invented a bereavement-fare policy that did not exist, the airline’s defense at tribunal was that the chatbot was “a separate legal entity responsible for its own actions.” They lost (Moffatt v. Air Canada, 2024 BCCRT 149, if you want to watch a tribunal politely decline to believe a company). They paid about 812 Canadian dollars, plus the legal time, which I promise cost more than that.

The lesson is not that the chatbot was dumb. The lesson is that when AI becomes part of how your operating model runs, the accountability does not get to spin off into a separate legal entity. It is still yours. You have quietly hired a coworker who can commit the company to things, cannot be fired, and will never once feel bad about it. Deciding where that coworker sits, and what it is allowed to promise, is an operating-model question. It is not a procurement one.

Four questions to run on your own operating model

You do not need a new framework for this. You need four honest answers about your own shop.

1. If you changed the architecture next quarter, would the teams that own it have to change shape? If the answer is no, those are not the teams that own it.

2. Where does your AI actually sit: in the loop where the work happens, or beside it, in a knowledge base people are proud of?

3. When the last reorg landed, did the systems change, or did the boxes move while the systems stayed put?

4. Name the number your AI moved. Not tokens processed, not seats licensed. The business number. If you cannot name it, you bought the structure, not the capability.

If those questions sting a little, good. That is the material.

The whole thesis, in one line

Architecture, teams, and AI are one program, or they are three expensive rehearsals. Three moving parts, one mandate, a number at the end.

That is what I am here to work out, in public, every week, with my hands still in the code.

Coming up

Next week I go straight at the piece that started all of this: the difference between being AI-ready and being AI-native, and why most transformations buy the first, call it the second, and pay AI-native money for the privilege.

Quick tell before then. If your proudest AI artifact is a reference library and your delivery pipeline has not changed a single stage, you already know which one you bought.

More soon. :-]

Sources

Because none of this comes only from my head. Every link below was checked.

• The definition problem: Suleman, Pekkola, Ralyté and Ahola, “IT Operating Models: A Systematic Review of Academic and Practitioner Literature,” Information Systems Management 43(1), 2025, 22-44. Open access, DOI 10.1080/10580530.2025.2513305.

• Joint optimization: Trist and Bamforth, “Some Social and Psychological Consequences of the Longwall Method of Coal-Getting,” Human Relations 4(1), 1951, 3-38, the founding sociotechnical-systems study.

• Conway’s Law: Melvin Conway, “How Do Committees Invent?,” Datamation, 1968. Turned into a practice in Matthew Skelton and Manuel Pais, Team Topologies (IT Revolution, 2019).

• AI-era frameworks (not peer-reviewed): Thorogood and Woerner, “Enterprise IT Operating Models in the AI Era,” MIT CISR Research Briefing XXV-12, December 2025; Sandeep Saini, “Governing the Agentic Enterprise: A New Operating Model for Autonomous AI at Scale,” California Management Review Insights, March 2026.

• Air Canada’s chatbot: Moffatt v. Air Canada, 2024 BCCRT 149 (British Columbia Civil Resolution Tribunal); the airline was ordered to pay 812.02 Canadian dollars in total (650.88 damages, plus interest and fees).

I make this Substack thanks to readers like you!

Subscribe now

I help companies modernize their architecture. They want to talk about Kubernetes. I end up explaining why Kate is burned out at 0.25 FTE across four workstreams.

I’m a recovering CTO who still writes the code. TilinTheCloud is an independent practice where modernization, team redesign, and GenAI adoption run as one program, not three. I call it the Three-Body Program: architecture, teams, and AI capability, moving together. Most enterprises run them as three separate tracks, and the gaps between them are where the program stalls. This newsletter is where I think out loud about closing those gaps.

What to expect (roughly once a week)

• How modernization, team design, and AI actually move together, and what breaks when you sequence them instead.

• Field notes from someone still in the terminal, not just the boardroom. Every claim anchored to something hands-on, with a number on the outcome.

• The occasional satirical interview with a clueless executive who genuinely believes “platform engineering” is something you can purchase.

Twenty years from statistician to CTO to hands-on architect. I’ve run these programs from the inside at GRESB, Nike, with LINKIT, and from the CTO seat.

The common thread? Kindness. Not as a values slide. As an operating principle. You can’t optimize systems while measuring humans in decimal points.

If your architecture is six months ahead of your teams and your GenAI strategy is a deck instead of a system, you’ll feel at home here. Subscribe and let’s talk.