Build your company as an intelligence layer, not an org chart

Productivity is the wrong frame

Most conversations about AI at a company are conversations about productivity — engineers ship faster, you bolt a copilot onto an existing workflow, everyone closes a few more tickets a week. That framing is comfortable because it assumes the company keeps its current shape and simply moves quicker. The problem is that it misses the actual shift, which is not about speed at all. It is about capability: the right person with the right tools now builds what used to take a whole team, or what was flatly impossible a year ago.

Once you take that seriously, the interesting question changes. It stops being “how do we go faster” and becomes “what should this company look like if AI is the ground it stands on, not a tool bolted to the side.” The one-line version I keep coming back to is this: AI should not be a tool your company uses, it should be the operating system your company runs on. Every workflow, every decision, every process flows through a layer of intelligence that is constantly learning and improving. It sounds like a slogan until you take it literally — and taking it literally is the whole point.

Every important process should be a closed loop

If you have ever touched control systems, you know the difference between an open loop and a closed loop. An open loop acts and never checks the result. A closed loop keeps measuring its own output and adjusts to stay on target. Most companies, in the old world, ran as open loops: someone made a decision, executed it, and never systematically fed the outcome back in. Open loops leak — information is lost at every hand-off, and nobody notices until it is expensive.

With agents that improve as they run, a company can work as a closed loop instead. In practice that means every important process should be wrapped in a loop that records what happened, feeds it back into a system, and improves the process over time. Status, decisions, and outcomes get captured continuously and returned to the intelligence at the center, so the system always holds a current picture of what is actually going on — not a picture that someone assembled by hand and that went stale two weeks ago.

Make the whole company queryable

A closed loop only works if the intelligence at the center can actually see the company. That means making the whole organization legible to AI: every important action should leave behind an artifact the system can learn from. In practice this is unglamorous plumbing — record meetings with an AI note-taker, move decisions out of DMs and buried email threads, put agents in the channels where work already happens, and build dashboards that expose everything: revenue, sales, engineering, hiring, ops.

Sprint planning is the example I reach for. Give an agent access to your Linear tickets, your engineering Slack channels, the customer feedback sitting in email and support tools, the high-level plans in Notion or Docs, and the recordings from stand-ups and sales calls. Now it can look at what actually shipped last sprint and how well that matched real customer needs, then propose the next sprint far more accurately than a chain of manager status roll-ups ever could — each of those roll-ups quietly loses detail on the way up. I have watched teams wire this up, cut their sprint time roughly in half, and get close to 10x more done in that time. The principle underneath is simple: to get a model’s full capability, give it as much context as you would give a new hire. Starve it of context and you get a confused intern; hand it the whole picture and the coordination overhead that used to eat your week largely disappears.

Software factories replace handwritten code

There is a matching shift in how the fastest teams build product. If you know test-driven development, the AI software factory is the next turn of that same screw. Humans write a spec and a set of tests that define what success means; agents generate the implementation and iterate until the tests pass. The human decides what to build and judges the result — writing the code is the agent’s job.

Some teams have pushed this far enough that the repository holds no handwritten code at all, only specifications and test harnesses. StrongDM’s AI team is the example I point people to: they built a factory where specs and scenario-based checks drive agents to write, test, and rewrite code until it clears a probabilistic bar for “good enough.” It works. This is the real mechanism behind the “1000x engineer” that Steve Yegge talks about. You do not get there by hiring a superhuman; you get there by surrounding one capable engineer with a system of agents that lets them build what they never could alone.

The org chart is what actually breaks

Put those pieces together — closed loops, a queryable company, software factories — and the classic management hierarchy stops making sense. In the old world you needed middle managers to route information up and down the org. That routing layer was human middleware, and its whole job was to carry context between people who could not see each other’s work. If the company is queryable and legible to an AI, the intelligence layer does that job, and you should be left with almost no human middleware at all.

This matters because a company’s velocity is capped by the speed of its information flow, and every layer of human routing you remove is a direct gain. Jack Dorsey has landed on the same conclusion at Block: keep the same org chart and management structure and you have missed the shift entirely. The company itself gets rebuilt as an intelligence layer, with people at the edges guiding it rather than sitting in the middle relaying messages.

The roles that survive collapse to three. The individual contributor is the builder-operator who directly makes and runs things — and in an AI-native company that is not only engineers; sales, ops, and support show up to meetings with working prototypes instead of slide decks. The DRI, the directly responsible individual, owns a strategy or a customer outcome end to end — one person, one outcome, nowhere to hide. And the founder still builds, still leads by example, and does not hand their AI strategy to someone else. With that structure a small team gets outsized results, and the metric that matters flips: you are maximizing token usage, not headcount. Be willing to run an uncomfortably large API bill, because it is replacing a far more expensive and far slower pile of hires.

Early-stage founders have the edge

You cannot outsource your conviction on any of this. The only way to build it is to sit with the coding agents yourself and use them until they break your own assumptions about what is now possible. Read about it and you will nod along; do it for a week and the argument stops being abstract.

If you are early, you are holding a real structural advantage here. You have no legacy systems, no entrenched org chart, no thousands of people to retrain — you are small enough to build the company right from day one. Incumbents have the opposite problem: they have to keep a live product growing while unwinding years of standard operating procedure and deep assumptions about how software gets made. Some pull it off by spinning up a small skunkworks team that builds AI-native systems from scratch, kept separate from the core business — Mutiny is a good example. But for most large companies, every change to a core process risks breaking something that already works, which makes going AI-native genuinely hard for them. Startups do not carry that weight. Design your systems, your workflows, and your culture around AI from the start, and you can move at a speed the incumbents structurally cannot match.

Based on Diana Hu’s YC Startup School talk on building AI-native companies. The core argument is hers; this version is my synthesis and wording.

Related reading

• Why AI agents need a harness, not just a better model — the engineering underneath the intelligence layer this post assumes you can build.
• How to build an AI-native services company — the same thesis applied to trillion-dollar services markets.