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

# Access is not a map

Source: https://ortelian.com/notes/access-is-not-a-map/
Markdown: https://ortelian.com/notes/access-is-not-a-map.md
Author: Laurens Nys
Published: 2026-05-24
Updated: 2026-09-23

Connecting an agent to the CRM, Slack and email gives it territory. The map, what those things are and how they relate, still has to be built.

Most companies start an agent project the same way. They connect it to the CRM, Slack, email and the web, and expect it to understand the work. It can now read everything an employee can read. Then it drafts a follow-up that repeats a date nobody approved, or sets the account owner to the wrong person, and the project stalls. Access gives an agent territory. The map, what those things are and how they relate, has to be built. Until it is, more access makes the agent more confidently wrong.

## Access makes demos look smarter than they are

In a demo, access looks like intelligence. The agent finds the right document. It drafts the email. It updates the field. Everyone sees motion and concludes the agent can work.

But the demo picked the task. In a company, work is rarely one isolated action. The follow-up depends on why the deal matters, who owns it, what changed on the last call, what is safe to put in writing and which source is right when two disagree. A new hire with every keycard on day one is in the same position. They can open every room. They still don’t know how the business fits together, and it takes months of watching people to learn it.

That is where stalled agent projects usually sit. The agent has the keycards and no map.

## A customer promise is a chain of facts, not a note

Take a sales call. The customer says: “If you support this by Q3, we expand to the whole region.”

An agent with access to the recording summarises it and creates a follow-up task. Useful, and shallow. A rep who knows the company hears something else. The promise depends on a product limit. The product limit touches the roadmap. The roadmap decides what sales may say in writing. The expansion changes the account value, and repeating that date to the customer probably needs someone’s approval first.

*Diagram: One sentence from a sales call. Read as text, it becomes a follow-up task. Read as a chain of facts, the promise depends on a product limit, which touches the roadmap, which decides what sales may say, which needs approval; the promise also changes the account value.*

*The same sentence, read as text and read as a chain of facts. Access alone yields a task; the map yields a risk with an owner and an approval before the date goes back to the customer.*

None of that is in the transcript. It is in the relations between the customer, the product, the roadmap, the account and the approval path. An agent that sees only text treats the promise as a note. An agent working from a model of those relations sees a risk with an owner and a next action. That difference is where most demos break in production.

## The 64 accounts were never in the CRM

A deep-tech company we work with sells into hospitals through integrators. Its sales team had the CRM, an enrichment tool, LinkedIn and a spreadsheet of about 2,700 partner companies. That is more access than most agent projects get. Any agent could have read all of it.

None of it said which of the 2,700 mattered. The spreadsheet was dirty, the CRM held what reps had typed in, and the tools could enrich a company but not tell you whether it was a real prospect. So we built the territory instead: a graph from government sources, hospital lists and integrator registries, normalised and linked to their CRM. The 2,700 rows collapsed to 64 ranked accounts, 48 of them with contacts already pulled.

*Diagram: Left, access: the CRM, an enrichment tool, LinkedIn and a 2,700-row spreadsheet each feed an agent, whose output is 2,700 rows read carefully. Right, map: government sources, hospital lists and integrator registries feed a territory graph of hospitals, integrators and CRM accounts, which feeds the agent, whose output is 64 ranked accounts, 48 with contacts.*

*One deep-tech company, first week. Same tools, same reps; the 64 accounts came from the map, not from the access.*

The 64 were not hiding in a system the agent lacked access to. They came from putting the sources side by side and resolving what was the same company, what was a hospital, what was an integrator and how each connected to the accounts already in the CRM. That is a map. Connecting more tools would never have produced it, because the tools do not know what a hospital is or which integrator serves it. [A world model for knowledge work](https://ortelian.com/notes/what-is-a-world-model-for-knowledge-work/) is that map, kept current.

## More tools make the mistake bigger

The obvious response to an agent that gets things wrong is to connect more. More CRM fields, more call transcripts, more Slack history, more MCP servers, more write permissions.

Sometimes that helps. Usually it gives the agent more ways to be wrong. If the agent cannot tell which source wins, adding a source adds a conflict. If it cannot tell what needs approval, adding a write permission adds an unsafe write. Go back to the Q3 promise. An agent with write access to the CRM and the outbox, and no map, can log that date as a commitment and repeat it to the customer before anyone in product has seen it. The more it is allowed to write, the further the mistake spreads.

You might expect better models to make the map unnecessary, since they read messy context better every year. A smarter model does read the spreadsheet more carefully. It still cannot know that the 2,700 rows should be 64, because that fact is not in the spreadsheet. Nobody infers the map from the data. Someone builds it and keeps it current.

## Start with one operating loop, not the whole company

None of this means modelling the whole company before the agent can do anything. That is the other trap. It sounds serious and mostly delays contact with reality.

Pick one operating loop where context keeps breaking. A call turns into follow-up work. A rep needs a fresh list every morning. A promise touches product. Map that loop: what the agent reads, what it may change, which source wins when two disagree and what needs a person’s approval before it goes out. At the deep-tech company that first loop was the territory list, [built in a week](https://ortelian.com/notes/one-week-at-one-company/). The map that produced the 64 accounts is the same one the meeting-prep agent now works from at 9am each morning, pulling previous calls, emails, deal history and similar companies for that day’s external meetings. One loop, mapped once, and the next agent starts from it.

So the question to ask about an agent is not what it can access, but what map it is using when it acts.

## Follow the work.

Roughly monthly. Notes only. Unsubscribe anytime.

Email address