What I kept noticing
Across a decade of work with engineers, founders, researchers, and product teams in many domains, the hardest obstacles were never the APIs or the compute budget. They were alignment problems that surfaced before any line of code was written. Teams had to agree on what they were building, why it mattered, who it served, what constraints existed, and which trade-offs were acceptable. Those agreements emerged in conversations, sketches, specs, and documents—not because the artifacts were the goal, but because they gave people a common ground for reasoning.
Over time I realized those artifacts were all trying to accomplish the same thing: they were building a shared language—a conceptual model that let different people talk about the same business without constantly re-explaining it. A single phrase could carry months of context; a diagram could encode relationships that never needed to be spelled out again. The team's effectiveness grew as their mental model converged.
The moment my thinking shifted
When I began building AI systems, I expected the interesting work to be making the models execute better. Large language models were already writing code, drafting documents, and synthesizing research, so the challenge seemed to be making those capabilities easier to use.
Instead, I found myself drawn to a different problem. As we moved from a single monolithic model to collections of specialized agents—some gathering information, others planning, evaluating, generating, or coordinating—the need for collaboration grew. Each agent had to reason about the same business, but they were each reconstructing the same mental model from fresh prose prompts. Every hand-off required translating concepts back into language, and the system ended up rebuilding context rather than sharing it.
That realization flipped the question: Humans collaborate because they develop a shared conceptual model through language. What do software agents need? The answer was not "more prompts" but a shared representation that lives independently of any particular language.
The intervention: making the business model explicit
Instead of treating business judgment as hidden inside documents, I began to represent it directly:
- Capabilities, customers, pains, markets, business models, constraints, assumptions, and strategic decisions became first-class objects.
- The relationships between those objects were encoded explicitly (e.g., a capability solves a pain; a pain matters to a specific customer; a customer belongs to a market; a market shapes the business model; the business model imposes constraints).
What changed
Before: each agent (or human) received a prompt like "describe the customer, the goals, the constraints…" and had to reconstruct the model from scratch.
After: every participant read from the same graph. Improving the graph once instantly improved every downstream reasoning process.
The conversation shifted as well. Instead of asking "Why did we make this decision?" teams began asking "Is this relationship correct?" The focus moved from defending conclusions to inspecting the assumptions that produced them.
Durable principle
Representations are infrastructure for reasoning. As execution becomes cheaper, the limiting factor in any intelligent system—human, agent, or hybrid—is the quality of the shared conceptual foundation they operate on.
Takeaway
I started out trying to make agents better at reasoning. I ended up spending far more time designing what they were reasoning over.
If you're building multi-agent systems, invest early in a clear, explicit model of the domain you're trying to reason about. The effort pays off in every subsequent coordination step, whether the participants are people or machines.