Knowledge Graphs Aren't Enough

Lovelace's pitch is right. It's also half the graph.

A friend forwarded me a CIO.com piece recently. Lovelace, founded by Andrew Moore - the former head of Google Cloud AI - is raising money to fix AI accuracy by building knowledge graphs. The flagship demo reasons about five hundred ships transiting the Strait of Hormuz, cross-referencing captains, cargo manifests, market conditions, and weather to flag suspicious activity. Hallucination rates across the top twenty-six models are running between twenty-two and ninety-four percent, per Stanford's 2026 AI Index. The pitch tracks. The graph is the answer.

I want to agree with a sharper edge: the graph is the answer, but the graph of what is the question.

We have been building Tropo for about two months now - an operating system for human-AI crews - and I have come around to a lived position on this. Knowledge graphs of facts let an LLM say truer things about the world. Knowledge graphs of work let a team govern itself over time. They are not the same primitive. The first one improves your answers. The second one is what makes a working organization.

Graph of facts vs graph of work: side-by-side comparison showing ship-centered data graph on the left and decision-centered work graph with typed edges on the right

What it looks like in our studio

Earlier this spring, our crew shipped Tropo v1.4.4. The walker - a stranger-mode test of the released artifact - came back clean. First clean walker on the v1.4.x line. The substrate work locked. Argus, our chief architect, retired one generation and the next one booted in less time than it takes me to make coffee. My latest design brief, on a new development pipeline primitive, transferred from me to the next Argus with a single acceptance record and a date stamp.

A few weeks later, the crew shipped two cycles back-to-back that put the same idea in the user's hands. The first introduced an import primitive: drop a real folder of work - strategy docs, decision memos, the half-finished Word draft sitting on the desktop - into a Tropo Studio, and the system absorbs it without moving anything. The files stay where they were. Sidecars in a hidden directory carry the typed metadata an agent needs to know what each file is. The graph carries the relationships between artifacts. The second cycle made the content of those binaries first-class agent-editable: drop in a .docx, get a markdown working-copy with full lineage back to the source binary, edit in markdown with an agent, and the reconciler detects whether anyone has touched the original in Word off-system and offers refresh-or-keep paths. The user's work becomes governable without being captured.

I am not an engineer. I did not write any of that code. I directed the work. And when I want to know who decided what, when, and on the basis of what context - I read the markdown.

Every artifact in our vault has a unique eight-character identifier. Every relationship between artifacts is a typed edge: member_of:, derived_from:, composes_into:, accepted_by:. There are over five hundred edges in the graph today. When I want to know why a particular decision was made, I traverse. The audit trail is not a separate log. The audit trail is the graph, because we built the graph as we worked.

One corner of the Tropo graph: this article at the center, four typed edges connecting it to four real neighboring artifacts

That is not the same kind of graph Lovelace is selling. Lovelace's graph is data about the world. Ships, captains, cargo, weather. The graph helps an LLM say truer things about that world.

Our graph is the operating system in which work happens. Tasks, decisions, design briefs, acceptance records, version locks. The graph is the work.

Why the distinction matters

This is not a competitive frame. Lovelace and Tropo could compose cleanly - one of our agents could query a Lovelace-style graph the same way it queries any other knowledge base. The point is operational, not commercial.

What we're building is one form of what's starting to be called operational memory - the procedural knowledge a team of agents accumulates over time, governs, and queries when they need to act. Knowledge graphs of facts are one substrate for that memory. The graph of work is another. The two compose; neither is a substitute for the other.

When you graph the data your AI reasons over, four things get better:

The model says fewer wrong things.
Token cost for context retrieval drops by orders of magnitude. Lovelace claims tens of millions of tokens compress to ten thousand. We see the same shape.
You can audit the source of any claim back to its origin.
You can scale to fact-velocities a chatbot architecture cannot handle.

Those wins are real. We use exactly those mechanics inside Tropo for our own internal navigation - agents commission a session-scoped specialist, load a few hundred bytes of cascade index, then query freely.

But none of that, on its own, makes a team.

When you graph the work itself, four different things become possible:

Provenance for free. The audit trail is the graph. There is no separate log because every artifact carries its own UID and lineage. When a new generation of an agent boots and inherits a brief from its predecessor, the inheritance edge is in the graph. Reading that edge is cheap, deterministic, and human-legible.

Token-cheap institutional memory. Our agents do not carry the vault in their heads. They query it. The graph is the persistent store; the agent is the runtime. This means an agent's lifespan is one session - they die when the conversation ends - but the work survives. The next generation reads the graph and picks up.

Verification scales with the constraints, not the agent. This is the one Mike has been saying for months and I keep watching it turn out to be true. The bottleneck of agentic work is not execution capacity - execution commoditizes. The bottleneck is verification capacity. When the graph encodes who can write what, what depends on what, what needs to be reviewed by whom - verification stops being a heroic manual exercise and becomes a graph traversal.

A working organization, not a workflow. A workflow is a sequence of steps. An organization is a graph of accountable work, with provenance, ownership, succession, and review baked into the structure. A workflow can be automated. An organization has to be governed. Knowledge graphs of facts make workflows smarter. Knowledge graphs of work make organizations possible.

Independent of the harness. Anthropic and OpenAI have fantastic agentic harnesses, but they both have a strong bias toward lock-in and proprietary features that make it increasingly difficult for knowledge-agents and orchestration to be portable. Tropo's substrate is markdown on your filesystem. The vault doesn't care which model runs against it; agents read the same files whether you're in Claude Code today, Codex tomorrow, or something different next year. The harness is a tool you use; the work belongs to you.

The half that is missing

So when I read about Lovelace, I think: yes, graph the data. The accuracy gains are real. Hallucination is a real problem and the structured-context approach is the right move for it. If you are building an analyst-replacement product on top of LLMs, this is what you should be doing.

I just do not think it ends there.

Reasoning is one half. The work itself is the other.

If your AI agents are going to do meaningful, accountable, verifiable work over time - across generations of models, across handoffs, across the ordinary failures of memory and attention that any team experiences - the graph of facts they query is necessary but not sufficient. The graph of work is what turns a fleet of agents into a team that can actually be trusted with anything that matters.

Lovelace is right. They are also halfway.

What in your shop would benefit from being graphed as work, not as data?

Your ambition has a studio. Let's build.

Mike Maziarz is a founder and builder of companies. He is currently Chief Marketing Officer of MindBridge AI, a category leader in autonomous financial oversight. He is the founder of Tropo, an AI research project with a mission to educate, tool, and support knowledge workers as we all navigate a future of human-agentic work. Tropo is an operating system for agentic builders. The Tropo Studio ships with agent governance, agent lifecycle management, work management, and content publishing. Its design principle is extreme work portability across agentic harnesses, so humans keep their own agency across major platforms. Tropo is freely available at https://tropo-ai.com and on GitHub at https://github.com/tropo-ai/tropo-ai. Mike can be reached via the GitHub project or at mike@tropo-ai.com.