Your agents can read your data. They can't reach the rules that actually run the company, because nobody ever wrote them down.*
Last quarter a mid-market software company gave its new RevOps agent access to the warehouse, the CRM, and a clean set of metrics. Good data, well modeled. Two weeks in, the agent flagged a Nordic account for a standard net-30 renewal and started the dunning sequence. The account was on net-60. It had been on net-60 since 2023, because the founder cut that deal personally to land them, and the only place that fact lived was in his head and one Slack thread nobody could find. The agent did everything right with the data it had. The data it had was never the problem.
This is the part of "company knowledge" that no warehouse holds. The definitions are the easy half. The hard half is the rules, the history, and the judgment that make your company run, and almost none of it is written down anywhere an agent can read.
Why your agents can't reach it
There is one disease underneath this, and it shows up the same way every time: your company isn't written down anywhere an AI can read it. The data is. The meaning and the rules are not.
Think about where company knowledge actually lives. Some of it is in dbt and the warehouse, which is the part agents handle fine. Most of it is somewhere else. The renewal logic lives in a sales leader's head. The reason a given account gets a discount lives in a two-year-old Slack thread and the memory of an account executive who left in March. Which customers are politically sensitive, and why, is something everyone on the team knows and nobody has ever typed out. This is institutional knowledge, and it is the knowledge that makes the difference between an answer that is technically correct and an answer that is right for your company.
It is not only the revenue side, and that is the part worth sitting with, because it means no single integration fixes it. A support agent at the same company told an enterprise customer they were covered by the standard 30-day refund window. They were not. Enterprise contracts there are non-refundable, a term negotiated deal by deal and written into the order form, not the help center. The agent quoted the public policy because the public policy was the only version it could reach. Finance has its own copy of the problem: the FP&A agent reported committed revenue for a board deck and counted two deals sales had verbally closed but legal had not countersigned, because the rule that nothing counts until countersignature lived in the RevOps lead's head and in no column anywhere. Customer terms, support policy, revenue recognition. Same disease, three departments, and the warehouse holds none of the rules that decide the right answer.
A model cannot infer any of it, and this is the part teams underestimate. A handshake deal from 2023 is not a faint signal that a better model or more training data would eventually surface. It is a decision a person made once, in a room, that left no trace in any dataset. There is nothing to learn from, because the fact was never recorded as data in the first place. And even where the knowledge does exist in writing, in a contract clause or a Slack thread, the agent cannot reach it at the moment it answers unless something deliberately put it somewhere queryable. Inference happens in a split second against whatever the tool can see, and the order form in a folder is not in that set. So the agent fills the gap the only way it can, by guessing, and the guess is confident and wrong.
The obvious fix is "put it in the wiki," and most companies have tried. It does not hold for three reasons. First, the unwritten rules are unwritten precisely because they live in the flow of work, not in a document someone sat down to author. Second, a wiki is built for a person to open and read, not for an agent to query at the moment it answers. Third, even when the knowledge is in the wiki, it goes stale within weeks, carries no authority, and cannot be filtered by who is allowed to see it. RAG over the wiki inherits all three problems. You get an agent that retrieves a paragraph someone wrote eighteen months ago and treats it as current truth.
Then there is the tax you pay for all of this more than once. You spend six weeks getting ChatGPT to understand the business. Then Cursor needs the same context. Then the support agent. Then the next tool. Every one of them starts at zero, and the explanations you give each one drift apart over time until no two agents agree on how the company works. The knowledge never compounds, because it never has a home.
What fixing it looks like
Making your AI understand the business means giving the company knowledge a place to live that an agent can actually read, with an owner and a date attached so it stays trustworthy. That is what a context layer is, and it is the thing Sento builds.
It starts with capture, because the hardest knowledge is the unwritten kind. Sento's Knowledge Capture surface is a lightweight way for the people who hold that knowledge, the sales lead, the account manager, the ops person, to encode it without learning a data tool. The net-60 deal, the discount rule, the sensitive accounts, typed once by the person who knows them, with a review queue so the data team curates what becomes canonical. This is the surface a data catalog never had, because catalogs were built to document tables, not to capture the judgment in someone's head.
Captured knowledge lands in the Context Catalog, where it becomes a governed fact rather than a note. Each entry has an owner and a last-validated date, so when the renewal terms change, the change has a place to happen and everyone reading from it sees the new version. Nothing in the catalog is authored from a blank page. Sento self-seeds a first draft from the tools you already run, the warehouse, dbt, Notion, Slack, and the people confirm and correct it. Confirming is a different job than authoring, and it is the difference between a context layer a small team keeps current and one that goes stale in a month.
From there the MCP Server does the part that makes it pay off across every tool at once. Any AI tool you run queries the same source at inference, filtered by who is asking and what they are allowed to see. The new tool you add next quarter inherits everything the company has already written down on day one, instead of starting at zero like the last four did. And because every resolution is logged through Lineage and Audit, when an agent acts on the net-60 rule you can trace the answer back to the captured fact and the person who owns it. Customer knowledge is the example here because it is the messiest, but the same layer holds finance rules, product logic, and anything else your agents need to get right.
What this changes
The RevOps agent from the top of this page does not flag the Nordic account, because the net-60 term is a governed fact it reads at inference, not a guess. The next agent you deploy knows it too, without a six-week re-teach. And when leadership asks why the agent did what it did, the answer traces to a source instead of a shrug. That is the difference between AI that demos well and AI you can put in front of a customer.
Your AI doesn't know your company. Sento fixes that.
