Field note 04 / Knowledge systems
Beyond the Chatbot: Designing an Agent-Ready Knowledge System
What an AI assistant migration is teaching me about structured knowledge, specialized Skills, and human governance.
For a technical sales team, a fast answer is rarely just a convenience.
It can keep a discovery call moving, help an Account Executive respond confidently to a buyer, or prevent an unsupported technical promise from finding its way into a proposal. The questions often sound simple, but a dependable answer may require details scattered across product documentation, internal guidance, and the experience of technical specialists.
For us, Embrace demonstrated how valuable conversational access to that knowledge could be. It gave sellers a practical way to ask technical questions in the flow of work and receive useful answers without first knowing where the underlying information lived.
With that experience approaching its sunset in our environment, the immediate need was straightforward: find a new home for the workflow.
Should we simply replace the assistant, or should we reconsider the knowledge system underneath it?
That question has led me toward a different model—one that treats the AI assistant not as a layer placed on top of an existing knowledge base, but as one participant in a governed knowledge-production system.
Update / August 2026
The project has moved from a content workflow to a governed knowledge lifecycle.
Several pieces described below as future-state have now moved into the working architecture. Knowledge production and knowledge consumption are represented as intentionally separate systems.
A frontline Answer Engine retrieves from a constrained collection of curated knowledge. When an interaction exposes a potential gap, that signal can enter a separate workflow for review, investigation, drafting, and human validation before any new material becomes trusted guidance.
Answer Engine → Gap Signal → Reviewer → Queue → Knowledge Architect → SME / SE Review → Trusted Knowledge → Answer Engine
The system that answers a question should not automatically have the authority to decide what the organization believes is true.
I have left the original article below largely unchanged because it captures the earlier stage of the project—the assumptions I was testing before the broader lifecycle began taking shape.
See the current Answer Engine, gap-handling workflow, Queue, Knowledge Architect, and evaluation model.
01 / The hidden challenge
A knowledge base can work well for people and poorly for agents.
The first lesson was also the most important: content written for humans is not automatically good source material for an AI agent. That does not mean the existing knowledge is bad. It means it was designed for a different consumer.
People are remarkably good at compensating for inconsistent information architecture. An experienced Sales Engineer can scan a long article, recognize which paragraph carries the authoritative answer, distinguish an internal operational note from customer-facing guidance, and infer that a specification applies only to a particular product tier. An agent has to reconstruct those distinctions from the content it retrieves.
- The direct answer appears several paragraphs into a card.
- Important prerequisites are expressed indirectly.
- Internal implementation detail is mixed with seller-ready guidance.
- Old and current guidance remain plausible without clear authority markers.
Formatting is not just a presentation choice. Once an agent becomes a primary consumer, structure becomes part of the system architecture.
The same knowledge / two consumers
Human-readable vs. agent-ready
02 / The content model
Designing a second knowledge layer for retrieval.
My goal is not to replace every human-readable article with terse, machine-oriented content. People still need explanations, background, examples, and narrative context.
Instead, I am exploring an agent-ready layer derived from the knowledge we already trust. Each unit should make the most important distinctions explicit enough that both an agent and a human reviewer can evaluate them quickly.
Can a managed platform support a custom runtime extension?
Bottom-line answer
Support depends on the extension, service tier, and whether the platform team can safely maintain it.
Requirements + specifications
Confirm the approved extension list, runtime version, ownership model, and deployment path.
Boundaries
Do not promise support until compatibility and operational ownership have been verified.
Customer-safe talk track
“We can evaluate the requested extension against your architecture and confirm the supported path.”
Agent-ready knowledge card template
A clean Markdown starting point for answers, requirements, boundaries, talk tracks, sources, and review state.
03 / Specialized behavior
One Agent, two specialized Skills.
The workflow I have started building uses one Guru Knowledge Agent with two specialized Skills: one for research and one for drafting. Specialization is more valuable here than a single broad prompt.
Research
Find relevant source material, identify conflicts, filter operational chatter, preserve qualifications, and surface unresolved questions. The output is evidence—not a finished answer.
- Sources + authority
- Agreements + contradictions
- Internal-only detail
- Open SME questions
Drafting
Transform researched material into the standard card anatomy without inventing facts. The output is consistent and usable—but explicitly unpublished.
- Bottom-line answer
- Requirements + boundaries
- Customer-safe language
- Review metadata
Today, these are two controlled modes within one Agent and an intentionally supervised workflow. I am not treating them as an autonomous pipeline that can silently research, approve, and publish content end to end.
04 / Assigning authority
The human validation gate is part of the architecture.
It is tempting to view human review as a temporary safeguard—something to remove once the prompts become reliable enough. I see it differently.
AI can propose knowledge. A qualified human approves what the organization is prepared to trust.
The Agent can gather related material, normalize terminology, identify gaps, structure the answer, surface technical caveats, and prepare language for a seller. But an expert must still confirm that the source is current, that requirements and boundaries are complete, that internal context has not become an external commitment, and that the customer-safe language is genuinely safe.
05 / The intended system
The longer-term model: production and consumption.
The intended destination separates knowledge production from knowledge consumption. The production workflow is skeptical, detailed, and designed for knowledge managers and technical experts. The retrieval experience is concise, direct, and constrained to approved guidance for frontline sellers.
- 01Answer EngineBounded retrieval↓
- 02Gap signalPotential missing knowledge↓
- 03ReviewerQualify the gap↓
- 04The QueueExplicit knowledge work↓
- 05Knowledge ArchitectResearch + structured draft↓
- 06SME / SE reviewHuman authority↓
- 07Trusted knowledgeApproved collection↓
- 08Answer EngineImproved retrieval
The next insufficient answer becomes another potential knowledge signal.
This was the intended destination when I wrote the original note. The project has since progressed into an active closed-loop design with a constrained Answer Engine, explicit gap handling, a review Queue, a broader Knowledge Architect workflow, and human approval before proposed knowledge enters the trusted retrieval layer.
Addendum / What changed after the original Field Note
From content generation to the complete knowledge lifecycle.
My first implementation work focused heavily on production: source material → research → drafting → human review → verified knowledge. That remains important, but it solves only half of the problem.
The system became more interesting once frontline retrieval began feeding information back into knowledge production. The architecture now separates an Answer Engine grounded in a constrained collection, a gap-detection and review layer, a Queue that turns transient conversations into explicit work, a broader Knowledge Architect, and a human validation boundary.
The Answer Engine has less context and less authority because its job is to answer safely and quickly. The Knowledge Architect has broader context because its job is to investigate ambiguity. Neither gets to assign organizational truth by itself.
The evaluation question changed too.
- Does the Answer Engine retrieve authoritative knowledge and preserve its qualifications?
- Does the system abstain when the trusted collection is insufficient?
- Can a failed interaction identify a reusable knowledge gap?
- Can the production workflow resolve that gap without unsupported claims?
- Can a human reviewer validate the proposed change efficiently?
- Does the approved knowledge measurably improve the next retrieval?
Good enterprise AI is a system for deciding what context the model receives, where uncertainty is exposed, who holds authority, and how real usage improves what the system knows next.
06 / Early practitioner lessons
What I am learning so far.
Migrating the interface is the easy part.
A platform transition is a rare opportunity to inspect the deeper system rather than simply moving it.
Knowledge architecture is Agent architecture.
Prompt design cannot permanently compensate for ambiguous source material, terminology, authority, or review state.
Creation and retrieval need different behaviors.
One workflow should expose uncertainty; the other should be concise and constrained to approved guidance.
Skills create specialization without unnecessary Agent sprawl.
Distinct research and drafting behaviors create cleaner contracts while keeping related knowledge work together.
Governance cannot be bolted on at the end.
Sources, ownership, review state, and boundaries have to be represented throughout the workflow.
Human-readable and agent-ready knowledge can coexist.
Narrative helps people learn; structure helps retrieval systems answer predictably.