Tacit knowledge
Some of what your team knows cannot be written down, only shown. That is precisely the knowledge your coding agent is working without.
You can ride a bicycle. You cannot say how. The rule a balanced cyclist actually follows, adjust the curvature of your path in proportion to your imbalance and inversely to the square of your speed, is one the chemist and philosopher Michael Polanyi could write down and no rider has ever used. You keep your balance by knowing something you cannot state. Polanyi opened his 1966 book with the line that names the whole problem: we can know more than we can tell.
The knowledge that will not go into words
Polanyi called it tacit knowledge, and once you have the idea you see it everywhere. You recognize a friend's face in a crowd of thousands and could not begin to describe the features you used. A doctor reads a chest film and sees pneumonia before she can list what tipped her off. A senior engineer looks at a design and says it will not scale, and the reasons arrive later, if at all. The knowing runs ahead of the telling, and some of it never catches up.
This is not the same as knowledge that merely has not been written down yet. That distinction is the whole point, and it is the one most people skip. Some knowledge is unwritten because nobody got around to it. Other knowledge is unwritten because it cannot be fully put into words at all, only demonstrated, watched, absorbed by working alongside someone. Polanyi's claim, the strong one, is that this second kind is not a gap in our documentation. It is a permanent feature of how expertise works.
Later writers gave the useful half a name. Ikujiro Nonaka called the act of turning tacit knowledge into explicit, statable form externalization, and treated it as one of the hardest and most valuable moves an organization makes. Not writing more down, but converting the kind of knowing that lived only in a person into something that can be shared. Most of what a company knows how to do has never made that trip.
Your agent only ever gets the explicit half
Now think about what a coding agent can actually read. The code. The schema. The ticket. The comments, the docs, the tests. Every one of those is explicit knowledge, the part that already made it into words. The agent is, by construction, a reader of the explicit layer and nothing else.
But the decisions that matter are sitting in the tacit layer. Why the rate limit is forty a minute and not ten is not in the code, it is in the memory of the person who negotiated the contract. Why users are keyed by organization and not by email is not written anywhere, it is a scar from an incident three years ago. Why this one module is never touched without a review is understood by everyone on the team and recorded by no one. None of it reached the agent, and not because your team is lazy. It never got written down for the oldest reason there is: everyone who needed it already knew, so saying it out loud felt like stating the obvious, right up until the person who needed it was a machine that had never sat in the room.
The documentation illusion
The reflex is to say we will just document it. And teams do have documentation, sometimes a great deal of it. But documentation captures the explicit residue of a decision, the what, and tends to lose the tacit reasoning that produced it, the why. The wiki says the limit is forty a minute. It does not carry the judgment that would tell you when forty is wrong. That judgment was tacit, and writing the number down did not externalize it, it just recorded the output.
So the agent reads the number, treats it as settled, and moves on, exactly as it treats every other value it finds. It cannot tell the difference between a number that encodes hard-won judgment and a number somebody typed as a placeholder, because the thing that would let it tell them apart never made it out of a human head. When it reaches a fork the documentation does not cover, it does the only thing it can. It fills the gap with a default, and the default is a ghost decision nobody made.
Why this is the deepest version of the context gap
I have written before that a coding agent is a nearly perfect agent whose one remaining weakness is information it cannot see. Tacit knowledge is why that information is so hard to hand over. It is not sitting in a document waiting to be attached to the prompt. It is distributed across people, encoded in habits and instincts, and a good part of it has never existed in a form you could copy and paste at all.
That is also why the naive fix fails. You cannot dictate your entire organization into a text file, both because there is too much of it and because Polanyi is right that some of it will not go into words no matter how long you talk. The dream of writing everything down was tried, under the name knowledge management, and its signature failure was graveyards of stale wikis. The judgment that mattered stayed tacit and left when its owners did.
Why the enterprise feels it most
An enterprise is a deep reservoir of tacit knowledge. Decades of decisions, exceptions, and instincts live in the senior people who have been there longest, and almost none of it is written in a form an agent could use. It is also the place where that knowledge is most expensive to lose, because when one of those people leaves, the context walks out with them, and the enterprise has always half-known this without a way to fix it.
Now the same enterprise is pointing coding agents at the exact systems that tacit knowledge governs, and asking them to make the exact decisions that the knowledge exists to inform. Maximum tacit reserve, maximum turnover exposure, maximum number of agents now acting without any of it. The gap was always there. AI turned it into a daily cost.
Externalizing the decision, not the person
You cannot make all of it explicit, and you should stop trying. What you can do is externalize the small, load-bearing slice that decides an outcome at a fork. Not the whole of a senior engineer's judgment, which is hopeless, but the specific decision it produced: this limit, for this reason, under this constraint. That is a subset small enough to actually capture and exactly the part the agent needs.
That is the job Brief does. It is a product navigator: it catches the tacit decisions at the moment they are made, the real limit and the real reason, the identity rule and the incident behind it, the constraint and who it protects, and it holds them in explicit, queryable form so the agent can read them at the fork. It does not try to write down everything a person knows. It externalizes the decisions that would otherwise stay locked in a head, and it puts them where the machine that never sat in the room can finally see them.
What this does and does not claim
A few limits, because the idea is stronger than any tool built on it. Polanyi's claim is that a genuine tacit dimension is permanent, so I am not claiming Brief, or anything else, makes all tacit knowledge explicit. That is impossible by Polanyi's own argument, and most of a person's expertise will always stay tacit. The narrower claim is the useful one: the decision-level knowledge an agent needs at a specific fork, the value and the reason for it, is a small externalizable subset, and capturing it changes what the agent builds. I am also not claiming documentation is worthless. It handles explicit knowledge well. The gap is the conversion of tacit judgment into an explicit decision, which ordinary docs are not built to do and mostly do not. And externalizing a decision is not the same as transferring the full judgment behind it, only enough of it to change the next choice, which turns out to be enough.
So the next time you are tempted to fix the context problem by writing more down, ask the harder question first. Of everything your team knows that would change what your agent builds, how much of it has anyone ever actually managed to say?
Frequently asked questions
What is tacit knowledge? Tacit knowledge is knowledge you have but cannot fully put into words, only demonstrate or apply, like riding a bicycle or recognizing a face. The chemist and philosopher Michael Polanyi introduced the term and summarized it as "we can know more than we can tell." It is distinct from explicit knowledge, which has been stated in words, numbers, or code, and it is distinct from knowledge that is merely undocumented, because a genuinely tacit part resists being written down at all.
Why does tacit knowledge matter for AI coding agents? Because a coding agent can only read explicit knowledge, the code, docs, schema, and ticket, while many of the decisions that matter live in the tacit knowledge of the team: why a limit is set where it is, why users are identified a certain way, why a module is off limits. That context never reached the agent, so it fills the gap with defaults and produces choices no one actually made.
Can you just write all tacit knowledge down to give it to the agent? No, and trying is the classic failure. Polanyi's argument is that a real tacit dimension is permanent, so some expertise cannot be fully stated no matter how much you document. Past attempts to write everything down, under the banner of knowledge management, are best known for producing stale wikis while the judgment that mattered stayed tacit and left with the people who held it.
How do you get tacit knowledge to a coding agent then? By externalizing the narrow, load-bearing slice rather than the whole. You do not capture all of a senior person's judgment, only the specific decisions it produces: this limit, for this reason, under this constraint. A product navigator like Brief exists to capture those decisions when they are made and hold them in explicit, queryable form, so the agent can read them at the moment it would otherwise guess.
← Back to Blog