Let's start by establishing the core goal of a company. Companies solve problems for people. Successful companies solve those problems efficiently. Very successful companies solve problems efficiently and show a true ROI to the people who have the problem. So if we're leveraging an AI system, the foundational prompt should define the problem the company solves, and any knowledge the company has should be viewed through the lens of how it relates to solving that problem.

We know that the merging of the Venn diagram of roles and responsibilities for developers will also happen on the business/operations side. So we should drill down into the existing roles to identify which tasks each role is responsible for. From there, we can start targeting tasks for removal and then consolidation.

The roles and responsibilities that come to mind are:

A key component of incorporating AI into your business is removing "knowledge sync" type activities. You probably shouldn't plop an AI into replace a role in your company without that AI being transparent about what it is doing, why it is doing it, and how it aligns with the problem the company is solving. That information should be stored in a company knowledge layer that other agents/humans interact with to stay aligned on core objectives. A shared knowledge store means that agents/humans can both extract the hyper-task-tuned context they need to complete their next task.

As mentioned in another post, every company will have some sort of Software Factory internally. It'll either be something they build themselves or buy. We can anticipate that as the cost of building software goes down, the willingness to "start over" on software will increase. For example, if I use my internal software factory to build a CRM tool and then realize that the CRM isn't solving the problem it was intended to solve, I can likely rebuild it from the ground up using lessons learned from the initial tool's failure. This would be unheard of today, but in the near future, I think it's the more likely way things will happen.

I'll start exploring the next steps in another post, but I think we've made good progress on laying the foundation with this initial post.

One note: the "one-person" company is slightly exaggerated. While it will certainly be possible to have a one-person company, at some point scaling to solve bigger problems will be necessary, and in those cases it will be good to have like-minded humans working at that scale to ensure things are moving the way they are supposed to. You'll want your company to have diversity of thought, and you'll want your ideas to be steel-manned to improve the chances of success. I don't think a growing headcount will be something people boast about in the future (in fact, I think, in the short-term hype cycle we're in, growing headcount will be seen as a negative), but I do think the number of small companies is going to explode. The more companies working on solving problems, the better chance they have of actually getting solved.

Let's first analyze how we got to where we are. When you're in a two-person company, direct communication is how communication happens. You don't need Slack or invites for internal meetings; you pick up the phone and talk. Direct communication is the most effective way to build and stay true to the vision set by the company's founders. You are, or are supposed to be, hyper-efficient. This amazing efficiency continues throughout the early growth, largely due to direct communication and the initial need to hire "ticket-makers" (your thought workers) rather than "ticket-takers" (your execution workers). You grow stably, and as you grow, direct communication gets offloaded to tools like Slack and email, and further gets offloaded through other employees who leverage the tools to communicate. Eventually, communication and decision-making that was once founder-only is distributed from the founders through layers of the organization to carry it out. Currently, the growth pattern/org-chart relationship is something like:

Many of these positions are required to enable the company's progress. There is only so much data you can consume, and there are only so many actions you can take in 24 hours. Delegating work across these layers becomes necessary to sustain growth. But, what if a founder did NOT have a limit to data consumed and did NOT have a limit on actions they could take in 24 hours?

This is what AI gives us the opportunity to change. We can build companies where some of the founders' decision-making processes are hardcoded into an agent, and that agent can be integrated into processes to reduce the need for multiple layers. We can build company knowledge stores that are accessed via natural language and provide an up-to-date view of the company's capabilities. Combining those two things with internal processes and tools would allow us to shrink the organization and begin to maximize efficiency (not to mention marketing improvements, like building a Capabilities MCP server on top of your knowledge store that broadcasts what your company is capable of and what work it has already done).

I think we should next look to group the responsibilities in our organization and see what information is needed to execute those responsibilities effectively. That can help tell us which agents to build and what data to collect.

For this post, I’ll start by focusing on what AI is good at, so we can understand what agents we need to build and how a company with these agents will be structured. Can we compress headcount so that the work of a traditional 1000-person company can be done by fewer than 100 people?

I’ve been building my own software factory to investigate the limits of AI agents today. I have deferred all coding to AI so I can better understand its strengths and weaknesses and how to bridge the gap to make it more reliable. To apply this to rethinking a company, we need to stop thinking of AI as simply executing tasks and instead consider how task execution can be strategically aligned with the company’s goals. Once we do that, we can identify the failure modes and specific capabilities that shape the company, which is very different from how today’s companies operate.

In building the software factory, I’ve started to build around the idea that AI is really good at 4 critical things:

1. Information Routing. AI can be really good at taking some information and assigning it to an individual bucket from a set of buckets. So, passing the information and having it accurately determine where to put it is good.
2. Information Summarization. This is pretty much out-of-the-box, good at summarizing. With a little structured prompting, it can be great at summarizing for an intended audience (i.e., a medical summary for a neurosurgeon).
3. Pushing data into a specification. I’ve proposed the CAIL process as a replacement for AGILE. CAIL focuses on creating contracts that steer the AI toward an expected output and structure. AI is really good at taking unstructured or structured information and converting it into a specification.
4. Following instructions when given a good context. The frontier models are fantastic at this. If you give an AI a clear set of steps to follow or a decision tree to think through, then it can do a great job of following that.

If these are what AI is good at, then we can map existing responsibilities to one of these categories where possible. This would guide us on which agents we need to build, the context each needs, and the responsibilities we need to offload to humans to carry out.

Category 1: Information Routing

Category 2: Information Summarization

Category 3: Pushing Data Into a Specification

Category 4: Following Instructions With Good Context

After you sort work into those categories, what’s left is the work that needs human thinking and execution. We can group similar responsibilities and then assign them to new roles:

This becomes really intriguing because it removes the communication layer we needed the middle to provide and restructures the company to move at the speed of the knowledge layer, with people who have more agency. This means we can rethink our scaling table to be less dependent on the communication/oversight boundaries and instead be based on problem complexity. This unlinks headcount from growth. Headcount grows much more slowly, with principals growing in proportion to the problems the company solves, while crafters/counterparts can be distributed across multiple problems. The company degrades differently because failure modes shift from communication breakdowns to judgment failures. The tradeoff is with accountability. A company’s success or failure depends on the judgment and execution of its principal.

If we apply this new thinking to our previous table on company scaling, I can see massive productivity gains with far fewer people. There are still failure points, but they seem to be much narrower than in a traditional company:

The bet underneath all of this is that companies are slow because information moves inefficiently through layers of humans, and that if you replace the routing layer with software, the company starts moving at the speed of its knowledge layer instead. That's how 60 to 150 humans end up doing the work of a thousand; not because the humans are working harder, but because the distance between a decision and its execution collapses to nearly zero.

This isn’t a magic wand, though. The new structure has new problems, albeit different ones. When Principals are the only judgment layer in the company, there’s nothing above them to catch a bad judgment before it propagates. The current org charts include built-in human structures to mitigate that risk, which are missing from this new version. There’s still a significant gap that needs to be addressed. We need a different mechanism for catching judgment errors, and it needs that mechanism to work in something close to real time.

I started this series thinking every company would need a software factory. I'm now convinced it also needs a tiered knowledge dashboard. Traditional org charts catch bad judgment through layers: your manager sees your emails, their boss identifies patterns, and so on, until somewhere up the chain, a wrong decision gets caught or softened. An AI-native company doesn't have those layers, so it needs a mechanism to live elsewhere. The dashboard is where it lives: a real-time view of what Principals are deciding, their reasoning, and the outcome. It's a status report and an escalation path, and it has to be both because the layers that used to provide each separately are gone. We can dig into that in a future post.