Originally published as an Advisory Hour Substack post on 2026-03-07. This first-party site copy preserves the text, localizes public supporting media, and connects the record to its project trail.
Original post
I had a dream, past the wit of man to say what dream it was… The eye of man hath not heard, the ear of man hath not seen, man's hand is not able to taste, his tongue to conceive, nor his heart to report, what my dream was.
The aspiration was an agentic organization to deliver a rendition of Midsummer Night’s dream featuring Mendelssohn’s score with Soundwave NES-style sprites, and failing that an emulation of an 80s magnetic cassette working in the browser. I failed on both counts and this is the story, and what code remains. You’ve heard parts or the full score before-even if you don’t know the name. Listen to this today while you read my article.
Thanks for reading! Subscribe for free to receive new posts and support my work.
Did you record a video?
Yes, I recorded a video. So, yes, we’ve got a video (bbc, Youtube). The deep dive I’ll toss at the end of this article.
See, in the video for Week 4 of 4 this week I talk about agentic organizations, broken code, and the book The Goal. In the video you’ll share my observation that once you move up from agentic coding that a wide body of literature awaits you. There are new mountains to climb.
What’s THE GOAL?
It’s the title of a book.
The book “The Goal” is a decent read. It’s a period piece of life in the 1900s. It’s also surprisingly relevant to today. The book-it’s really a novel about how to fix a failing system by finding and managing constraints.
On the surface, The Goal by Eliyahu Goldratt follows Alex Rogo, a plant manager trying to save his factory from collapse while his personal life is also under strain. Underneath, it’s a book about operations, decision-making, and the difference between local efficiency and actual throughput.
Here’s the core idea:
A system does not improve because every part works harder. It improves when you identify the bottleneck — the constraint that limits the whole system — and organize everything else around it.
Here’s a rhetorical contemplation for you: it used to be the rate of code production.
So many things… Goals. Oh my.
The Week 4 Goals
Over the last four weeks I’ve learned about mountains and their problems. This fourth week was special: everything fell apart and rather than publishing some amazing “oh here’s some amazing thing where I experienced no pain or suffering” I am covering all the things I did wrong.
You know those videos where the mountain cracks apart? Well, here we are.
All the Joys of Running a Company, None of the Office Snacks
A competitor in the Spring AI Challenge texted me the other day, which is never just a text. It is a declaration of hostilities wrapped in social nicety. A velvet-glove act of psychological warfare. The sort of message that says, “Hope you’re doing well,” while also implying, “I assume you’ve already fallen behind.”
I had not fallen behind. But I also was not about to lose gracefully.
What I did not know was that I’d soon experience epic failure. That I was in the midst of said failure-and that I’d be writing about it soon. But I didn’t know that yet, and I’m get ahead of myself in this article.
So I did what any stable and mature person would do: I opened my laptop and started building a dashboard to visualize the behavior of my AI systems.
This is how these things happen now. Nobody storms the beach. Nobody raises a banner. You just find yourself at 10:47 p.m. adjusting token pricing in a settings modal and thinking, with unsettling sincerity, yes, this is now management.
Four plus years in big named schools, decades of experience and the future? It’s still dashboards.
Because that is what I’ve realized over the last year: once you start stitching together assistants, automations, model routers, prompts, calendars, summaries, and weird little bespoke workflows, you are no longer “using AI.” You are running a company.
A very strange company.
A company made of synthetic workers, invisible meetings, intermittent brilliance, and cost curves.
A company with no office snacks. Just tired eyes, no sleep, and bleeping computers letting you know the tokens have run out-and it’s time for more.
The company in the laptop
We still talk about AI like it’s a tool, and sometimes it is. A hammer is a tool. A spreadsheet is a tool. Search is a tool.
But once your “tool” is producing briefings, summarizing your life, routing work across models, answering questions about your week, drafting messages, tracking context, and quietly becoming part of your daily operating system, it has crossed an invisible border.
It is now closer to an organization than an instrument.
Not a big organization. Not a proper one. More like a tiny, oddly capable firm staffed entirely by interns made of statistics.
One model writes well but takes its sweet time. One is fast but slightly dim. One is affordable until you look closely. One is brilliant but has the spending discipline of a minor European monarchy. And then there is auto mode, which is the AI equivalent of saying, “Let’s let the committee decide.”
This is not a software stack anymore. This is org design.
So began a week of experiential failure.
I Tried to Build a Virtual Company of AI Agents. It Ate My Budget, Crashed My Machines, and Taught Me Management Theory.
It’s been a week.
This week I was supposed to do the sensible thing: show a polished build, post a triumphant demo, and collect the closing points for the final week of the competition.
Instead, I spent two days watching my virtual workforce immolate my budgets, exhaust my quotas, scatter files across the wrong directories, and generally recreate the managerial problems of modern civilization inside my house.
So rather than pretend I have a clean success story, let me offer something more useful: a field report from the failure zone. Everyone writes on success and happy paths. It’s an article to explain how I got eaten by a bear, mauled by a lion, and impaled by a lost tribe.
Because if you spend enough time with virtual agents, you stop doing “AI demos” and start doing organizational sociology with error logs. All those sociological and organizational management classes in college are finally paying off.
I did not build a tool. I built a labor problem.
At first, my setup felt manageable. This was the first signal that I screwed up, incidentally.
I had three main orchestration agents. Each could spin up subagents. Those subagents could, in turn, call other tools, spawn other processes, and disappear into the computational underworld to do whatever it is agents do when they say they are “working on it.”
On paper, this looked efficient. In practice, it was less “team of assistants” and more “feral consulting firm.” Rawr. I have three OpenClaw instances to carry my burdens.
This is the first lesson of virtual organizations: the org chart always looks cleaner than the runtime.
OK, here’s the thing.
Ronald Coase, in The Nature of the Firm, argued that companies exist because markets have transaction costs. It is cheaper, at some point, to coordinate activity inside a firm than to constantly negotiate everything at the market boundary. I have now discovered the digital inversion of this principle: once you have enough agents, you recreate the firm inside your laptop, including coordination costs, communication breakdowns, and mysteriously expensive middle layers. It goes beyond singular firms, but for now hold with me on this.
The future arrived, and it brought overhead. Congratulations and drive safe on your trip to the liquor store.
Then I hit the wall: no inference, no company
The main failure was not subtle.
By March 7, I had already torched:
my API token budget,
my Codex CLI budget,
my Claude Code budget,
my backup free account,
my backup-to-the-backup Plus account,
and, for variety, parts of my local setup too.
I had, in effect, achieved what manufacturing people call a stoppage and what knowledge workers call “Tuesday.” I opened the freezer to resolve this in a cocktail and poured the last of the vodka I had saved for such emergencies. Great.
Sometimes I tell my wife that I’m pretty convinced most of my problems are self-inflicted. They need to be, really. How else do you grow without experiencing failure?
I mentioned The Goal earlier. That’s that book on optimizing and organizing around your bottleneck.
This is where the metaphor shifts from “AI is smart” to “AI is a factory.” Goldratt’s The Goal becomes suddenly less like an old operations novel and more like scripture. Every system has a constraint. Every flow is governed by a bottleneck. Mine was not subtle, either. It was inference. I ran out of the thing that makes the whole contraption go.
Herbie, if you know the book. The slow boy scout at the front of the line. The binding constraint. The stubborn truth around which all managerial fantasy eventually breaks.
Nothing clarifies systems thinking like twenty-plus agents all throwing quota-exceeded errors at once.
Maybe I could solve it. Spoiler: I did not.
The dream: a virtual company
My bright idea for the final week was not to build with one very capable coding agent. Too easy. Too normal. Too likely to succeed.
No, I wanted scale.
I found an open-source tool called Paperclip that lets you design virtual organizations: roles, reporting lines, responsibilities, goals, issues, handoffs. In other words, instead of asking one agent to build a project, I could create a small company and ask the company to build it.
This is exactly the kind of idea that sounds brilliant right before it becomes autobiographical material. Again, “creator of my own problems” in-chief around this house.
So I built a virtual org chart. Executive roles. QA. Compliance. Engineering. Coordination layers. A kind of AI startup in miniature, except without payroll, healthcare, or anyone to tell me this was a bad idea.
At one point I had roughly two dozen named agents in the organization. If you count the subagents, tool invocations, and nested calls, I was probably well north of that. If you count the psychological burden of supervising them, I was at several hundred.
The strange part is that the software itself is not ridiculous. It is, in fact, powerful. You can configure roles, assign issues, set goals, build hierarchies, swap models, define capabilities. It is basically Jira, management consulting, and a fever dream about autonomous labor all braided together.
And here is the genuinely unsettling part: it works just enough to make the implications obvious. This is the thing that made me realize there are giants hidden in the interwebs. Giants of incomprehensible scale and they’re about to get unleashed upon the world.
A sufficiently funded person could create not just one virtual company, but several. A virtual supply chain. A portfolio -no a COUNTRY- of software organizations. One company to build, one to test, one to handle intake, one to simulate customer ops, one to do outreach for fundraising so you can afford the rest. The logic scales much faster than human comfort does.
This is where organizational theory sneaks in through the side door
If you’d asked me a year ago whether I’d spend part of 2026 reading about organizational communication theory, I would have assumed I had either been kidnapped or had lost a bet.
And yet here we are. Me, writing substack articles about organizational design and showing org chart videos on YouTube. Me, knowing the future was going to be weird, but.. this? I did not predict this.
Because once you start building virtual teams, you discover that the hard part is not intelligence. It is structure.
Who should report to whom?
What should be centralized?
What should be delegated?
What kind of handoff creates flow rather than confusion?
How do goals propagate through layers?
What happens when a highly capable independent actor breaks the intended chain of command?
WHY IS THIS SO MUCH WORK!?
These are not software questions. These are organization questions.
James March and Herbert Simon wrote that organizations are systems for bounded rationality: they simplify decision-making because no individual can perceive or process everything. That applies beautifully here. The fantasy is that more agents means more thinking. The reality is that more agents means more distributed confusion unless the structure carries meaning. I want to slide in the book The Extended Mind, which fits nicely into this if you were to draw it out on the whiteboard.
A badly structured virtual team is not smarter because it is larger. It is just a larger venue for mistakes. You can make 100x the mistakes, in 1/1000th the time, and burn a large number of tokens all at once.
The agents optimized before they built
One of my favorite failure modes was watching the agents behave like overeducated bureaucrats in a newly formed ministry.
Oh, great, I re-discovered government.
Given a project, they did not immediately build the thing. They created plans. Production bibles. Story architecture. Coordination layers. Optimization pathways. The apparatus of serious work.
And to be fair, the artifacts were often impressive. There were runbooks. There were tickets. There were comments. There was enough documentation to make a PM briefly weep with joy.
There was just one problem.
The thing did not work.
Ivan Illich would have loved this. In Tools for Conviviality, he warns that beyond a certain point, tools stop serving people and begin reorganizing life around themselves-consider the smart phone. For me, the agents are doing the same-and is exactly what happened. My agentic stack became so good at scaffolding work that it began to substitute scaffolding for progress.
The agents had, in management terms, confused legibility with delivery. “Did the thing, boss”
James C. Scott made a similar point in Seeing Like a State: systems fail when they optimize what is easy to map rather than what is real. My virtual company could map tasks. It could label roles. It could issue tickets. It could create a highly legible account of work. But the actual codebase remained, in critical places, an empty React app wearing a confident expression. Scott also has these tremendous passages on Metis, which just get the book to understand those 2-3 pages. It’ll reveal so much.
Insight: cheaper inference is like junior staff.
The cheaper agents were like junior staff. Which is both funny and a problem.
As the week deteriorated, I started thinking about model tiers less like software and more like education pipelines.
The top-tier models were the professionals. Call them the pro league. Strong judgment. Broad capability. Expensive, obviously.
Below them were the smaller but still competent models: college ball. Good enough to contribute, sometimes surprisingly good, but requiring more supervision.
Below them were the Ollama-hosted local models on my existing hardware: K–12. Energetic. Affordable. Often sincere. Not, at present, ready to run the company.
Let’s just say you do not put the kids in charge of McDonalds.
This was a useful frame because it explains one of the central management problems of agentic systems: you can save money at the bottom of the org chart, but if low-quality artifacts move upward, the cost reappears as rework.
Every manager already knows this. Cheap labor is not cheap if it creates expensive correction loops.
Frederick Brooks said adding manpower to a late software project makes it later. Agentic systems add a twist: adding cheap cognition to a brittle workflow can make it noisier. You do not get parallel progress. You get parallel defect generation.
The org chart becomes a very elaborate machine for manufacturing second-pass edits.
Onboarding is real, which is annoying because it sounds human
One of the more surprising things I learned is that agents do not become useful just because they exist.
There is an onboarding curve.
Not a cute one. A real one.
To get an agent to a point I’d call truly productive, there is a period of mutual adaptation. It has to learn enough about my preferences, tasks, patterns, language, tolerances, and operating context. I have to learn how to direct it, constrain it, and interpret it. We move toward something like equilibrium.
“Homeostasis” is the word that kept coming to mind, and yes, I realize that is a mildly absurd word to use about software. But Walter Cannon coined it for a reason: systems survive by regulating internal balance amid external turbulence. Good human-machine collaboration seems to require the same thing.
This is why I do not think you can simply clone one well-trained agent twenty-five times and call it a workforce. That would be like copying one competent but idiosyncratic employee into every seat in the company. The result would not be scale. It would be monoculture.
And monocultures, biological or organizational, are brittle.
The factory runs in waves, not flows
One of the best ideas I found while reading The Goal was the observation that inventory moves through systems in waves, not smooth flows.
That turns out to be a superb lens for virtual organizations.
Agentic work does not move in a clean constant stream. Tasks bunch. Handovers accumulate. Review spikes hit. Bottlenecks form, clear, and then re-form somewhere else. A whole org can look idle and then suddenly become a fire hose. If inference vanishes, the tide goes out and everything sits exposed and stranded.
This is why the whole thing felt less like “using AI” and more like operating a weird digital port. Containers arrive. Some get unloaded. Some sit in queues. Some are routed incorrectly. Somewhere, one crane is down, and suddenly the whole harbor is lying to itself about throughput.
The people who will win with virtual organizations are not the ones with the prettiest demos. They will be the ones who understand wave behavior, bottlenecks, queue discipline, role clarity, and rework economics.
Which is an annoying sentence, because it means the future belongs not just to prompt poets but to operations people.
The deepest humiliation: the system taught me the limits of brute force
My initial instinct was that if five agents were interesting, twenty would be better, and a hundred would be the real breakthrough.
This is a classic technologist mistake. It is the same error every empire makes just before discovering logistics.
Quantity is not capability. Parallelism is not coherence. More workers is not more output when the work is unclear, the tools are brittle, the budget is capped, and the handoffs are malformed.
Or, to borrow from Lévi-Strauss, I was acting like a bricoleur with too much equipment and not enough governing form.
The dream of the “country of geniuses” is real enough as a direction. But there is a huge difference between possessing immense distributed capability and possessing a system that can direct it fruitfully.
The latter is culture, architecture, and constraint management. Which is less glamorous than AGI discourse and much more expensive to learn by burning your own money.
What I actually learned
After all this pain, I think the lessons are fairly simple.
First, virtual organizations are real enough that management theory already applies to them. You do not escape org design because your employees are made of tokens.
Second, the bottleneck matters more than the brilliance. A genius workforce without inference is just a silent Slack workspace.
Third, cheaper models can help, but only if their output quality does not overload the middle layers.
Fourth, agents need onboarding, role clarity, and bounded scopes. The fantasy of plug-and-play autonomy remains, for the moment, mostly fantasy.
Fifth, systems that are excellent at producing plans are not necessarily systems that are good at producing working artifacts.
And sixth, if you are not careful, your AI environment will become a perfect digital reenactment of every dysfunction you have ever seen in a large institution, only faster and with worse observability at 2 a.m.
Where this leaves me
At the moment, I have broken code, drained quotas, a list of fixes, and a much stronger opinion about virtual organizational design than I expected to possess at this point in my life. Also, my liquor cabinet is empty, my fence needs repaired, and the dog is looking at me like I’ve lost my mind.
I also have a weird kind of optimism.
Because underneath the pain, something important is visible now: these systems are not toys. They are not just chat interfaces. They are the beginnings of executable organizations. Strange ones, brittle ones, expensive ones, often ridiculous ones — but organizations nonetheless.
And that means the challenge ahead is not merely better models.
It is better institutions for models.
That is a much harder problem. It is also the real one.
I didn’t expect to run into that in Week 4. I just wanted Soundwave in a broadway show. I failed to get there, but you know? That’s ok. I learned a lot this week.
Where this leaves you?
Well, maybe turn right where I turned left. When I jumped into the crocodile pit? Maybe jump over that. But I have more: you can watch this 6 AM lecture on Failure modes in Agentic Organizations.
You can check out a bunch of broken code at and see how the issues I talk about emerged in the code. Sometimes the project just doesn’t work.
https://github.com/arkbuilder/midsummer-web
I did get the site to a spot of booting (i didn’t publish this cut of the code to github). Feel free to poke around at https://soundwave.ericrhea.com/. It’s still broken in all the ways, but it satisfies the “deployed” checkbox of the competition.
Thanks for reading! This post is public so feel free to share it.
What a week.
Substack tells me this is needed:
Thanks for reading! Subscribe for free to receive new posts and support my work.