> Site index: [llms.txt](https://ortelian.com/llms.txt) with all pages and descriptions.

# Map first, tools second

Source: https://ortelian.com/notes/map-first-tools-second/
Markdown: https://ortelian.com/notes/map-first-tools-second.md
Author: Laurens Nys
Published: 2026-09-27

Agents get the tools we built for people and rebuild a map of the company on every run. A world model for knowledge work gives them the map to query, and the tools feed it.

Getting AI to be maximally useful inside a company comes down to solving two problems:

1. Get AI actually used. That’s a people and process problem.
2. Make the model itself as useful as possible. That depends on what actions it can take and what context it has.

This note is about the second one, the context part, and my answer to it: a [world model for knowledge work](https://ortelian.com/notes/what-is-a-world-model-for-knowledge-work/). Today agents get the tools we built for people and rebuild a picture of the company on every run. They should get a map of the company and the world around it, and work from the map first and the tools second.

## We give agents the tools we built for people

When you ask the question “How do we make AI maximally useful inside (complex) companies?”, the first instinct is to look at how we make people useful. We do that by giving them tools, so agents get them too: the CRM, Slack, docs, call recordings.

Turns out a lot of those tools were built around human constraints that AI doesn’t have, while depending on something people have that AI doesn’t: a map.

People carry a model of their work and the world around it in their heads. What things exist, and how they connect. A rep sees a name and knows the account, the vertical, the open deal and what came up on the last call without having to look it up. They use tools mainly to expand on details of a map they already hold.

An agent has no durable map. All it has is the tools, so it has to build the map while it does the work. Each tool shows a slice of the company and its relationships: the CRM knows accounts and deals, Slack knows threads, the call recorder knows calls. Every run, the agent stitches those slices together, does the task and loses the picture when the run ends. The next run starts from zero. And it only ever finds the connections it thought to look for. That last part matters most. More on it below.

## How much that hurts depends on the work

Not all work suffers equally. It mostly depends on how much of the work is shaped by things outside your company.

*Diagram: A line from little outside influence on the left to a lot on the right. Writing code sits at the left end: almost everything it needs is in the codebase. Deciding what to build sits in the middle. Selling sits at the right end: spread across the CRM, email, calls and LinkedIn, and the world outside the company.*

*The more the work reaches outside the company, the less of what it needs sits in any one tool.*

Writing code sits on one end. Almost everything it needs is in one system: the codebase itself.

Selling sits on the other extreme. It’s spread across the CRM, email, calls and LinkedIn, and by definition it reaches outside your company: prospects, other companies, the people who move between them, regulations, events in the market.

Now look at what the tools hold. Mostly inside relationships. The CRM knows you have a deal with a prospect. It doesn’t know which regulation applies to that prospect, who they supply or that their champion just switched jobs.

So for code, the codebase already acts as the map. That’s a big part of why [coding agents took off first](https://ortelian.com/notes/why-coding-agents-work-and-company-agents-dont/). For selling it breaks, because most of the world isn’t in any tool.

## The answer is to give agents a map

We should give agents that map explicitly, and the ability to query it directly.

I call it a world model for knowledge work: a map of what shapes your company’s work, inside and outside the company, written down so agents can work from it.

(When people say “world model” today, they mostly mean models of the physical world, for robots and video. Knowledge work needs one too.)

There are three core layers to it.

*Diagram: Three layers. Data, the survey: tools, APIs and public data, flowing into the graph. The graph, the map: your ontology, filled in. Knowledge, the notes pinned to it: notes that AI writes and people edit, attached to the graph.*

*A world model for knowledge work is all three layers: the data that keeps it current, the map and the knowledge tied to it.*

**The data:** everything that comes in from your tools and from outside: the CRM, Slack, call recordings, public APIs. Instead of an agent having to combine tools to build a full picture of a company, the model holds it all and combines it into the map. Every fact keeps its source and when it was true, so an agent can tell a government registry from a rep’s guess.

**The graph:** your ontology, filled in. [Ontology](https://ortelian.com/notes/what-is-an-ontology/) is a big word for a simple and old idea. (Palantir made ontologies big in enterprise software, but Aristotle was sorting the world into categories more than 2,000 years earlier.) It defines what kinds of things exist in your world and how they relate, the nouns and verbs:

- person → works at → company
- company → belongs to → vertical
- person → raised → objection
- regulation → applies to → vertical

Building it means asking: what influences how your company operates? What influences sales? And what influences those influences? Or, at a meta level: what influences the work?

Filling it in means adding the actual companies, people, events and so on. One core idea here is that you don’t just fill it with inside knowledge. You map the full world, so the companies both inside and outside your CRM.

**The knowledge:** notes tied to the things on the map: what you understand about a company, a deal, a regulation. AI writes them, and people maintain and review them.

If you like the map metaphor: the data is the survey, the ontology is the legend, the graph is what’s drawn from it and the knowledge is the notes pinned to it. The territory is still the real world, and the map is only useful while it matches. That’s why the data keeps flowing in.

That’s also the difference with a [knowledge graph](https://ortelian.com/notes/is-a-world-model-for-knowledge-work-a-knowledge-graph/). A knowledge graph is roughly the middle layer. A world model is all three: the data that keeps it current, the map and the knowledge tied to it.

## Map first, tools second

Today the agent’s way into your company is a list of tools. It goes tool by tool and rebuilds the map as it goes.

A world model flips that. The tools feed the map, and the agent works from the map.

*Diagram: Before: an agent reaches into the CRM, Slack, docs and call recordings one by one and rebuilds the picture on every run. After: the CRM, Slack, docs, calls and public data feed a world model for knowledge work, and the agent queries the world model.*

*The tools don't go away. They feed the map, and the agent still uses them to act.*

Say a new regulation comes out, and you ask an agent: which open deals does it affect?

Tool by tool, it searches your wiki and the web for the regulation, guesses which companies it might apply to, looks each one up in the CRM and checks their deals. It only checks the companies it thought of, and it mostly misses the ones that aren’t in your CRM yet.

On a map it’s one query: regulation → applies to → vertical ← belongs to ← company → has → open deal. Every company in that vertical is already on the map, including the ones you’ve never talked to.

That’s what I mean by querying the map. The agent works the way a good rep does: map first, tools second. The tools don’t go away. They feed the map, and the agent still uses them to act (send the email, update the deal). But it reads the world from the map.

## Knowledge should sit connected to what it’s about

The way we store knowledge today is an artifact of how humans work, not how AI works.

Say a salesperson learns about a new regulation from a prospect. To pass it on, they post it in Slack or write it in a wiki. The knowledge is now cut off from what it’s about: the regulation, the prospect, the other companies it applies to. For people that’s fine. Whoever reads it holds the map and reconnects it in their head. For an agent, it’s a loose note with nothing to attach to.

In a world model, that knowledge sits on the regulation. The regulation is linked to the vertical, and through it to the prospect and every other company in it.

## Why not build a company brain in Obsidian?

Why not just build a “company brain” in something like Obsidian, or as a folder of markdown files? It seems to be the company brain tool of the moment.

The core difference: a wiki doesn’t tie knowledge to the things. A wiki is pages that people (or AI) write and link. The knowledge sits on the page, and the things it’s about (the company, the person, the regulation) are words or links on it. A link says two pages are related, not how. In a world model the thing itself is the node, every link says how things relate (works at, belongs to, applies to) and the knowledge sits on the things it’s about. That’s what lets an agent hop across many nodes and assemble an answer.

A wiki solves a human constraint: people need pages to read. Agents don’t. They need the map.

## The reason to bother is sight

Just because we can build this doesn’t mean we should. So why should we?

I think the core argument is [sight](https://ortelian.com/notes/what-sight-means/). With everything connected in one place, you see what no single tool shows. The regulation from that one call shows up on every account it touches. The objection from one call turns out to be the same one hitting three other accounts in the vertical. Nobody asked for those connections. They were just there once the map was.

(Sidenote: this is [where our name comes from](https://ortelian.com/1570/). In 1570 Abraham Ortelius put the world’s existing maps into one atlas. Looking at the whole, he later noticed that the coasts of the Americas, Europe and Africa seemed to fit together, more than 300 years before anyone proposed continental drift.)

This is also the case against standard RAG. Search finds the documents that match your question. It can’t find a connection you didn’t know about. Microsoft’s [GraphRAG paper](https://arxiv.org/abs/2404.16130) makes the same point for documents: plain RAG struggles with questions about a whole collection, and a graph built from those documents does better. I go through the evidence in [the case for GraphRAG](https://ortelian.com/notes/the-answer-is-between-the-documents/).

## The map already exists regardless

The good news: nobody has to invent this map. Every company already has an ontology. It lives in the heads of its people. It’s just undefined.

Just because it’s not written down doesn’t mean it doesn’t exist.

## Follow the work.

Every Sunday. Notes only. Unsubscribe anytime.

Email address