Most of what I’ve learned about building companies has come from making mistakes inside my own. Every now and then, though, I get the opportunity to watch someone else start from a completely blank sheet of paper, before assumptions have hardened into process and before software choices become organizational constraints.
Last week I was on vacation with family and friends, and for part of the trip with Nola Solomon, who is building Renoverse. There is a particular clarity that comes from watching someone build a company today with no legacy stack to defend and no inherited workflows to route around. Every founder claims they’re building AI-first. Watching someone actually do it is different. You start to notice that many of the assumptions the rest of us have carried for years simply never enter the conversation. The default answer isn’t “who should own this?” It’s “should a person own this at all?”
Watching her build sent me back to something I wrote in 2012.
At the time I had written a post arguing that founders should formalize every repeatable process in their business as early as possible. Every recurring task should become documentation. Every documented process should live in its own binder. As the company grew, those binders became the mechanism for delegation. Instead of hiring someone and hoping they figured things out, you built the process first and hired into it later.
I wasn’t inventing anything new. The idea came directly from Michael Gerber’s The E-Myth, a book that has probably influenced more founders than they realize. Gerber argued that companies should be systematized to the point where they become independent of the people who created them. Every role should have documented responsibilities. Every responsibility should have a repeatable process. Build the machine first, then add people to operate it.
Reading my old post again almost fifteen years later, I was surprised by how much I still agreed with it.
What surprised me more was realizing that I’d misunderstood one of the assumptions that sat underneath the entire argument.
The binder was never really about the employee.
For decades we treated documentation as a management exercise because there wasn’t another practical reason to write it. You documented a process so one person could teach another person how to perform the work. The documentation itself wasn’t valuable. It was simply the vehicle that transferred knowledge between humans.
That assumption no longer holds. The procedure has become the product.
The thing Gerber was asking founders to build wasn’t actually a training manual. It was a structured representation of work. In 1986, the only system capable of consuming that representation happened to be another employee, so naturally every discussion around documentation became a discussion about hiring, onboarding, and organizational design. Looking back, I think we accidentally confused the consumer of the procedure with the procedure itself.
Today the exact same artifact serves an entirely different purpose.
A documented operating procedure is no longer waiting for someone to join the company. It’s software that hasn’t been deployed yet.
That’s why so much of the current conversation around AI feels strangely incomplete to me. People talk about prompts as though they’re some entirely new form of computing. In practice, most of the prompts that matter inside businesses look remarkably familiar. They describe objectives, constraints, escalation paths, edge cases, approval criteria, definitions of success, and all of the other things that have always lived inside good operating procedures. The difference isn’t that companies suddenly need documentation. The difference is that documentation has become executable.
Once the idea clicked, I started hearing it everywhere. Different founders, different companies, different industries, but they were all converging on the same conclusion from different directions.
Joe Luchs, who founded Datalinx AI, described his philosophy as creating structure amidst ambiguity. If the work can be defined precisely enough, he told me, it often doesn’t need to be staffed. That struck me because it isn’t really a new management philosophy. It’s almost a direct continuation of Gerber’s. The discipline is still the same. The work still has to be decomposed into repeatable steps. The criteria for success still need to be explicit. The only thing that changed is who executes the procedure after you’ve finished writing it.
Decagon is probably the clearest public example of this idea finding product-market fit. Their core abstraction isn’t really an AI model. It’s what they call an Agent Operating Procedure, a structured description of how work gets done that becomes directly executable by software. Investors understandably focus on the valuation, but I think that’s the least interesting part of the story. The real innovation is recognizing that the operating manual itself had quietly become software.
What I found more interesting, though, wasn’t the public examples. It was watching founders who had already internalized this shift.
Nola doesn’t describe individual automations. She talks about suites of agents interacting with one another to complete entire business functions, with humans stepping in where judgment or approval actually matters. She walked me through a fully autonomous go-to-market engine that, in her words, removes the need for an entire marketing organization, then showed me the operating layer she built over the top of it that lets her initiate work, review outputs, and approve decisions from her phone while sitting on the beach with the rest of us.
What struck me wasn’t the sophistication of the technology. It was that she never framed it as automation. She talked about it the same way founders have always talked about building teams.
That same pattern showed up again in a conversation with William Cichowski, who is building PubRunner in a part of the market I know well.
As AI Overviews and chat interfaces reshape how people discover content, every visitor that reaches a publisher has become more valuable. PubRunner automatically optimizes how each of those visits is monetized and nurtured over time.
What interested me more than the product itself, though, was how Will thinks about creating the procedures behind it.
Back in 2012 I wrote that once a founder solidifies the best way to perform a task, they should document that method so someone else can repeat it. Reading that sentence today, I realized the most important word wasn’t document. It was solidifies. Implicit in that advice was the assumption that expertise had to exist before documentation. You became good at something, refined your approach through experience, and only then wrote the binder.
That assumption has quietly disappeared as well.
Today the founder’s job isn’t necessarily to possess the expertise before writing the procedure. Increasingly it’s to assemble the best available knowledge, work collaboratively with models until a process emerges, test that process against reality, refine it through iteration, and then formalize the version that consistently produces the best outcome. The procedure still matters every bit as much as it did fifteen years ago. The path to creating it has changed dramatically.
Will described spending the last month doing exactly that across disciplines ranging from legal drafting and sales enablement to infrastructure management and interface design. He wouldn’t claim to be the world’s leading expert in any of those domains, nor does he need to be. The leverage comes from being able to synthesize expertise, pressure test it, improve it, and ultimately convert it into something repeatable.
That’s a fundamentally different model of company building than the one most of us grew up with.
It’s also where I think a lot of commentary around agents becomes far too optimistic.
There’s an assumption floating around that AI somehow lowers the importance of process because the model is “smart enough” to fill in the gaps. If anything, I’ve found the opposite to be true. The more capable the system becomes, the more expensive ambiguity becomes.
A mediocre employee operating from an imperfect procedure produces inconsistent results. Sometimes they make the right judgment call, sometimes they don’t, and over time you coach them, improve the process, and move on. The mistakes are usually contained to that individual.
An agent doesn’t improvise around ambiguity. It operationalizes whatever you gave it. If the procedure is thoughtful, the system scales thoughtful execution. If the procedure is sloppy, it scales sloppy execution with extraordinary consistency. The mistakes don’t stay at one desk. They propagate everywhere the procedure runs.
That’s why every founder I spoke with spent more time talking about governance than autonomy.
Joe builds Datalinx around deterministic workflows with clearly defined authority, escalation paths, and auditability because enterprise software has always required explainability. Nola approaches the same challenge from the opposite direction, validating outputs against external systems, testing workflows continuously, and assigning different permission levels based on the consequences of each decision. Neither of them talks about replacing judgment. They spend their time deciding exactly where judgment belongs.
That distinction feels increasingly important.
The narrative around AI often assumes the technology changes the need for discipline. In practice, it rewards disciplined organizations and exposes weak ones. Businesses with poorly defined processes don’t become AI-first. They simply automate confusion. The companies starting today have the advantage of designing around agents from day one. Everyone else has to untangle years of undocumented institutional knowledge before they can do the same.
That’s a much bigger shift than replacing individual jobs.
For decades companies scaled by hiring people faster than complexity accumulated. Every new function eventually meant another team, another manager, another layer of coordination, until eventually the organizational chart became the operating system. That’s the world Gerber was writing for, and frankly it’s the world most of us have spent our careers operating inside.
I’m increasingly seeing something different. The repeatable work gravitates toward software while people move toward the parts of the business that still resist formalization. Engineers become architects. Managers spend less time assigning work and more time defining what good looks like. Founders spend less time reviewing output and more time deciding which problems deserve to exist in the first place. The organization doesn’t disappear, but it becomes flatter because much of what used to occupy the bottom of the org chart no longer requires a person.
I also think this is why watching founders like Nola build from scratch feels so different. They’re not taking a traditional company and replacing pieces of it with agents. They’re designing the company around the assumption that documented work is executable from day one. They don’t have years of institutional knowledge to unwind before they can automate it because they’re creating the institutional knowledge and the automation at the same time.
Looking back at what I wrote in 2012, I don’t think I’d change the advice at all. I’d still tell every founder to write the binder before they think they need it. I’d still encourage them to document every repeatable process they can find because the act of writing forces a level of clarity that every business eventually needs.
What I misunderstood wasn’t the value of the binder. It was what the binder actually was.
For decades we treated documentation as overhead because we assumed its purpose was transferring knowledge between employees. In hindsight, that was only one implementation of a much broader idea. The real asset was never the training manual. It was the encoded understanding of how work gets done.
Gerber understood that businesses should be built as collections of systems rather than collections of people. What neither he nor I appreciated was that those systems were always moving toward becoming executable. We simply didn’t have anything capable of reading them.
Today we do.
Looking back, the binders we’ve been writing for the last forty years weren’t training manuals waiting for employees.
They were undeployed agents.