Every System Has the Same Shape:
Agents, Components, and Interactions

The Three Elements

Everything is a system. An economy is a system. A team is a system. A market, a forest, a hospital, a supply chain, a classroom. All systems. And every system in the world (however complex, however large, however abstract) is made of exactly three kinds of things.

Agents give a system its purpose. They have intent, make decisions, and act. They're the reason the system exists. Remove them and there's no system left, because nothing decides, nothing responds, nothing cares.

Interactions are the rules and channels agents use to relate to each other and to components. They define what agents can do, what they know, and what happens when they choose. Change the rules and the same agents produce different outcomes.

Components are the resources and objects agents work with. A component can be complex (a server cluster, a piece of legislation, a drug compound) and still not be an agent. It processes or enables. It doesn't decide, and it has no goals of its own. Its value comes from the agents using it and the rules governing that use.

The Same Pattern, Everywhere

This isn't a metaphor. The three-element structure maps cleanly onto domains that have nothing in common on the surface. In each case, the same question applies: who are the agents, what are the interactions shaping their behavior, and what are the components they're working with?

The Business Operations row isn't there by coincidence. People, Process, and Tools (the management framework most organisations already know) is exactly this model applied to a single domain. The same three elements, the same logic, one specific context. Which means every insight from that framework generalises. And every insight from every other domain in this table applies back to organisations.

Sharpening the Three Elements

Two questions come up as soon as you try to apply this table to real cases. Both have the same kind of answer: the boundary isn't about capability, it's about purpose and scale.

Is deciding enough to make something an agent? No. Notice that the Web & Technology row keeps AI agents and models out of the Agents column, even the autonomous ones. The distinction isn't whether something makes decisions: sophisticated software makes decisions constantly. A chess engine chooses moves. A routing algorithm chooses paths. An autonomous AI agent plans steps, picks tools, and recovers from failures without a human approving each move. What none of them do is decide why. An AI agent executes the user's intent: the user sets the goal, the agent works out how to reach it. That's still a Component, an unusually capable one, because it processes and enables rather than owning the purpose. It would only cross into being an Agent if it originated its own goals independent of any user's request, which is a different claim than being autonomous in how it executes a goal someone else gave it.

Is "institutions" really a single agent? Not exactly. A court has judges who decide, clerks who process, procedures that structure how cases move, and precedent that shapes what's possible. That's an agent, an interaction layer, and a set of components, all packed inside what the table just labels "institutions." This isn't a flaw in the framework, it's how the framework behaves at every scale. A firm is an agent inside a market, and a full system of people, process, and tools inside itself. A court is an agent inside a legal system, and a full system of judges, procedure, and precedent inside itself. The three elements are fractal: zoom into any agent and you find the same three elements again, one level down.

What decides whether you treat something as an agent or unpack it into its own system isn't a fixed property of the thing, it's the question you're asking. Diagnosing why a market misallocates capital? Treat the firm as one agent responding to incentives. Diagnosing why that firm keeps misallocating capital internally? Unpack it: its people become the agents, its incentive structures become the interactions, its tools and capital become the components. Pick the zoom level that matches the failure you're explaining, then ask the same three questions again at that level.

Why Incentives Determine Everything

Naming the three elements is the easy part. The insight that makes this framework actionable is the relationship between them.

A system is stable when the incentives of the agents align with how the system needs them to interact with the components and with each other. When agents are individually motivated to do what the system collectively requires, the system runs itself. When they aren't, no amount of investment in components will hold it together.

Go back to the bike-sharing program. The agents, riders, had every incentive to use the bikes and zero incentive to maintain them. The interaction design was anonymous: no accountability, no consequence for damage, no feedback that made care a rational strategy for any individual. The components degraded as a result. This wasn't a hardware failure. It was an interaction design failure that created incentive misalignment in the agents. The most expensive fix, replacing the bikes, addressed the symptom while the cause remained.

This pattern appears in every domain. Three examples:

Two Failure Modes, Only Two

Every system that isn't working is broken in one of two ways. Not three, not five. Two.

The first failure is usually detected and addressed. Structurally absent elements are noticed: the capability gap is obvious, the tool hasn't been procured, the process hasn't been written. These are solvable with investment.

The second failure is almost always invisible until the damage is extensive. The system looks operational. Meetings are held, tools are in use, activity is visible. But the agents are doing exactly what their incentives reward them for, and those incentives diverge from the system's purpose. The divergence compounds quietly, at scale, and the system degrades until something breaks visibly enough to force a diagnosis.

How to Use the Framework

When a system isn't working, or when you're designing one, start with the three questions in order:

Who are the agents? What do they actually want? Not what they're supposed to want, not what the org chart says they want. What does their behavior reveal about their real incentives? This question alone resolves more system failures than any component analysis.

What does the interaction layer look like? What incentive structures does it actually create, not the stated ones, the real ones? What do agents get rewarded for? What do they get penalised for? What information do they receive, and does that information change their behavior in the direction the system needs?

Are the components adequate? Given what you now know about the agents and the interactions, which components would extend the system's capability? Not which components are available, not which are impressive, not which the vendor recommends. Which ones serve what's already working?

Draw It Before You Fix It

Answering the three questions in your head only gets you so far. Put it on paper: agents in one column, interactions in the middle, components on the right, then draw arrows for how incentives actually flow, not how they're supposed to flow. A whiteboard or a sheet of paper is enough. No software required.

The value isn't the diagram itself. It's what becomes visible once agents, interactions, and components sit side by side instead of tangled together in a meeting. An incentive arrow that points away from the system's stated goal. An interaction that connects to nothing. A component nobody's actually using. Friction that was invisible in conversation shows up as an arrow that doesn't line up on the page, and it usually shows up before you've even finished drawing.

Here's the opening story mapped the same way:

Nothing about that diagram required new information. Every fact in it was already in the story. What the drawing adds is the missing arrow: nothing carries the cost of a damaged bike back to the rider who caused it. That's the whole failure, visible in one line that doesn't connect.

Now redesign only the interaction layer and draw the same system again. Same riders, same bikes, same docks. The only thing that changes is the middle column, and that's enough to close the loop:

Same three elements, same domain, one redesigned column. The arrow that was missing now closes the loop, and the diagram shows a self-sustaining system instead of a degrading one, exactly the aligned-versus-misaligned distinction from earlier, drawn instead of described.

The three-element framework doesn't tell you what a system should do. It tells you what it actually is, and why it behaves the way it does. Once you stop seeing systems as undifferentiated complexity and start seeing agents, interactions, and components, you start asking different questions. Better questions. The ones that lead to fixes that hold.