Most companies now have generative AI tools connected to some part of their work. Far fewer have noticed those tools getting better at understanding the company specifically, rather than staying competent only in general. This piece argues the gap has a structural cause. Companies have spent years writing down their explicit knowledge: policies, decks, wikis, playbooks. Their tacit knowledge, the judgment calls, corrections, and precedent that actually get work done, stays scattered across chat threads and people's memory. A system that only sees the explicit layer produces generic, competent output. One with access to the tacit layer too, connected to the work that produced it, starts to behave like it understands your company. What follows is a conceptual framework for why that connection matters, grounded in how Core, Gradien's product, is built, not a report of results from an external study.
This piece asks what actually makes an AI system useful to one specific company.
Ask a team using ChatGPT, Claude, or Cursor whether the tool understands their company, and the honest answer is usually a qualified yes. It understands the company's public materials, maybe a pasted style guide, maybe a summary someone wrote once. What it almost never understands is why the team made the decisions it made: why an onboarding flow changed in March, why a vendor got dropped, why one client contact always needs pricing language softened. None of that lives in a document. It lives in the work itself, in corrections given during review, in the gap between what was planned and what shipped. The question here is narrow. Does capturing only explicit knowledge produce a lesser kind of AI usefulness than capturing explicit and tacit knowledge together, connected to the workpath that produced it?
This question matters because most AI programs are optimizing the wrong half of the problem.
When a company tries to make its AI tools more useful, the default move is to feed them more documents: the wiki, the brand guide, the onboarding deck, the last several strategy memos. This helps, and it hits a ceiling quickly, because most of what makes a team's output distinctive was never written down. It was worked out in the moment: a founder's correction to a draft, an engineer's explanation of why a shortcut is fine here but not there, an account manager remembering that one client dislikes one specific word. A system drawing only on the explicit layer keeps producing the same generic version of good work, because the documents were never where the company's real judgment lived.
A company's operating knowledge lives on two connected layers, not one.
Explicit knowledge is what a company has actually written down and would recognize as documentation: policies, templates, decks, wikis, style guides. It is necessary, and it is also, by definition, only the part of the company's knowledge someone already had time to formalize. Tacit knowledge is everything else: judgment calls made under time pressure, corrections a manager gives on a draft, precedent set by how a similar situation got resolved before, the unwritten reasons one approach is preferred over another. Tacit knowledge is usually larger than explicit knowledge, and almost always more current, because it is produced continuously, in the act of doing the work, rather than in a separate act of writing it down afterward.
Workpaths are the connective tissue between an isolated fact and real institutional memory.
A workpath is not a task list and not a project plan. It is the record of what actually happened: which draft came first, what got corrected and by whom, which version a client approved, which decision reversed an earlier one and why. Tacit knowledge without a workpath is a floating fact, something like use softer pricing language with this client, with no context for when it applies or why it exists. Attached to a workpath, that same fact becomes closer to institutional memory: a specific correction, made at a specific point in a specific project, by a specific person, that a system can later recognize as relevant when a similar situation comes up again.
Explicit knowledge tells an AI system what your company says about itself. Tacit knowledge, connected to its workpath, tells it how your company actually decides.
A knowledge graph only becomes proprietary once it is linked to the workpaths that generated it.
A knowledge graph is the structure that holds a company's facts, entities, and relationships: this client, this project, this decision, this person, and how they connect. On its own, a graph built only from documents is organized explicit knowledge, something a competitor with similar public materials could largely reconstruct. It becomes harder to replicate once its nodes carry the tacit layer too, specifically the tacit knowledge that stays attached to the workpath it came from. A single correction to a launch brief is one data point. That same correction, made on the brief's third revision, after a similar approach had already been rejected by the same client, has enough structure to be genuinely useful the next time a similar brief comes up.
- Information: the facts a task actually used, not just what got filed somewhere.
- Decisions: what was chosen, and as closely as the record allows, why.
- Preferences: standing judgment calls, like a client's expected tone or an unwritten house rule.
- Corrections and outcomes: what was wrong in an earlier attempt, what fixed it, and what happened next.
None of this is useful if a system updates what it knows about a company without anyone checking it first. Captured information is proposed as a candidate update, reviewed by a person, and only added to what the system draws on once approved. That step keeps a growing base of company knowledge trustworthy rather than just large, and it is also why this is not the same thing as retraining a model on company data. The model stays as it is. What changes is the context it is given before it answers.
Disconnected context and workpaths quietly reset a team's intelligence to zero.
Consider a product launch team at a company like Northstar, working with a client like Meridian Labs. Maya drafts positioning, Jordan manages the client relationship, Alex runs technical scope. Over a few months, small corrections accumulate: which claims Meridian Labs's legal reviewers always flag, which details Alex has learned to over-explain because they got misread once, which draft structure earns a fast approval from Jordan's contact. None of it sits in a document anywhere. If each of them opens a different AI tool for a different piece of the work, and none of those tools share what happened in the others, the team spends its time re-deriving judgment calls it already made once. The system does not fail loudly. It simply never gets better than its first week, no matter how long the team keeps using it.
This is the architecture Core is built around.
Core is Gradien's context and operating-continuity layer. It sits underneath the AI surfaces a team already uses, including ChatGPT, Claude, Cursor, Codex, and Claude Code, and captures both layers described here: the explicit knowledge a company has written down, and the tacit knowledge produced as work happens, connected to the workpath each piece came from. When someone moves from one surface to another mid-project, the relevant context moves with them instead of resetting. Updates to what Core treats as established company knowledge go through human approval, not automatically. Core does not retrain or fine-tune any model, and it is not a chatbot in its own right. It is the layer that lets whichever AI surface a person is already using respond as though it has been on the team longer than it actually has.
This framework describes an architecture, not a guarantee.
A few limits are worth stating plainly. This is a conceptual model grounded in how Core is built, not a record of measured outcomes across companies. Capturing tacit knowledge also depends on work happening somewhere a system can observe it. A decision worked out in a hallway conversation or an unrecorded call stays tacit until someone writes it down or brings it into a connected surface. And connecting context to workpaths increases the value of what gets captured without removing the need for human judgment: the approval step exists precisely because not every correction generalizes, and a team still has to decide what counts as a durable preference rather than a one-time exception. A connected system makes good judgment easier to apply consistently. It does not replace it.
- What Is Core
- Why Core Matters
- How to Stop Re-Briefing AI Tools