In 1956, a programmer at General Motors sat down with a stack of punch cards (each one a single line of code) and walked them to a window where a white-coated operator took the deck. The cards sat on a rack until the reader was free, got scanned to a job queue tape, and a couple of hours later a stack of fanfold paper appeared in a bin outside the operations room with the deck sitting on top. If the output was wrong, the programmer pulled the deck, found the bad card, punched a replacement, and resubmitted. God help you if you dropped the stack — most keypunch machines didn’t number the cards, so a dropped deck meant reconstructing the entire program by hand.
I grab my coffee, knowing what awaits. I open a fresh chat window, paste in four documents (a spec, a skill file, two database schemas) and wait while my AI loads forty pages of instructions it won’t remember tomorrow. Then it’s working.
The AI is supposed to draft an essay. The agent runs the brief against forty-plus stored drafts, finds the topic, and produces a rough cut that serves as a reasonable starting point. But the agent runs a second editorial pass that makes the piece worse, smoothing out the edges I wanted to keep. Sigh. Instructions need updating.
I load files for another agent, this one charged with managing updates. It rewrites the schema, adjusts one skill, and hands it to me to reload the entire stack in a fresh thread to see if the fix holds.
Why, you ask, haven’t I automated the process? Because I'm not optimizing for the orchestration. I'm optimizing for the judgment, and being in the loop is how I see the fix that's needed. Automating means I can no longer easily validate why my writing agent recommended stopping a third editorial pass.
We’re at the same stage as computers were nearly 80 years ago. The AI model does the reasoning. I manage the design of the memory, the scheduling, the quality control, and the judgment about whether the system is good enough.
The media is frothing about autonomy; agents that browse, code, run multi-step workflows unsupervised and are packaged into shiny demos. The unfortunate reality for anyone doing judgment-heavy work with agents is that the quality of the system depends heavily on the judgment, memory, and structure its operator built into it.
The research backs this up. Harvard Business Review published a study this month based on field research at Walmart, Amazon, and Medtronic. Their finding was that AI improves enterprise decisions only when the underlying work is already clear. If the processes are opaque or dependent on informal knowledge, the technology reinforces existing coordination problems. It doesn't fix the mess, it scales it.
If computing history is any guide, this stage is temporary. The batch model gave way to real operating systems and eventually to networks. That took twenty-five years. It’ll move faster, but the transition won’t happen overnight. Memory systems, agent-to-agent protocols, and persistent state already exist in early forms, yet they’re not reliable yet for work where a wrong call has real consequences.
But when the orchestration layer does get automated, the question for companies won’t be whether to adopt it. It’ll be whether the team understands the judgment the automation is now hiding.
Right now, most companies are letting individual employees figure out their own agent workflows. That’s fine as a starting point; after all, it’s how judgment gets built. The problem is that most of that judgment stays locked inside one person’s private setup, invisible to the rest of the team. Nobody else can see why the agent makes the calls it does, what was tried and abandoned, what breaks when the context changes.
Deloitte's 2026 State of AI survey of 3,200 executives found that only one in five enterprises has a mature governance model for their agents. Adoption is outrunning integration, which means companies have the tools and the use cases, but not the organizational changes to make them stick. It’s the equivalent of letting every department write its own punch card deck and never sharing the documentation. It works until you need two systems to talk to each other, or until the person who built it leaves and no one can explain why the agent recommended what it did.
The companies that move fastest from here won’t be the ones that automate first. They’ll be the ones that took the judgment their best operators built in the loop and made it legible — baked into specs, schemas, and decision logs that a team can read, challenge, and build on. The OS stops being one person’s private deck and becomes the one the whole team can read.