Your AI shouldn't start from zero every day.
Here is how most companies actually use AI: someone opens a chat window, types a question about their business, and gets an answer written for no business in particular. So they add background — who we are, what we sell, how our service works — and get something better. Tomorrow, a colleague opens a fresh window and starts the explanation over. The company's understanding of itself evaporates every night.
Then the conclusion gets drawn: AI isn't ready for real work. But the AI was never the problem. It was answering from zero context — and from zero context, the best possible answer is a generic one, delivered in confident language.
Effectiveness is a function of context
If you want AI to be effective in growing your business, it has to know you: your company, your goals, and the decisions you have already made. Not as a courtesy — as a working condition. An answer about "your key accounts" is only useful if the AI knows which accounts are key and why. A recommendation is only safe if it respects the policy you wrote last year and the direction you chose last month. Every piece of context the AI holds is a question you don't re-answer and a mistake it can't make.
What context design means
The fix isn't dumping your file server into a vector database and hoping. Context has to be designed: a structured, curated body of organisational knowledge, living where the AI works, maintained like the asset it is. In practice that means the company's identity and organisation map; its processes as they're actually run; its terminology, so words mean what your people mean by them; its policies; its KPI definitions; its decision log — and, crucially, the operating rules AI agents must follow when they touch your data. The context doesn't just describe the company. It sets the rules of the game.
One property separates a context you can run a business on from a pile of documents: managed certainty. Every statement carries its status — a confirmed fact, an assumption, or an item explicitly marked "to verify." The AI answers accordingly, and you always know what an answer stands on. A system that admits "this part is unverified" is worth ten that never do.
In medtech, this is non-negotiable
Any business benefits from context. Medtech cannot function without it. This is an industry with hard regulatory specifics — MDR compliance, data governance, mandatory traceability from LOT and expiry to serial numbers, periodic safety checks on devices — where an answer that ignores the traceability chain from client to device to activity isn't just wrong, it's a liability. And it's an endeavour where the end of every chain is a patient: the work saves and improves human lives. "Roughly right" is not a standard here. Context design is what makes AI answers respect the rules the industry runs on.
Live, not theoretical
This is now running at a real company. Days after the first demo, we loaded the complete organisational context of Imedex — the medtech distributor documenting its Healtek journey publicly — into their instance: 30 structured documents across 14 areas, from the organisation map and sales processes to MDR policies, KPI definitions and the rules for AI agents. It was deliberately the first AI functionality delivered on their journey — before any visible feature, because every feature builds on it. The details are in journey update #2.
Imedex calls itself a Technology Scout — its job is finding the world's best medical technologies and bringing them to clinicians. The context layer exists so the AI handles the operational memory, and the scouts can scout.
The prerequisite
Whatever your AI roadmap says — agents, automation, autonomous workflows — it rests on this: context design is the prerequisite of success in an AI-driven business. An AI without your context is a stranger with good manners. An AI with it is a colleague who was in the room for every decision. Start there.
Talk to us about designing your context →
Owner: Jan Safka · Healtek field notes, August 2026. The Imedex knowledge-base delivery is a real event (see journey update #2); the 30 documents / 14 areas figures are from the actual delivery. The rest is method.