Process Isn't the Point — the Contract Is

When departments can’t agree on a data spec, don’t rush to unify the spec. What you need first is a contract everyone can read.

Here’s a recent example. A few departments wanted to build a central database to serve as the core AI would use to exchange data, so everyone started talking about a grand unified database spec. Just like in theoretical physics, they were hoping for one solution that would settle everything once and for all. Sounds reasonable. After all, if you’re setting up a shared database, agreeing on how to store things is usually step one. But that’s exactly where the trouble started: everyone had their own picture of how the data should be handled and passed along, so the arguing went back and forth and nothing ever landed. If you’ve ever handled a cross-department project, this scene probably looks familiar. Each department’s idea makes sense on its own, but stack them all together and you realize it’s like several maps drawn at different scales: no matter how you line them up, they never quite match.

At times like this, there’s always some small fry hiding in the corner who gets handed the task by the boss (yes, whatever can’t be settled always lands on someone’s desk eventually, someone like me). My answer wasn’t to just hand over a database spec. Instead: every department can keep its own spec, but we need a shared language, a contract, so that everyone can understand what the others are doing, what each piece of data means, and where to go to access it.

How is that different from a spec? Why not just hand over a spec and be done with it? Honestly, if I’d thrown out a spec too, at best there would just be one more map on the table, drawn at yet another scale. If it worked (or, in the end, didn’t), it would only be because I’m the one in charge and the boss trusts me right now, not because it actually solves the problem. So if we really want to solve the problem, we have to go back to the source, which is the better way to help every department. And all of this starts with where SOPs came from.

Why SOPs Were Born, and Why They Became Dead Weight

Of course, I’m not saying companies don’t need SOPs or standard processes. From the point of view of how a company operates, a large company needs a high degree of internal coordination to avoid friction, which is exactly why workflows and SOPs were born inside companies in the first place. When departments or units collaborate, standardizing the process and following an SOP lets different departments work on something complicated at the same time without much back-and-forth communication. An SOP that breaks the work down into well-defined steps and options lets requests or development move forward efficiently and quickly, with less time spent on revisions and confirmations. That’s an SOP as it’s meant to be: a map everyone can read.

But as a company grows, that structure grows with it, and efficiency actually starts to slide. That’s because things get more complicated and more fragmented, so the process gets split too finely and there are too many things to confirm, until confirming becomes a cost in itself. It’s like the map getting drawn in more and more detail, until it’s more complicated than the road itself, and the person using it has to stop at every step to check the map again, which only makes it take longer to get where they’re going. If you’ve ever had a small change go through round after round of confirmation just because of an SOP, you probably know what I mean. At that point, the SOP has become the very thing tying down a company’s ability to change, and tying the hands of the people doing the work, and it has lost its original purpose. Not because there’s anything wrong with the design, but because it grew too big.

We’ve Been Talking About the Same Data All Along

Thinking about all those cross-department handoffs, have you ever felt that a lot of data exchange isn’t real processing at all, and we’re just describing the same data in different ways?

That’s actually only natural. Each department needs specific information to do its job, so it emphasizes the parts of the data that matter to it and downplays the parts that don’t. Along the way, everyone grows their own formats and processes. But in the end, those processes are just the same data being transformed as it flows in and out. It’s a bit like the same Excel file being saved as a new copy in every department: delete two columns here, run some totals and add a column there, rename a field, until the filename becomes “Final_revised_v3”. Open it up, though, and it’s still saying the same thing.

That’s also why the database spec from the beginning could never be settled. Every department wanted to shape the same data into the form it needed, and asking everyone to unify on one spec meant asking each department to give up its own specialization. Yet those specializations are exactly how each of them does its job well. Seen that way, it’s no surprise the argument went nowhere. What everyone was fighting over wasn’t the data itself, but what that data should look like in their own hands.

Let AI Exchange the Data First

Since AI entered our work, quite a few teams have tried to use AI to redefine how data gets exchanged, speeding things up by letting AI handle the structured information in the process that’s already standardized or already has an SOP. Companies a step further along have already tried centralizing this information in a central database and having AI write programs to do the data exchange. Things that used to be split into many steps and confirmed by hand now go through AI reading the same data or sharing the same memory, to reduce the friction of exchanging information. So the steps that used to need human sign-off and confirmation become a flow where AI does the processing and humans sign off.

Once we get to this point, we can start thinking about putting a so-called “AI data contract” at the very start of the process to define the overall framework, letting AI transform or exchange the data on its own and handing that process to different AIs to coordinate. Different AIs in different departments can even read the same data directly and pull out the parts they each need to work on, without having to keep reshaping the data into each department’s preferred form at every handoff. It’s as if all our data went back into different columns of the same Excel file: no more “Save As.” Everyone opens the same file and looks at the few columns they need.

I ran into this once in my Agent Team. As I covered in the earlier article on communication architecture, a unified format is meaningless across heterogeneous Agents. Every Agent’s output structure is different by nature, and forcing a unified format only makes each Agent compress its most valuable structured information into a generic summary. So what I ended up building wasn’t a unified format, but an inspection map and a Return Contract: agreeing on where to look, what to look at, and how short the report has to be. How each Agent is built internally isn’t the point (I won’t rehash the details here). And that’s the first layer of the answer I gave the departments: each department keeps its own spec, and the central database doesn’t need a unified spec. It only needs everyone to be able to find their own piece, and that’s the contract.

But the Data Still Flows Through the Old Process

Even with that change in place, I have to say it: this change makes a good architecture for exchanging knowledge or data, but it still flows within the original process. The data no longer has to be reshaped, but the process itself is still the same process: upstream hands off to downstream, and once the first gate is done you move on to the second. AI makes each handoff faster, but the gates are still the same, and so is the process.

This reminds me of the past few years of using AI. When we first started writing code with AI, we’d manually check the AI’s output and input at every stage. Then we started defining how the AI should use a spec to verify its own output, and which documents it should refer to. Now, two or three years into AI’s development, using AI for software development has become more about defining the framework for the end result, and how we confirm that result actually works. All the development and verification in between is now planned and carried out by the AI on its own, and the idea of an SOP has more or less disappeared.

Coming back to AI data exchange, I think it’s time for companies to take the next step: use AI to de-process / customize. We no longer need to worry about what order, method, or definition a process or its steps should follow. Instead, we define the data-structure contract for inputs and outputs, and set a few checkpoints in between. As long as the structural contract or the output validation at those checkpoints matches the definition, we don’t need to manage, step by step, how the steps and processes in between are carried out.

Has the process disappeared? No. It’s just no longer something we define and pin down one step at a time, because process isn’t the point — the contract is. (Does that sentence sound familiar? Yes, I used the same sentence pattern back when I wrote “Architecture Isn’t the Hard Part — Context Is”. This time, it’s the process’s turn to step aside.)

I tried this idea once on a small scale in my own working directory. When I took stock a few days ago, data was scattered across several places, the same batch of conversation logs had been copied several times, and the same set of skills had one copy for Claude Code and another for Codex. Every one of the dozen-plus shared skills looked different on each side.

This time I didn’t write a classification SOP first. I only set a one-line rule for each of five zones, plus a YAML header format for every file. That’s the contract. Then I added an index:check. That’s the checkpoint. After that, I let a dozen-plus Agents read over a hundred files in parallel and decide for themselves where each file should go. Once the skills were merged into a single canonical copy, Codex reads only name and description and simply ignores the other fields, while Claude Code reads more. The same file, and two AIs each take what they need.

What If Even the Process Isn’t Fixed

So the customization I’m talking about doesn’t mean every department doing its own thing. It means we don’t even keep the process itself fixed. We focus only on the final output. The contract agrees on what comes in and what goes out, checkpoints guard the few places that genuinely need human sign-off, and how things get from one to the other is left to AI.

Back to that database spec nobody could agree on at the start: the contract here is only the first step. The contract lets each department’s data be understood by the others, and tells everyone where to get it, but the path the data flows along is still the same old path. The real question here isn’t getting everyone to follow the same spec. It’s that we should be asking: once the process is handed to AI, what’s left for us humans to define and sign off on, and what kind of contract should AI and AI use to talk to each other?