Every company knows more than any one person in it can hold. The knowledge is real, it just lives in scattered places: a call from a few weeks ago, a thread, a field in the CRM, someone's memory. So getting an answer your company already has usually means going to find it. You ping the person who might know, wait, re-explain what you need, and reconstruct something that existed the whole time.
That cost has a shape, and it deserves a name. Call it the communication tax. Every company pays it, and almost nobody counts it.
It scales against you
The tax gets worse exactly as you grow. Two people share context by turning their chairs. Twenty need threads, docs, meetings, and a search bar. Two hundred need all of that, plus the knowledge of who to even ask. Every new person and every new tool adds another place for context to hide and another handoff where it gets lost. The bigger you get, the more of the day goes to moving information around instead of doing the work.
And the tax has a spike. Day to day it is a drip. The expensive version is when someone who held a lot of context leaves. The CSM who knew the real history of every account. The engineer who remembered why the system was built the way it was. When they walk out, the context walks out with them. You either lose it and rediscover it the hard way, or you spend their last two weeks trying to download what is in their head. The knowledge was never really the company's. It was rented from a person, and the lease just ended.
AI was supposed to fix this. Connecting tools doesn't.
This is the thing AI was supposed to solve. Give everyone an assistant that knows the company, and nobody has to interrupt anyone.
The current version of that promise is MCP: a clean, standard way to connect an agent to all your tools, the closest thing the industry has to a universal port. It is genuinely useful, and it is access, not knowledge. Access is the ability to reach your data. It is not a picture of your company.
Watch what an agent does with access and nothing else. Every time you ask it something, it starts over. It fetches from Slack, queries the database, reads a few docs, and assembles an answer from raw material, from scratch, on every run. A large share of what an agent spends its time and money on is not the task. It is rediscovering the company before it can begin. It has no memory of what it learned last time, no sense of what is current, and no idea that two of the sources it just read contradict each other.
So connecting more tools does not pay down the tax. It cuts the cost of reaching your data and does nothing about the cost of trusting it. If anything it adds a new one: a fast assistant paying the same interpretation tax you do, whose answers you now double-check because they are sometimes right and sometimes not. Access was the easy part. We mostly solved it. It was never the hard part.
Retrieval finds what is close, not what is true
The usual patch is RAG: embed everything, and pull the most similar chunks when the agent needs context. It helps, and it has a ceiling enterprises are hitting right now.
Retrieval returns what is semantically close to your question. Close is not correct. Ask about a deadline and you get the chunks that mention deadlines, the original plan, a revised plan, and an offhand message, all at once, all relevant, all disagreeing. Retrieval has no way to reconcile them. It does not know one is newer, that one came from the system of record and one from a hallway conversation, or that one replaced the other last month. It hands the model a pile of contradictory text and lets it guess.
That is why most enterprise retrieval problems are not model problems. They are information problems. The data feeding the agent is stale, conflicting, and unranked, and no amount of better embedding fixes a knowledge base that disagrees with itself.
Your coding agents are already paying it
If you work with Claude Code, Codex, or Cursor, you do not need the enterprise version of this argument. You are paying the tax in your own repo today.
Every team running coding agents has built a context layer by hand: a CLAUDE.md here, an AGENTS.md there, Cursor rules, a conventions doc. It works, briefly. Then the code moves and the context does not. The instructions say one thing, a migration from last week says another, and the agent, which has no way to know which is current, follows whichever it read first. So you correct it. Then your teammate corrects their copy. Then next month someone burns an afternoon on a bug that traces back to the agent confidently applying a convention the team abandoned in March.
Notice the shape: it is the same tax. The knowledge exists, the agent has access to it, and nothing tells anyone that two of the sources disagree or that one of them expired. Writing more context files does not fix it, for the same reason connecting more tools does not. Every file you add is another claim that can silently go stale, and the agent trusts all of them equally.
The missing primitive is a belief
Here is the part the connect-everything framing keeps skipping. The unit an agent should read is not a tool call, and not a chunk of text. It is a belief.
A belief is a claim with four things attached:
- Evidence. The exact source it came from, so it can be checked. A receipt, not a vibe.
- Weight. How much to trust it, based on where it came from and how recent it is. A signed contract outranks a passing comment. A system of record outranks a guess.
- Time. When it became true, and whether something newer has replaced it. Beliefs get superseded, not silently overwritten.
- A dispute state. What it conflicts with, if anything, and whether that conflict is resolved.
Take a launch date. A sales call promised March 15. The implementation doc later moved it to April 2. A Slack thread says probably end of March. The CRM still says March 15. Retrieval hands the agent all four and lets it pick. A belief layer tells it what the company currently believes, why, and that the date is still in dispute.
The codebase version is even cleaner, because the ground truth is checkable. Your CLAUDE.md says the plan limit is 15. The code says 50. A PR changed it yesterday, and the docs page still teaches the old number. A belief layer does not hand your agent all three and hope. It knows the code is the system of record, knows which claim is newer, flags the two stale sources, and can prepare the exact correction.
A connector cannot give you this. It gives access to the raw material a belief is made from. A retrieved chunk cannot either. It is just text that scored well on similarity. A belief is a maintained position: sourced, weighted, timestamped, and aware of its own contradictions. That is the difference between an agent that can reach your data and one that actually knows something about your company.
The field is already moving this way. Temporal knowledge graphs now track what was true when, and which source said it. That is the right direction, and it is not the whole problem. Knowing the timeline does not tell you what to do when two current sources flatly disagree. You cannot always take the newest one, because the newest one is sometimes wrong. The honest answer, when sources conflict and the system cannot be sure, is not to pick one quietly. It is to weigh them, and when it still cannot resolve them, to surface the conflict instead of guessing. Why that is the hard part, and how we think about getting it right, is its own essay.
Why this is the edge
Start with the part almost nobody else says. The advantage of a belief layer is not just that it knows your company. Plenty of tools will claim that. The advantage is that it is honest about what it does not know. When two sources disagree, it does not hand you a confident guess. It shows you the conflict and the receipts and lets you decide. A system you can trust to tell you when it is unsure is a system you can actually act on, and that is rare enough to be the whole game.
The rest follows from there. Everyone has the same models now. Your competitor runs the same Claude or GPT you do, so the model is not your advantage, because it is nobody's. What is actually yours is your company's own understanding of itself, and a belief layer turns that into something your team and your agents can read instantly, with the source attached, instead of paying the tax to re-derive it every time. The answer is there before anyone asks. The new hire understands the accounts on day one instead of month six. When someone leaves, the understanding stays, because it lives in the company and not in a person's head.
That compounds. A company that has paid down its communication tax moves a little faster on everything, every day, and the gap widens over time. You cannot buy it in a quarter, and a competitor cannot copy it by hiring your people, because it is no longer trapped in anyone's head to poach.
Connect the tools. Then build the beliefs.
Connecting your tools is necessary. Do it. MCP is good, and access is table stakes. Just do not mistake it for the finish line. An agent with access and no beliefs is a very fast new hire with a login to every system and no idea what is true.
The communication tax is the price of not having that layer. Connecting more tools cuts the cost of reaching your information. It does nothing about the cost of trusting it, and that second cost is the tax that actually slows you down. The only thing that pays it down is a layer that holds what the company believes: sourced, weighted, current, and honest about what it does not know. Your people and your agents read the same one, and stop rediscovering the company every time.
That is the layer we are building with Recon. Not another place to store what your company knows, but a way to keep what it believes true enough to act on.