Ask a general-purpose AI to write a specification for a load-bearing wall and it will produce something that looks like a specification: the right headings, the right categories of information, formatted the way specifications are formatted. Ask an architect to review it and they will tell you immediately that it was written by someone who has never stood on a building site.
The problem is not vocabulary. The problem is judgment. An architect knows which constraints matter in which contexts, what the failure modes are, what an inspector is actually looking for, which details are boilerplate and which require real attention. That judgment does not come from reading about architecture. It comes from doing it.
The question for anyone building AI systems for professional services is: how do you close that gap? The answer is not fine-tuning (expensive, slow, requires training data you probably do not have). It is knowledge embedding: giving the model the right context before it does anything.
The gap between generic and expert
The gap shows up in specific, predictable ways. Generic AI output in a professional context tends to:
- Use technically correct terms without understanding their practical weight
- Present all considerations as equally important when practitioners know they are not
- Describe what a document should contain without understanding why each element exists
- Miss the implied constraints that practitioners take for granted (regulatory context, common client concerns, known failure modes in the sector)
- Sound like a textbook summary rather than someone who has done the work
These are not hallucination problems. The model is not making things up. It is producing output that is accurate but shallow, because it is drawing on surface-level knowledge rather than practitioner knowledge.
The fix is not a better model. It is better context.
What domain knowledge actually is
Before you can embed domain knowledge, you need to be precise about what it actually consists of. It is not a list of facts. Professionals in any field carry several distinct types of knowledge simultaneously:
- Vocabulary with weight: Not just what terms mean, but which ones carry authority in which contexts, which are used internally versus with clients, which signal competence to a peer.
- Prioritisation frameworks: When multiple things are true, which ones matter most. In architecture: structural integrity over aesthetics, regulatory compliance over client preference, buildability over theoretical elegance.
- Contextual constraints: The background rules that govern every decision without being stated. Building regulations, standard practice in a specific region, what a structural engineer will and will not approve, what a planning officer typically objects to.
- Common failure modes: What goes wrong, how often, and why. This is often the most valuable knowledge and the hardest to find in any written source.
- Client communication patterns: How practitioners translate technical reality into language clients can act on. What gets explained and what gets handled without involving the client.
A knowledge document that captures all five of these is a fundamentally different input than a prompt that says "you are an expert architect."
The embedding approach
Knowledge embedding means writing a structured document that sits at the top of every system prompt and gives the model a practitioner's mental model before it handles any specific task. It is not a persona instruction ("act as an architect"). It is a briefing.
The distinction matters. A persona instruction tells the model to play a role. A knowledge document gives it the actual knowledge it needs to reason correctly. The model does not pretend to understand load calculations. It has enough context about how they work and what they are used for to handle them accurately in the tasks it is given.
This is the same approach that underlies the Camille AI Operating System: each client in that system has a detailed brief that embeds their business context, their audience, their sector, and their content history. The agents do not guess what the client's industry looks like. They are told, precisely, before they do anything.
Building the knowledge document
The structure I use for a knowledge document has five sections, corresponding to the five types of domain knowledge above:
1. Context and scope. What this professional does, in what contexts, for what clients. Not a Wikipedia summary. A description written from the inside: "An architect in a residential practice in the UK deals primarily with planning permission, building regulations approval, and contractor coordination. The client relationship is long (12 to 36 months per project) and the professional is accountable for both technical correctness and client experience throughout."
2. Vocabulary in use. The terms that appear in real work, with brief notes on how they are actually used. Include terms that look similar but mean different things in practice. Include terms that are used differently with clients versus with contractors or engineers.
3. Prioritisation rules. Explicit statements of what matters more than what. These should be written as rules, not suggestions: "Structural adequacy always takes precedence over aesthetic preference. Regulatory compliance is non-negotiable and should be stated as such, not framed as a recommendation."
4. Known constraints and failure modes. What is commonly misunderstood about this field. What clients typically get wrong. What tends to go wrong on projects and how practitioners handle it. What a professional in this field would never say, and why.
5. Communication register. How this practitioner writes and speaks. What level of technical detail goes into client-facing documents versus internal notes. What tone is standard in formal correspondence versus project meetings. Real examples where possible.
Layering context for specific tasks
The knowledge document is the base layer. For any specific task, you add a second layer of context: the project brief, the client profile, the specific constraints in play.
This layering is important. You are not trying to make one document that handles every possible architectural scenario. You are making a base that gives the model the practitioner's mental model, then adding task-specific context on top of it for each request.
In practice, this looks like:
[KNOWLEDGE DOCUMENT - always present]
You are operating in the context of an architecture practice.
The following describes how this practice works, what it prioritises,
and how it communicates...
[PROJECT CONTEXT - added per task]
Current project: residential extension, semi-detached house,
conservation area designation, client has planning approval,
currently at technical design stage...
[TASK]
Draft a pre-construction checklist for the contractor...The knowledge document handles the professional context. The project context handles the specific situation. The task instruction is then narrow and clear. Each layer does one job.
How this works in a real system
I built a system for a client in the built environment sector where the knowledge document was the result of three sessions with a senior practitioner: one to capture vocabulary and constraints, one to work through failure modes and common client misunderstandings, one to review the draft document against real project examples.
The output of those sessions was a document that took the model from producing technically accurate but shallow content to producing output that the practitioner described as "something a junior with two years of experience might write." That is exactly the target. Not to replace expert judgment. To produce a solid first draft that the expert can review and adjust, rather than write from scratch.
The time saving on document drafting was around 60%. More importantly, the review cycle shortened because the model was no longer producing content that required structural corrections: the domain framing was right, and the adjustments needed were at the level of detail and emphasis rather than substance.
The same approach sits at the core of the prompt engineering work I do across sectors. The specific knowledge changes. The method does not.
Where it breaks and what to watch for
Knowledge embedding has limits. It is important to know them:
- It does not substitute for real information. If the knowledge document says "planning authorities in this region typically accept X" and that is no longer true, the model will continue to operate on the old assumption. Knowledge documents need to be maintained as practice changes.
- It does not handle novel situations well. The document embeds what is known and common. When a project has unusual characteristics that fall outside the document's scope, the model may apply the wrong framework confidently. The review step is not optional.
- It can be too constraining. A very detailed knowledge document can prevent the model from surfacing useful ideas that fall outside the stated norms. Build in an explicit instruction to flag when standard practice may not apply.
- Context window limits apply. A long knowledge document plus a long project context plus a complex task can exceed what the model can handle effectively in a single prompt. For complex systems, this is a reason to split tasks across multiple calls rather than trying to fit everything into one.
None of these are reasons to avoid the approach. They are reasons to build it carefully and treat the knowledge document as a living specification, not a one-time piece of work.
If you work in a professional services business and you are evaluating whether AI tools can produce output that meets your quality standard, the answer is almost always yes, with the right knowledge architecture behind it. The Prompt Engineering service page covers what that architecture looks like as a structured build.