Connected knowledge: putting your firm's work behind AI
5 minutes read
AI that only knows what a public model was trained on writes generic drafts. Connected knowledge is how you make it work from what your firm actually knows.
Connected knowledge means the AI works from what your firm actually knows: its prior work, its methods, the external sources it trusts, and, where an engagement permits, the client's own material. Without it, the AI only has what a public model absorbed in training, which is why generic drafts read generic. With it, the work is grounded in your firm's real context.
For an expert service firm, this is often the difference between AI that produces a plausible essay and AI that produces something recognisably yours. Your value is not that you can write. It is what you know and how you apply it. Connected knowledge is how that gets into the work.
Why a public model alone writes generic work
A public model writes generic work because it only knows what was in its training data, and that stops at your firm's front door. It has never seen your last thirty engagements, your house methodology, the way your team frames a particular kind of problem, or the specific material this client handed you. So it fills the gap with the average of everything it has read, which is the definition of generic.
You can feel this in the output. The draft is competent and could have been written for any client in your sector. The senior person then spends their time putting back the specific knowledge that makes it a firm's work rather than a template. Connected knowledge moves that knowledge to the front of the process instead of the reviewer's desk at the end.
The four sources of connected knowledge
Connected knowledge pulls from four places, and a good setup uses all of them under clear rules.
| Source | What it adds | Access consideration |
|---|---|---|
| Your prior work | Real examples of how the firm has solved this before | Available to the people permitted to see it |
| Your methods | The firm's way of framing and doing the work | Shared across the team so quality is consistent |
| Approved external sources | Trusted outside material, not the open web by default | Chosen deliberately for the kind of work |
| Permitted client material | This engagement's specific context | Used only where the engagement allows it |
The first two are what make the work sound like your firm. The third keeps external claims grounded in sources you trust. The fourth is what makes a draft about this client rather than a generic one. Approved sources get their own treatment in the reliable AI client work guide, since they are also the backbone of a reviewable draft.
Connecting your stack and data
Connected knowledge also means connecting to the tools and data your firm already uses, so the work draws on your real material rather than a copy someone pasted in. The framing that matters here is not how many integrations exist. It is that Hebno connects to the specific tools your firm works in and uses them under the access rules those tools already have. Someone who cannot see a document in your document store does not suddenly see it through Hebno.
That last point is the one to hold onto. Connecting knowledge is not the same as flattening permissions. The right setup respects the access boundaries your firm already runs, so each person sees only what they are meant to. The security guide covers how those boundaries are enforced.
Connected knowledge is not a document search box
A knowledge-management tool stores and retrieves documents. Connected knowledge is different: it is not about finding a file, it is about the AI using selected knowledge to do a piece of client work and produce a reviewable draft. Retrieval is a step inside that, not the product.
This distinction matters when you evaluate tools. A search box that returns your documents is useful, but it still leaves the whole job of turning knowledge into a deliverable on the person. Connected knowledge feeds the drafting itself, so the firm's context is in the work from the start.
How to set it up
Start narrow and expand. Pick one kind of work your firm does often. Assemble its connected knowledge: a few strong examples of prior work, the method you use for it, the external sources you trust, and the client material the engagement permits. Run a real brief through it and compare the draft to what a generic prompt produces. The difference is usually obvious, and it tells you which knowledge is worth connecting next.
You do not need an engineer for this. Connecting your knowledge and stack is setup work the person who owns delivery can do, not an IT project.
