Eli5 article review series: Institutional AI versus Individual AI

Institutional AI vs Individual AI

Source:a16z News, George Sivulka

Abstract. Sivulka draws a historical parallel with the New England textile mills of the 1890s. Factories swapped out their steam engines for electric motors and saw almost no increase in output for thirty years. Productivity only materialized in the 1920s, once the entire factory floor was redesigned around the new technology with assembly lines and individual motors per machine. His thesis is that we are repeating the same mistake with AI today. We have swapped the motor, but we have not redesigned the factory. To bridge that gap, he introduces seven pillars of what he calls Institutional AI: coordination, signal, bias, edge, outcomes, enablement, and unprompted action. The argument is that pure productivity tools for individuals create chaos, while institutional intelligence creates coordinated, deterministic, revenue-generating systems built on top of foundation models.

Review and insights. The historical analogy is the strongest part of the piece. The idea that new technology only delivers value once you redesign the surrounding system is not new, but it is rarely applied this directly to AI. The article does a good job naming a pattern that many organizations are quietly experiencing right now. Every employee has their own ChatGPT habits, their own prompting style, their own outputs that do not connect to anyone else's outputs. The org chart still exists, but the actual flow of AI-generated work tells a different story.

That said, parts of the piece read as a vision rather than a roadmap. Sivulka runs an AI company funded by a16z, so it is no surprise that the conclusion points toward purpose-built institutional AI products. There is also a striking paradox worth noting. Sivulka openly states that he asks his own executive team not to use AI for any final written product because the output is slop. Coming from an AI founder, that is a remarkable admission about the current state of the technology.

In our discussion, we worked through a few specific points where the vision meets the reality of the organizations we work with every day.

• The realism gap. The seven pillars are a useful thought experiment, but applying them to an existing organization with a few hundred people is hard. New AI-native companies can build around these principles from day one. Established Dutch SMEs cannot, especially in the current cautious investment climate.
• Continuous modernization beats one big leap. The companies that handle this well are not the ones that suddenly decide to become AI-first. They are the ones that have been modernizing their stack and processes for years. Stripe is the obvious example: developer-driven, community-active, engineering treated as a first-class function. That posture absorbs institutional AI naturally. A company that revisits its processes once every five years cannot.
• End users are usually the bottleneck. Resistance rarely comes from the people managing data and infrastructure. It comes from the end users who have built their daily routine around the current system. Sivulka frames adoption as a top-down problem. In our experience it is more often a middle-layer problem.
• Deterministic agents need a harness. The article says institutional AI must be deterministic, defined, and auditable, but does not explain how. In practice you wrap the model in guardrails, a context layer, and a defined toolset. Standards like the Model Context Protocol are emerging, but Anthropic, OpenAI, and Gemini all do it differently. For now you build the harness yourself with skills files, context files, and memory files.
• The edge has moved up the stack. Foundation models are eating the app layer, and app layer companies are climbing into the solution layer. Anyone can prompt a CRM into existence today. Whether it solves a real business problem is a different question. The edge is no longer in building the thing. It is in knowing which thing to build for which niche, and being able to support, secure, and improve it over time.

Link to software modernization

The piece never actually says "modernization", but the connection is unavoidable. You cannot drop institutional AI on top of a legacy backend and expect coordinated, deterministic, revenue-generating outcomes. The same way you could not drop electric motors into a 1890s textile mill and expect modern factory output.

For most of our clients the realistic path is not to rebuild the entire organization from scratch. It is to modernize the backend in a way that makes institutional AI possible later. That usually means a few things. First, getting the data into a state where it can actually be queried reliably, because garbage in still means garbage out. Second, exposing the right parts of the legacy system through clean interfaces so that AI tooling can consume them safely. Third, documenting the buried business rules that explain why the data looks the way it looks, since uncovering those is often eighty percent of the work in any modernization project before a single line of new code is written.

The frontend can change shape over the years. It can become an AI agent that talks back, a clean web interface, or something we have not invented yet. The backend is what determines whether any of that is even possible.

Concluding remarks

The historical analogy is sharp, the seven pillars are a useful framework for thinking, and the observation that productive individuals do not automatically make productive firms is true and underdiscussed. It loses a few points for being a vision piece without a real blueprint, and for being noticeably aligned with the kind of company the author runs and the kind of company a16z invests in.

For most organizations, the takeaway is not to immediately go build an institutional AI strategy. It is to keep modernizing the backend, keep the data clean, document the why behind the system, and stay close enough to the AI landscape to move when the standards finally settle. The factories that win the next decade will be the ones that quietly rebuilt their floors while everyone else was busy buying new motors.
‍

Full video episode: Institutionele AI vs Individuele AI (Dutch)

The first step to start your modernization journey

Software modernization and architectural rebuilds lie at the heart of Eli5. We solve complexity to deliver direct business value by focusing on pragmatic, cloud-native transitions.

Before you decide whether to wrap your legacy system, buy a new SaaS product, or use AI to build custom tools, you need total visibility into your current tech landscape.

Would you like to book a free brainstorm to discuss your legacy stack? It is the essential first step to turning your technical debt into a scalable, modular future.

‍

‍

‍