Build or Buy an Agent Knowledge Layer: Cost and Ontology Tradeoffs
Build a comparable three-year cost model for an agent knowledge layer, define upkeep responsibilities, and evaluate explicit document relations against formal ontology requirements.
Choosing an agent knowledge layer means choosing who will operate ingestion, permissions, retrieval, review and recovery over time. Compare custom development, self-hosted licensed software, managed services and hybrid arrangements against the same requirements. A low infrastructure bill is useful only if the resulting system supports the workflow and has accountable owners.
Key takeaways
- Compare equivalent source coverage, security, quality, interfaces and recovery requirements before comparing cost.
- Model implementation, recurring work and change or exit costs separately. Show assumptions instead of inventing industry savings figures.
- Controlled vocabulary, explicit relationships, formal ontology reasoning and validation solve different problems.
- Test shared evidence through both human UI/API workflows and agent MCP clients.
- Include curation and migration effort in the decision; neither building nor buying removes that work automatically.
Compare operating models at the same scope
A wiki, search index, ontology platform and agent knowledge layer may contribute different capabilities to a solution. Comparing their subscription prices alone does not establish which option meets the enterprise requirement.
| Operating model | Work to price and assign |
|---|---|
| Custom build | Component integration, application behavior, evaluation, infrastructure and ongoing maintenance |
| Self-hosted licensed software | License terms, deployment, upgrades, infrastructure, integration and internal operations |
| Managed service | Subscription and usage, configuration, source integration, internal review and contractual service boundaries |
| Hybrid | Responsibilities split across services, plus synchronization, identity and incident coordination |
For every option, specify sources and file types, expected update volume, user and agent identities, permitted actions, interfaces, evidence quality, retention, recovery objectives and support coverage. Reject options that fail mandatory requirements or price the additional work needed to satisfy them. Do not assume a managed service includes every connector, or that a custom build must implement every component from scratch.
Use a transparent 36-month cost model
A practical planning formula is:
36-month TCO = initial setup + sum of monthly recurring costs for months 1–36 + planned change and exit costs.
Use one currency, the same scope and a stated treatment of tax, inflation and discounting. Include recurring software, infrastructure, storage, network, model usage, support and internal labor. Keep failure and retry costs within those categories rather than counting them again as a separate total.
The following is an entirely hypothetical, undiscounted nominal example. It is not a vendor quote, measured deployment, industry benchmark or recommendation. The numbers illustrate arithmetic only; replace them with current quotes and measured workload assumptions.
| Cost element | Option A | Option B |
|---|---|---|
| Initial setup | $40,000 | $20,000 |
| Monthly recurring cost | $6,000 | $7,000 |
| Recurring cost over 36 months | $216,000 | $252,000 |
| Planned change and exit | $15,000 | $10,000 |
| Total | $271,000 | $282,000 |
Option A totals $40,000 + 36 × $6,000 + $15,000. Option B totals $20,000 + 36 × $7,000 + $10,000. Their illustrative difference is $11,000. An additional $1,000 each month changes a 36-month total by $36,000, enough to reverse the apparent ranking in this example. A cost difference is meaningful only after both options meet the required service and quality levels.
Measure labor instead of assuming it disappears
For each role, estimate allocated hours multiplied by its fully loaded hourly cost. Separate setup from recurring work and distinguish internal resource consumption from incremental cash spending. Avoid double-counting labor already included in a vendor service or an infrastructure allocation.
Populate a worksheet with real owners, measured workloads, current rates and source dates.
| Work category | Owner | Evidence and date | Low/base/high hours | Loaded rate |
|---|---|---|---|---|
| Connectors, parsing and ingestion | To assign | To measure | To estimate | To confirm |
| Identity mapping and revocation tests | To assign | To measure | To estimate | To confirm |
| Content review and terminology | To assign | To measure | To estimate | To confirm |
| Retrieval and answer evaluation | To assign | To measure | To estimate | To confirm |
| Backups, upgrades and incidents | To assign | To measure | To estimate | To confirm |
| Migration and exit rehearsal | To assign | To measure | To estimate | To confirm |
Calculate low, base and high scenarios from workload assumptions such as source changes, query demand, document complexity and review backlog. Record uncertainty and the date of each quote. A managed vector backend may shift index operations to a provider; it does not automatically include embedding inference, source synchronization, permission administration or recovery of the whole application.
Choose the necessary level of semantic modeling
Start with the questions the workflow must answer. A controlled vocabulary can standardize labels. Explicit document relationships can connect evidence. A formal ontology can define classes and properties with specified semantics. Validation rules can check data constraints. These are related choices, not interchangeable capabilities.
The W3C SKOS Primer describes concepts, labels and relationships for knowledge organization. The W3C OWL 2 Overview describes a formal ontology language. Whether a product supports the required reasoning or validation depends on its implementation and configuration; a graph database alone does not establish that behavior.
Consider a hypothetical “active customer” definition. Sales might mean an organization with an active contract, while Support might mean an account with a recent support interaction. Preserve each definition's domain, owner and effective period. Matching labels do not prove that the definitions or underlying entities are equivalent. A useful workflow can surface both meanings and ask for context rather than overwrite one with the other.
Price the work needed to maintain terminology, mappings and rules as sources change. A bounded vocabulary and explicit relationships may be sufficient for one use case. Formal reasoning may be justified for another. Neither requires an unsupported claim that enterprise-wide ontology adoption is always necessary or always unsuccessful.
Evaluate AKB within verified product boundaries
The AKB public repository describes documents, tables, files, explicit relationships, retrieval and document history. Evaluate these as shared evidence capabilities for human UI/API workflows and agent access through MCP. Document revision history should not be generalized into line-by-line history for every table or binary attachment. Explicit relationships should not be presented as proof of an automatic OWL reasoner or entity-resolution engine.
Separate Core from optional Collector and Gardener workflows. Verify capabilities and packaging for the selected release, and assign source integration, review and operations to named owners. Product direction or optional tooling is not evidence that every deployment includes a finished workflow.
Check the release-specific AKB license alongside any commercial quote. BSL 1.1 is source-available. The Additional Use Grant permits production use below 100 aggregated Named Seats as defined in the license. At or above 100, or for third-party hosted, embedded or rebranded offerings regardless of seat count, a separate commercial license is required. Use the license's aggregation and user definitions, not company headcount or concurrent-user guesses.
Assign governance work and measure its cost
The source owner maintains authoritative content. The platform operator handles the deployment. A domain reviewer resolves material content or terminology questions. The security owner defines identity and access requirements. The application owner evaluates the resulting user workflow. One person may hold several roles, but the responsibilities should remain explicit.
Automation can perform routine ingestion or formatting under policy. Material corrections and changes to approved knowledge need the review controls appropriate to their risk, including the source evidence and exact revision being approved. Recheck a proposal when its base content changes rather than treating an earlier approval as approval of different material.
Measure source-to-search lag with defined start and end events, p50 and p95, plus pending or failed updates. Track review backlog age, including the oldest pending item, and actual weekly review hours. Keep retrieval relevance, answer correctness and citation support as separate metrics with stated denominators.
For security testing, count actual unauthorized disclosures over unauthorized attempts and target zero disclosures within the test scope. Correctly blocked requests are successful outcomes. Evaluate revocation against a declared propagation target across human and agent paths, including snippets, relationship metadata, caches and derived content. Do not assume all paths update immediately.
Price an exit you have rehearsed
Define the export scope: content, identifiers, relationships, source references, permissions, binary files and retained history. Restore a sample into an independent environment, compare record counts and relationships, and repeat representative retrieval and access tests. A readable interchange format does not guarantee a lossless migration, a complete backup or equivalent permission semantics.
Include adapter changes, downtime, transfer and retention costs, and any required parsing, re-indexing or re-embedding. Do not assume every migration requires complete re-embedding; determine that from the destination, retained vectors and model compatibility. Conversely, do not assume an index can always be reconstructed without the source data, configuration or additional model work.
Use a bounded pilot to revise the decision
Choose one workflow with real documents, owners and permission cases. Exercise both a human UI/API path and an agent MCP path against the same authorized evidence. Test source updates, conflicting information, denied access, revocation, concurrent writes, retry behavior and a recovery drill. Record the operating hours and failed work as well as successful answers.
Use these observations to revise the cost model and identify unresolved responsibilities. Choose the option that meets the requirements with an acceptable operating burden and uncertainty. A default database choice or an existing wiki subscription does not decide the outcome by itself.
Frequently asked questions
How do wikis, ontology platforms and knowledge layers differ?
They emphasize different workflows: content authoring, semantic modeling, or shared evidence and retrieval. Capabilities overlap. Evaluate the actual product and required integrations rather than assuming every ontology platform includes formal reasoning or every wiki lacks agent access.
How should 36-month TCO be calculated?
Add setup, all monthly recurring costs and planned change or exit work using the same scope and assumptions. Include internal labor and sensitivity analysis. Treat illustrative numbers as examples until supported by quotes or measurements.
Do explicit AKB relationships imply formal ontology reasoning?
No. Explicit links can provide useful context without establishing OWL reasoning, automated entity equivalence or an enterprise-wide ontology requirement.
What matters in AKB licensing?
Use the current release's BSL 1.1 terms and Additional Use Grant, including aggregated Named Seats and third-party offering conditions. Confirm commercial terms for the intended deployment instead of inferring them from total employee count.
What should the pilot prove?
That the required human and agent workflows can use correct, authorized evidence with measurable update, recovery and review behavior—and that the organization understands the work and costs required to sustain them.
Explore shared enterprise knowledge with AKB
Evaluate AKB against your evidence, governance requirements and operating model. Learn more about AKB.
