Let AI Decide the Flow: A Company's Next Step with AI Is a Contract

When everyone’s AI grows into its own shape, what a company needs to standardize is no longer the flow, but the contract between one AI and another.

In the previous article, I argued that once a company brings in AI, instead of writing yet another, more detailed SOP, it’s better to define a data-structure contract for inputs and outputs, set checkpoints where they’re needed, and let AI handle how to get from one to the other. It ended on this line: “We don’t even have a fixed process for the process itself. We only focus on the final output.” That sounds clean and decisive, at least on the surface, but what happens after you hand the flow over to AI is something that article didn’t finish.

If the flow really is handed over to AI, what’s left for the company to define? And once every department’s AI has grown into its own shape, how are they supposed to communicate with each other?

From Writing Programs to Letting AI Shape the Flow: Three Stages

To answer that, I want to zoom out on the timeline first and look at how we’ve been handing things over to AI these past few years. If you ask the same question at every stage — how much stays fixed, and how much decision-making power gets handed over? — you can see three pretty clear steps.

Stage one: have AI write a program. The very first approach was to use AI to write a program that solves one problem. The upside is that it’s “mechanical, controllable, fixable, standardized, and once the program is done, we don’t really need AI anymore.” Here AI is more like an outsourced engineer who delivers and leaves, and nearly all of the decision-making power is hard-coded into the program. The downside is that as soon as the program has to move, problems pop up one after another — across operating systems, across hardware platforms, across datasets — so you end up building all kinds of adapters for different datasets. That’s the idea behind early APIs: let one component handle a certain task, but define its format and its input/output interface in advance.

Stage two: insert AI at a node. The next step is to wire AI into nodes in the flow, letting it make decisions on the parts that call for fuzzy judgment, picking the right option from a set of existing ones. Here, the role we give AI is more like a reviewer who can only tick boxes. Jev, which TypeSafe released on September 15, is built specifically for this, to speed up the whole flow: it returns choices, scores, or Boolean-style answers (Yes or No) with probabilities, designed for classification, routing, scoring, extraction, and other “bounded decisions”^[1]. In this kind of flow design, we still keep most of the outcomes fixed, but we give AI some decision-making power, replacing what humans used to do at certain nodes. The flow becomes more flexible as a result, able to adapt to more situations, and even take on more variations.

Stage three: let AI decide the flow itself. Since last year, the new trend has been to open up further and let AI decide the flow on its own. What gets fixed is no longer the flow itself, but the goal the flow is meant to reach. How many steps to take, which step comes first, which step can be skipped — AI decides. At this stage, AI is more like a project manager who’s handed nothing but the goal and plans the work on their own.

Put the three stages side by side and you get a line of decision-making power moving steadily outward. The outsourced engineer finishes the program and hands the decisions back to the program. The reviewer ticks boxes inside the options we’ve drawn. The project manager draws the boxes themselves.

LLM Wiki: Everyone’s Is Different

The best example of stage three is probably the LLM Wiki that’s so popular right now. An LLM Wiki isn’t a fixed program architecture or a fixed database — it isn’t even a fixed tool. Karpathy is very clear about this in his gist: “This document is intentionally abstract. It describes the idea, not a specific implementation.” And: “The exact directory structure, the schema conventions, the page formats, the tooling — all of that will depend on your domain, your preferences, and your LLM of choice.”^[2] What the original author put forward is just a methodology, a framework, and a flow for letting AI build up a whole body of knowledge. He even says outright that the document’s only job is to get the pattern across, and things like directories and pages are for your AI to figure out. In other words, it’s handed to the user — or more precisely, to the AI in the user’s hands.

So each user decides what their LLM Wiki should look like based on their own situation and data needs, on how the AI model they’re currently using reads things, or on the shape of the data they feed it. My own Agent Em is one example. As I mentioned when I wrote about the knowledge system, Em’s wiki applied a methodology from one of the internet’s big names and grew from 28 pages to 120 files. The methodology was borrowed, but the shape it grew into is mine. Those categories, those cross-references, all came out of ingest after ingest, driven by my needs, my questions, and my data.

Once an LLM Wiki like this is built, it’s really just a version specialized for that one user. Swap in a different person, and the LLM Wiki could look completely different.

You might ask: doesn’t that make data exchange pretty bad? Doesn’t the LLM Wiki end up defined differently on every person’s computer? The answer is yes. But that’s exactly what I mean by AI customization.

In the previous article I said that customization doesn’t mean every department doing its own thing. Here I want to slow down on that word a bit, because in a company, “customization” often gets taken to mean hard to maintain, hard to hand off. That’s not what I mean. AI customization means the methodology can be shared, but every implementation grows into its own shape according to the user’s situation. That doesn’t mean there’s no standard. The design allows for, and even encourages, this kind of outcome: one shared pattern, many different shapes.

What to Standardize Is the Contract, Not the Flow

So what about data exchange? In this situation, what we need to think about isn’t whether the thing itself has been normalized, standardized, or turned into a process; what we need to think about is whether, when we need to exchange data or knowledge, the output speaks a common language. In other words, what the “contract” for AI-to-AI communication should look like.

This contract can be looser than we’d expect, because traditional data specs define formats, values, and fields down to the last detail. But if the contract lets two AIs communicate and each get done what they need to do, then in some situations we don’t have to hard-code how the data is defined — we can even let the two AIs negotiate it themselves. The contract can step back from data formats, values, and fields to “how two AIs communicate toward a given purpose.” As long as the goal gets met, exactly which fields and formats they use to exchange data, and how the data gets stored and passed along, isn’t all that important in the age of AI.

But when it comes to data involving finance, regulations, ISO certification, and the like, we still need to set certain rules, defined by humans up front rather than left for two AIs to negotiate.

The same problem has a counterpart in an Agent Team. In the five-layer decision model I put together when looking at Agent communication through OS IPC, the top layer is L4 Content Contract, which decides “what to send.” Back then I borrowed a former colleague’s take: this is the layer every system today handles most crudely. That’s true between Agents, and I think it’s true between departments in a company too. Connecting the pipes only gets the data delivered; L4 decides whether the other side can actually use it once it arrives.

Going back to that database-spec debate at the start of the previous article, the one that never reached consensus, my answer wasn’t a single unified spec. It was: each department keeps its own spec, and everyone shares one contract they can all read. That’s this idea’s first step in a company setting.

So the next step for a company bringing in AI isn’t to set more AI standards. It’s to create a contract that lets AIs exchange data and talk to each other, because only then can an ecosystem that holds that contract up grow inside the company. So what we need to define is how responsibilities and obligations are divided between departments, and, for each problem we’re solving, how the AIs communicate with each other.

What this idea really does is make AI the main actor in the company, so that AI becomes the one picking up and exchanging data between departments, while humans only guard the checkpoints that need oversight.

What If the AI Goes Offline? Can We Trust AI?

Of course, once AI becomes the main actor, a contract-centered architecture like this can look too radical to some traditional IT folks, and the concerns are just as direct: what if the AI service goes down? What if these models can’t be reached one day, or get really expensive? And how can you trust AI’s judgment? What happens when it gets something wrong?

Sound familiar?

Yeah. Honestly, we went through something similar not long ago. Around 10 to 15 years ago, when the cloud was just taking off, plenty of people thought cloud services were unreliable: what if the network goes down and we lose the cloud service? Keeping data on-prem, in our own hands, means better control. Fast forward to today, and lots of companies run their entire services in the cloud. We used to worry that a cloud outage would take our services down with it — instead, it’s on-prem network outages that end up breaking service, while the cloud, with help from geo-redundant backups, multi-cloud hosting, and Edge Computing, delivers services to users in different regions over a more complete network architecture and turns out to be more resilient. As for AI’s judgment, it’s a lot like the journey of self-driving: we went from not believing AI could drive a car to millions of Teslas on the road every day (cumulative production passed ten million in July 2026).

I think humans and systems always find a way, and usually through methods we couldn’t have imagined at the time. AI will probably go down the same road and become what we call infrastructure. So rather than worrying about what to do if AI goes offline, it’s better to think about how we respond when it does. I believe those mechanisms will be developed soon. For now, setting up your own compute in the cloud and serving your own models, instead of depending entirely on external AI models, is also a stopgap.

What actually worries me is something else. A contract-centered architecture like this won’t just appear out of thin air once problems show up. If we don’t start laying the groundwork now, what we’ll be catching up on later won’t just be setting up server rooms or AI models — it’ll be rebuilding the entire internal data structure around AI. And the structures and data we’ve built with AI over the past few years don’t follow this model at all, so a lot of it won’t carry over directly. In other words, we’re going to go through two or three rounds of AI rebuilding, and those rebuilds are things we could, and should, already be discussing or doing now.

As for what this contract looks like in my own hands, in the practice article I lay out two tools I built myself. What they spell out is what to deliver and how to check it, not how to walk through it step by step.

The flow can be handed to AI, but the language AIs use to talk to each other is something we have to define first.

Maybe, at this point in time, the question we should ask ourselves isn’t whether we’re ready to use AI yet. It’s what your next step is: writing an even more detailed AI SOP, or writing a contract that lets AIs understand each other?

References

^[1] Let’s Data Science — TypeSafe Jev launch (2026-09-15; supports “the model returns choices, scores, or Boolean-style answers with probabilities.” and “Jev is designed for classification, routing, scoring, extraction, and other bounded decisions where an application needs an answer it can use directly.”)

^[2] Andrej Karpathy — LLM Wiki gist (2026-04-04; supports “This document is intentionally abstract. It describes the idea, not a specific implementation.”, “The exact directory structure, the schema conventions, the page formats, the tooling — all of that will depend on your domain, your preferences, and your LLM of choice.” and “The document’s only job is to communicate the pattern. Your LLM can figure out the rest.”)