We keep using AI to automate old processes. POSIWID suggests we should be questioning why the process exists at all.
I was watching Sicario the other night, again, because I listened to an interview with Taylor Sheridan where he talks about writing scenes to create tension. Most scripts follow a 3-act structure, but he uses a 5- or sometimes 7-act structure in a sub-plot to break the expectation of 1,2,3 – something we all now understand and often can already predict the story arc.
In the film, there is an inconsequential, almost throwaway line, where a border patrol officer looks at the situation in front of him and says:
“Well, I guess we’re not following procedure. What do you want to do?”
Now, my brain makes really strange connections. I can’t explain it, but I have learned to listen to it, and to follow these connections down whatever proverbial rabbit hole they lead me down. And this time, it connected with something I read on John Gruber’s always excellent Daring Fireball, but I will get to that in a moment.
I have been spending a lot of time recently designing agents, workflows, skills, and systems. And inevitably, when you design those things, you start designing procedures. First this happens, then that. This agent hands something to that agent, that gets reviewed, and then it gets approved. If this happens, go here; if that happens, go there. All very sensible. All very procedural.
What if we just don’t follow the procedure?
Not recklessly. Not because procedures don’t matter. But because the procedure was designed for a particular way of working, under a particular set of constraints, at a particular moment in time.
What if those constraints no longer exist? What if the question isn’t How should this process work? What if the question is simply:
What do I need this thing to do?
And that sent me back to something I had read a few days earlier on Daring Fireball.
POSIWID - The Purpose Of a System Is What It Does.
The phrase comes from Stafford Beer, the British cybernetician and management thinker. His argument was deceptively simple: we tend to describe systems according to what their designers intended them to do.
Beer essentially said: forget the intention. Look at what the system actually does. That is its purpose. Which initially sounds almost tautological. “Well, obviously”. And then you think about it for another thirty seconds.
“Oh, fuck.”
POSIWID suddenly felt less like an observation about systems and more like permission: permission to stop treating the existing procedure as sacred, to stop assuming the workflow you are replacing is the workflow you should rebuild, and to stop confusing activity with purpose.
It also gave me a useful distinction. Every system has a declared purpose and an enacted purpose. The declared purpose is what the brief, the slide deck or the system prompt says the thing is supposed to do. The enacted purpose is what the thing repeatedly causes in the world. The gap between those two is where the system is failing.
Gruber’s piece also references a Steve Jobs story.
In 2008, Apple launched MobileMe, its attempt to synchronize email, contacts, calendars and other information across devices. The launch was a disaster. According to an account later published in Fortune, Steve asked the MobileMe team a remarkably simple question:
“Can anyone tell me what MobileMe is supposed to do?”
Someone answered. Steve followed with the only question that really mattered:
“So why the fuck doesn’t it do that?”
Steve wasn’t asking to see the architecture. He wasn’t asking how many teams had worked on it, how many features it contained or whether the roadmap was on schedule. He was comparing the thing’s declared purpose with its actual behavior.
Somewhere between a throwaway line in Sicario, a cybernetician from the 1970s, and Steve Jobs swearing at the MobileMe team, I began to wonder whether I had been designing AI systems the wrong way round.
Horseless Workflows
Over the past year or so, I’ve increasingly found myself designing systems with agents that call other agents, skills wrapped inside instruction sets, and tools threaded through chains of decisions.
And inevitably, when you design one, you start thinking about process.
What happens first? What happens next, and what does it need from the step before it, or hand off to the one after? Where does the human come in, where does approval sit, what gets stored, and what happens when something fails?
These are all perfectly reasonable questions.
But POSIWID has made me wonder whether they’re the first questions.
When designing an agent, I tend to begin by looking at how something is currently done. Then I make it better. Faster. Automated. AI-enabled.
Agentic.
At some point, I have built an extraordinarily sophisticated machine for doing something exactly the way humans have been doing it for the past twenty years.
Only faster.
The first automobiles looked suspiciously like carriages. There was a good reason for this. Carriage makers knew how to make carriages. Roads were designed for them. People understood how to use them. The entire mental model of personal transportation was built around the carriage.
So when the horse disappeared, much of the carriage remained. Hence the wonderfully transitional phrase: horseless carriage.
Eventually, of course, designers stopped asking: “How do we make a carriage without a horse” and started asking: “What should personal transportation actually be?”
I wonder if we’re currently building the organizational equivalent.
Take a fairly normal knowledge-work process. A brief comes in, someone researches it, someone turns the research into a strategy, someone writes it up, and then it gets reviewed, revised, approved, and sent out the door.
Then AI arrives, and we get terribly excited.
We create a Brief Agent, a Research Agent, a Strategy Agent, a Writing Agent, a Critic Agent, an Approval Agent, a Distribution Agent.
We connect them with arrows. We give the whole thing an impressive name. And then we proudly announce that we have built an agentic workflow.
Maybe. Or maybe we’ve simply reconstructed the company org chart in software.
Processes As Fossils
A process isn’t necessarily the best way of accomplishing something. Quite often, a process is simply the accumulated history of the constraints under which that thing had to be accomplished.
Research went to researchers because they knew how to research, copy went to writers because they knew how to write, design went to designers because they knew how to design, and approval went upward simply because authority lived higher in the hierarchy.
Information was placed into documents because documents were an efficient way of transporting knowledge between people; meetings existed because getting six brains into the same room was sometimes the only practical way to synchronize six different understandings of reality; departments existed because expertise had to live somewhere, and handoffs existed because no single person possessed all the capabilities required to complete the work.
Much of what we call workflow is therefore not some timeless expression of how work should happen.
That doesn’t mean every process is useless. Process also contains accumulated responses to risk, accountability, coordination, and failure. A procedure may be clumsy, but it may also be protecting a consequence that matters.
The point is not to delete process automatically. The point is to recover the problem the process was built to manage before deciding whether the process still needs to exist.
AI has relaxed some constraints and introduced others. It can make certain kinds of research, writing, analysis and coordination far cheaper and faster. But it also creates new problems around verification, provenance, permissions, privacy, liability and judgment.
And yet we often keep the old process while adding AI to it.
Automating the Past
This is where I think a lot of current thinking about AI transformation goes wrong.
Organizations look at what they currently do and ask, "Where can we put AI?" Which almost guarantees incrementalism.
The invoice process has twelve steps, so let’s automate steps four and seven. The research department produces a 60-page report every quarter, so let’s use AI to produce it faster. Our creative process has seven approval stages, so let’s insert AI between stages three and four. Our employees spend six hours a week creating PowerPoint decks, so let’s have AI create them.
But there are more interesting questions:
Why does the 60-page report exist? Why are there seven approval stages? Why is the output a PowerPoint deck? Why does this information move through four departments?
Those aren’t automation questions. They’re systems questions. And AI becomes considerably more interesting when you stop asking it to improve the existing process and start asking whether the existing process needs to exist.
Design the Agent Backward
POSIWID suggests a different starting point. Don’t begin with the workflow. Begin with the behavior. Ask:
What should be different because this system exists?
Suppose I want an agent that monitors emerging creative AI tools. The obvious place to begin is process. It should search product-launch sites, monitor GitHub, read newsletters, track industry publications, categorize new tools, maintain a database, generate a weekly report, and send it to Slack.
Perfectly sensible. Except none of those things are actually the purpose of the system. They are activities.
So let’s apply POSIWID. What do I actually want the system to do? Perhaps:
Once or twice a month, surfaces something I didn’t know about that materially changes how we could solve an active client problem.
Now things get interesting.
Because suddenly the weekly report isn’t sacred. The database isn’t sacred. The monitoring cadence isn’t sacred. Slack isn’t sacred. The number of agents isn’t sacred. Even the definition of “creative AI tool” isn’t sacred.
The desired consequence is what matters. Everything else is implementation. That means we can design backward.
Desired consequence → observable behavior → required capabilities → system architecture.
The observable behavior matters because a desired consequence is often too vague to build against. What would I actually see if the system were producing that consequence? What decision would change? What would I do differently? What evidence would convince me it was working?
That is a very different sequence from:
Existing process → automation → more efficient existing process.
This feels like a small change in sequence. I suspect it is actually a very large change in thinking.
I recently wrote about something Taylor Swift said about songwriting:
“Details should not be strictly decorative.”
I loved that phrase because it describes something much bigger than songwriting. A good detail earns its place. It changes something. It creates tension. It has consequence.
The same test applies to system design. Why is this instruction here, this step, this handoff? What behavior does it change? If nothing meaningful happens when it is removed, perhaps it was never part of the system’s purpose.
The Architecture Is Not the Achievement
There is something seductive about complicated agentic systems. I understand the attraction. I’ve built them. A collection of specialized agents connected by conditional logic looks impressive. Research passes to Strategy, Strategy passes to Creative, Creative passes to Critic, and Critic sends it back, until eventually something emerges.
There is something satisfyingly industrial about it. You can almost hear the machinery.
But complexity is not intelligence. And orchestration is not effectiveness. If a twelve-agent system produces mediocre work, it is a mediocre system with an excellent diagram.
This is where the MobileMe question becomes useful. Forget the diagram. Forget the prompts. Forget the model. Forget the orchestration layer. Forget how clever the architecture feels. Stand in front of the thing you built and ask:
What is this supposed to do?
Answer the question in one sentence. Then look at what it actually does. If those two things are different:
So why the fuck doesn’t it do that?
That may be the entire QA framework.
The Human in the Loop Might Be a Legacy Feature
Consider one of the most common phrases in AI system design:
Human in the loop.
It sounds reassuring. Responsible. Safe. And frequently it is all three. There are places where human judgment, accountability, taste, empathy or legal responsibility absolutely belong. A decision may carry material risk. The evidence may be ambiguous. The system may need to be challenged. Someone may need to authorize an action or bear responsibility for the consequences.
Excellent. But sometimes the answer is: Because a person used to do that part. That is not the same thing.
If a human is present only to rubber-stamp an output, then the checkpoint may be nothing more than organizational archaeology. But if the human exercises judgment, changes the outcome, authorizes risk or owns the consequence, the human is doing something important even if the final output looks similar.
The question is not whether there is a human in the loop. The question is what the human contributes to the system’s behavior. The human should not be there because a person used to occupy that box on the flowchart. The human should be there because they change something that matters.
The same applies in the opposite direction.
Right now, there is enormous enthusiasm for multi-agent systems. Give every cognitive function a title: Researcher, Planner, Strategist, Writer, Reviewer, Critic, Fact Checker, Coordinator, Supervisor.
Suddenly your laptop has middle management.
Specialization can genuinely improve performance in some situations. Different contexts, tools, permissions, and evaluation criteria can make separate agents useful. But there is also a danger that we anthropomorphize organizational design.
Humans needed separate jobs because no individual human could simultaneously possess every skill, know every piece of information, maintain every context, and work continuously.
Those constraints do not map perfectly onto AI.
Before creating another agent, perhaps the question isn’t: What role is missing? Perhaps it’s: What behavior is missing?
The Purpose of an Agent Is What It Does
Which brings me back to Stafford Beer.
His idea wasn’t really about AI, obviously. It predates ChatGPT by several decades. But POSIWID is almost perfectly suited to this moment.
Because we’re entering an era where systems don’t merely store information or execute predefined software functions. They increasingly observe, interpret, decide, create, communicate and act. That makes the distance between what we intended the system to do and what it actually does more consequential.
We can write a beautiful system prompt describing an agent as helpful, strategic, discerning and proactive. Ok.
What does it actually do?
We can build an elaborate research workflow designed to generate insight. Does it generate useful insights? The kind that ground an idea or change a decision?
We can create an AI transformation program designed to make an organization more innovative. Does the organization become more innovative or does everyone simply attend three more meetings about AI?
POSIWID is ruthless about this.
It doesn’t care what we called the system. It doesn’t care what the slide deck says. It doesn’t care what the transformation roadmap promised. It doesn’t care how sophisticated the architecture is. It looks at the result.
And then we have to work backward.
Perhaps that’s exactly how we should design the next generation of AI systems. Not by asking how work has traditionally been done. Not by recreating our departments as agents. Not by preserving processes whose origins we’ve forgotten. Not even by beginning with what the system should do internally.
Begin with the consequence.
What should be different because this system exists?
Then build the minimum system capable of reliably making that true.
And when it doesn’t? Well, we already have the question you should be asking. Steve Jobs gave it to us eighteen years ago.
So why the fuck doesn’t it do that?
