Will a better model fix this?

No. A frontier model already knows more about your industry than a new hire will after a year. What it does not know is that your pricing changed in March or that one account has been escalating for a month, because that is state living in your systems rather than knowledge in the model. A better model reasons better about whatever it was given; it does not get given more.

Is this what fine-tuning is for?

Fine-tuning changes how a model writes and reasons, not what it currently knows about your business. Company facts change weekly, and retraining on each change is neither practical nor reversible. The fix is to give the model somewhere current to read from at the moment of the question.

We wrote everything down already. Why is it still wrong?

Because writing it down once solves the first day and none of the days after it. A document describing a process is accurate until the process changes, which nobody flags, so it becomes a confident record of how things used to work and people keep trusting it. Staleness is the second of the three failures and is structural rather than a discipline problem.

Why your AI does not know your company

30 August 2026Julien FrècheCo-founder, Tulina

Ask any capable assistant a question about your own company and watch what happens. It answers confidently, in the register of someone who knows, and it is wrong in a way that takes you longer to spot than a blank stare would have. Not because the model is weak. Because nothing it can reach contains the answer.

This is the problem a company brain exists to solve, and it is worth being precise about, because "the AI doesn't know our stuff" is three different failures wearing the same coat. They have different causes and different fixes, and a team that treats them as one thing usually buys a tool for the wrong one.

The gap is not the model

The instinct is to reach for a better model, or for fine-tuning. Both are answers to a question nobody asked. A frontier model already knows more about your industry than most of your new hires will in a year. What it does not know is that your pricing changed in March, that the "Enterprise" tier in the deck is called something else in the billing system, that this particular account has been escalating for a month, and that the person who would have told you all three left in June.

None of that is knowledge in the model's sense. It is state. It changes, it has a source, it has a date, and it lives in systems the model has never been introduced to. Improving the model does not move it an inch closer.

Three failures, not one

It starts from nothing. Every conversation opens at zero. The person at the keyboard pastes in the same background they pasted in yesterday, and whatever they forget to paste is the part the answer will be wrong about. Multiply by everyone on the team and it is a real, daily tax that nobody has ever put on a budget line.

It goes stale. The companies that saw this coming wrote it all down. Then the quarter turned, three processes changed, and the document that was going to fix everything became a confident record of how things used to work, which is worse than nothing because people still trust it. This is structural, not a discipline problem: keeping a written account true is permanent work with no deadline attached, which means it is always someone's fourth priority.

It never left anyone's head. The largest part was never written anywhere. It is the reason a deal is really stuck, the exception that applies to one customer, the step everyone knows to skip. It transfers by sitting next to someone, which is why it does not survive a reorg and cannot be pasted into a chat window.

The failure	What it looks like	Why writing more documentation does not fix it
Starts from zero	The same briefing pasted at the top of every chat, by every person, every day	The briefing is written from memory, so it carries whatever the writer happened to recall that morning
Goes stale	A page that describes last quarter's process with total confidence	Keeping it true is permanent work with no deadline, which makes it everyone's fourth priority
Never written	The reason a deal is really stuck; the exception that applies to one account	It transfers by working alongside someone. There is no document because nobody ever had a reason to write one

Those three are worth reading in that order, because each one is the previous one's excuse. The context starts from zero because it was never written; it was never written because writing it has never stayed true for long. The third has a name outside software: tacit knowledge, the kind that is understood without being stated, and the reason handovers take months rather than an afternoon.

FIG. 01 How company knowledge is actually held: a system per function, each authoritative about its own slice, none of them holding the account of how the company works. The dashed runs are the connections people make in their heads, and the ring is the thing nobody built.

Why it got urgent

None of this is new. Organizational memory has been studied for decades, and companies have operated on scattered knowledge and undocumented habit for as long as there have been companies. It worked because the mechanism for retrieving it was a person asking another person. That mechanism is slow, but it is very good: people know who to ask, they hedge when they are unsure, and they say "that changed last month".

What changed is that a second kind of worker arrived, one that cannot walk over and ask. An assistant has no colleague to check with and no instinct that something smells out of date. It will answer from whatever it was given, at full confidence, every time — the failure mode the field calls hallucination, and the reason a confident wrong answer costs more than a blank one. So a gap that a company could carry indefinitely while only humans worked from it becomes, the moment AI is doing the work, the thing that decides whether the output is usable.

FIG. 02 Why the same gap became urgent. A person who does not know goes and asks, and comes back with the answer and a caveat; the loop closes. An assistant has no colleague to check with, so the return leg is missing and it answers from whatever it was given, at full confidence.

What to do about it

The three failures are one problem seen from three angles, and they do not get fixed by trying harder at the thing that is not working: not a better model, not another round of documentation, not a rule that everyone should write more down. They get fixed by deriving the account from the systems that already hold the evidence, and by keeping it current as a property of the system rather than as somebody's fourth priority.

That is the whole argument for building something deliberate rather than continuing to paste. Once the shape of the answer is clear, the next question is what it takes to build one, which is how to build a company brain. If you are weighing it against a tool you already pay for, start instead with a company brain compared with what you already have.

Common questions

Will a better model fix this?: No. A frontier model already knows more about your industry than a new hire will after a year. What it does not know is that your pricing changed in March or that one account has been escalating for a month, because that is state living in your systems rather than knowledge in the model. A better model reasons better about whatever it was given; it does not get given more.
Is this what fine-tuning is for?: Fine-tuning changes how a model writes and reasons, not what it currently knows about your business. Company facts change weekly, and retraining on each change is neither practical nor reversible. The fix is to give the model somewhere current to read from at the moment of the question.
We wrote everything down already. Why is it still wrong?: Because writing it down once solves the first day and none of the days after it. A document describing a process is accurate until the process changes, which nobody flags, so it becomes a confident record of how things used to work and people keep trusting it. Staleness is the second of the three failures and is structural rather than a discipline problem.

WHY TULINA

Those three failures are what Tulina was built to close.

It reads across the tools your company already runs and keeps one current account of how you operate, so nothing has to be re-explained, nothing quietly goes stale, and what only lived in someone's head gets written down as a side effect of the work.

Set up in an afternoon: Your first context layer gets built on the intro call, from two of your real tools. There is no project to staff before anything is worth reading.
Shared, not re-explained: One person connects a tool and the whole team works from it, with access following roles rather than who happened to be in the thread. That is the third failure, closed.
Your AI gets better at your company: Every session starts from a distilled brief instead of a pasted one, so answers follow your definitions and your process rather than the model's best guess about them.

Calls