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

# Why coding agents work and company agents don't

Source: https://ortelian.com/notes/why-coding-agents-work-and-company-agents-dont/
Markdown: https://ortelian.com/notes/why-coding-agents-work-and-company-agents-dont.md
Author: Laurens Nys
Published: 2026-08-05

Coding agents took off first because a repository is already a world an agent can stand in. A company is not, so you have to build that world before asking the agent to work.

Coding agents were the first agents that worked. They went from autocomplete to closing tickets on their own. Every other department was promised the same thing and mostly got a chatbot. The same model runs both. The difference is that a repository is already a world an agent can stand in, and a company is not. So the job of deploying agents in a company is building that world first, and only then asking the agent to work.

## A repo is visible, editable, testable and versioned

Look at what a coding agent gets for free. It can read every file in the project. It can change any of them. It can run the tests and know within a minute whether the change was right. It can see the diff, so it knows exactly what it did and can undo it.

The knowledge about the code also lives next to the code. The README says how to run it. The tests say what correct means. The commit history says what changed, when and who did it. A coding agent dropped into a repo on Monday morning has the same standing as a new engineer. Nobody built any of this for the agent. Git and the test suite were built for humans over twenty years, and they happen to be exactly what an agent needs.

## A company’s records are not the company

Now look at what a sales agent gets. The company’s knowledge is spread across the CRM, Slack, call recordings, spreadsheets, email and people’s heads. None of those is the company. A call note is evidence about the world, not the world. The CRM says a deal is at “proposal” stage, which is one person’s opinion, entered at some point, possibly still true.

I watched this go wrong at a planning-software company we work with. A new head of sales, a few weeks in, stopped all outbound and changed the deal stages in the CRM. He did not tell the CFO. Nobody inside the company knew the full plan. An agent reading that CRM that week would have been working from a fiction: stages that no longer meant what they meant a month earlier, a pipeline nobody was working. Nothing in the records would have told it.

Compare the repo. If someone renames a function, the code that calls it breaks and the tests say so. If someone renames a deal stage, the dashboards look fine.

## Humans bridge the gap by hand, and agents cannot

Companies still work because people carry the missing structure in their heads. The senior rep at a deep-tech company we deployed at knows a CRM field is stale because he was on the call yesterday. He knows which rows in the partner spreadsheet are worth a call. He knows the stages changed because he was in the room. None of that is written anywhere an agent can read.

That is why the demo works and the deployment does not. In the demo, a person stands next to the agent and fills in what the records leave out. In production, the agent is alone with the records. When we started at that deep-tech company, the partner list was a spreadsheet of about 2,700 companies. The reps knew which ones mattered. The spreadsheet did not.

## The fix is to give the company what the repo has

So the work is building for the company the five things git and a test suite give the code. Built and maintained, that is what we call a [world model](https://ortelian.com/notes/what-is-a-world-model-for-a-company/).

*Diagram: A five-row comparison: identity, provenance, history, tests and permissions. Each is shown as a repository has it, as a company is found, and as what we build for the company.*

*The five properties a repository gives an agent for free, and what each has to be built as for a company.*

Stable identity for every object. In the repo, a file has one path. In the company, one hospital shows up as four rows with three spellings. At the deep-tech company we rebuilt the territory from government sources, hospital lists and integrator registries, matched everything to one record per company and linked it to the CRM. The 2,700 rows collapsed to 64 ranked accounts, 48 of them with contacts already pulled.

Provenance on every fact. In the repo, git blame tells you who wrote the line. In the company, a fact has to carry where it came from and when it was recorded, so the agent can tell a stage the head of sales changed yesterday from one nobody has touched since March.

Facts that supersede rather than overwrite. A commit does not delete history. When a contact changes role, the old role should stay, marked with when it stopped being true. Otherwise the agent cannot tell “current” from “last entered”.

Evaluations on real examples, as the equivalent of tests. Before we build, we agree with the customer what good looks like on real cases: does the meeting brief meet the standard for these ten meetings? Those cases become the evaluations. When the output falls short after launch, we change the knowledge or the workflow and run them again. That is the loop a coding agent gets for free from the test suite.

Permissions enforced below the model. In a repo, branch protection decides what gets merged, not the agent’s good intentions. In a company, what the agent can read and write has to be enforced by the platform, not by the prompt.

## Traces on the graph are the closest thing sales has to git history

At the deep-tech company, a meeting-prep agent runs at 9am every morning in a shared Slack channel. For each external meeting that day it pulls previous calls, emails, deal history and similar companies from the CRM and the graph, and writes a brief. Each run leaves a trace on the graph. The next run starts where the last one stopped. When the rep gives feedback in the channel, that feedback changes future output.

That is the versioning property, rebuilt for a sales team. There is a record of what the agent knew, what it did and what changed since. Without it, every morning would start from nothing. With it, the rep found the channel on his own and now checks it before every external meeting.

## Bigger context windows will not fix it

The counterargument I hear most: wait a year, the context window will hold the whole company, and this problem goes away.

It will not. The context window is working memory. It holds what the agent is looking at right now and empties when the task ends. The repo’s advantage was never that it fit in memory; most repos do not. Its advantage is durable structure: one path per file, a history of every change, a test that says whether the change was right. A million tokens of CRM exports and Slack history is still a pile of evidence with no identity, no provenance and no test. Give an agent all of it and it will read the fiction faster.

Coding agents worked first because someone had already built their world; for the rest of the company, building that world is the work.

## Follow the work.

Roughly monthly. Notes only. Unsubscribe anytime.

Email address