Build vs Buy Agent Knowledge Layers: A Cost Worksheet for Retrieval and Ingestion

Key takeaways

Compare the same workload: Use the same sources, permission requirements, query mix, and support window for each option.
Count recurring work: Connector maintenance, retrieval evaluation, incident response, and upgrades can matter as much as the initial build.
Separate price from scope: A license or subscription is only one part of the cost; confirm which operating tasks it includes.
Test the expensive uncertainties: Use a pilot to estimate engineering effort and resource demand rather than relying on unverified benchmarks.

A build-versus-buy decision becomes clearer when it is expressed as a worksheet rather than a feature count. The goal is to estimate the cost of delivering an acceptable knowledge service for a specific workload. A team that needs two stable document sources has a different problem from one that must support many changing connectors, complex permissions, and several agent clients.

Define one common baseline

Before comparing architectures, record source systems, data volume, update frequency, expected users, and query concurrency. Specify access rules, deployment locations, recovery objectives (defining RTO as target restoration time and RPO as acceptable data-loss interval), and support hours. Requirements need not all be contractual SLAs; use agreed acceptance targets.

Select a representative evaluation query set containing exact identifiers, natural-language questions, ambiguous terms, questions requiring source attribution, denied-access tests, and deleted-document edge cases. A lower-cost configuration is not equivalent if it achieves savings by dropping mandatory requirements.

Keep model and embedding choices explicit. Query embeddings, retrieval compute, reranking, and model input/output inference charges remain active cost drivers regardless of backend database choice.

Compare the work in each operating model

Data table · Scroll horizontally to see all columns. Arrow keys work when focused.

Cost area	Team-operated component assembly	Assembly of managed services	Integrated platform (operator to confirm)
Initial integration	Team connects selected open components	Team connects managed cloud services	Team configures platform capabilities and fills gaps
Source ingestion	Team builds or adapts connectors and parsing pipelines	Connector coverage and custom options vary by service	Confirm supported sources, update frequencies, and permission behavior
Retrieval tuning	Team owns ranking, re-indexing, and evaluation	Responsibilities depend on service boundaries	Confirm available ranking controls and evaluation access
Infrastructure operations	Team provisions, monitors, and maintains the stack	Provider operates contracted backend services	Hosting and operator duties depend on specific offering
Client maintenance	Team tests assembled system against client updates	Team tests managed service and client compatibility	Confirm vendor support and regression test duties
Exit and recovery	Team designs export tools, backups, and restores	Verify provider export formats and restore options	Verify full knowledge export and contractual support

Architectural patterns can overlap, and licensing must be checked separately from deployment topology. AKB Core licensing and any hosting or support contract must be evaluated independently; source-available licensing does not dictate an operating model or guarantee managed service availability.

Build a transparent cost model

Calculate total cost over a defined evaluation period (H months) using plain-text accounting rules in one currency:

TCO over H months = one-time implementation and migration + sum over H months [incremental recurring vendor/infrastructure charges + internal operating hours × fully loaded hourly rates] + scheduled change/exit costs not counted elsewhere

Accounting principles:

Cash versus effort: Report direct cash outlays separately from allocated internal labor.
Future labor: Future employee hours required for ongoing maintenance are operating costs, even if headcount is fixed. Exclude only irrecoverable historical sunk costs.
Labor valuation: Loaded labor rates are a consistent planning allocation rather than an isolated opportunity cost measurement. Use organization-defined rate components and document capacity assumptions.
Resource constraints: Existing hardware or cloud capacity may incur zero incremental cash, but record any utilization constraints.
No double counting: Count bundled hosting or API allowances only once. Allocate shared costs once across worksheet lines, and do not count the same setup, re-indexing, or upgrade work again as recurring labor.

Fill in the cost worksheet

For each line below, record unit volume, unit rate, cadence (one-time vs. recurring), included/excluded items, evidence date, owner, and low/base/high estimates. Mark missing entries as Unknown rather than zero.

Initial setup and migration: Engineering labor for configuration, connector setup, permission mapping, and initial data load.
Parsing and OCR processing: Ingestion parsing, OCR compute, retries, and manual curation or review hours.
Embeddings and indexing: Initial corpus embedding, incremental re-embedding, and vector index updates.
Query and inference usage: Query embedding generation, retrieval compute, reranking passes, model input/output tokens, and query retries.
Storage and retention: Object/file storage, database/index compute, snapshot backups, and network egress charges.
Connector upkeep: Maintenance for source API changes, schema evolution, credential rotation, and pipeline failure recovery.
Platform operations: Non-production/staging environments, monitoring, security/key management, and on-call operational response.
Subscriptions and licenses: Applicable seat counts, usage tiers, commercial license terms, and external support contracts.
Upgrades and exit: Scheduled software upgrades, knowledge export testing, and potential migration execution.

Optional operational unit metrics

When evaluating cost efficiency, use these optional operational metrics:

Cost per successful authorized retrieval: Total retrieval and inference costs divided by count of successful, authorized, grounded retrievals meeting latency targets.
Cost per accepted ingested document: Total ingestion, parsing, OCR, and indexing costs divided by count of successfully ingested document versions.

Rules for operational metrics:

Numerator and denominator: Denominators count accepted outcomes only. Numerators must include retry overhead, failed processing attempts, and allocated shared costs.
Zero outcomes: If zero accepted outcomes occur, report the metric as undefined rather than zero.
Normalizing comparison: When comparing document costs across systems, maintain identical page-count distributions and corpus mixes. Disclose shared-cost allocations and setup/exit exclusions.

Plan for recovery and exit testing

Distinguish routine operational backup recovery (satisfying RTO and RPO targets) from system export and re-import migration. Operational snapshot restores do not guarantee clean migration to a different backend.

During migration testing, audit preservation across five layers:

Raw source files and document blobs
Extracted metadata and custom attributes
Version history and document revisions
Entity graphs and cross-document relations
Permission mappings and access control lists (ACLs)

Evaluate scenario sensitivities before deciding

Keep measured pilot results separate from scale projections, and vary query volume, source change rate, manual review hours and contract tiers in low/base/high scenarios; there is no universal break-even threshold.

Assemble pilot measurements, worksheet totals, risk assumptions, and operational owners into a single reviewable document before committing to an architecture.

Account for AKB's scope and license

AKB provides a versioned knowledge engine with Model Context Protocol (MCP) support, explicit relation mapping, and hybrid retrieval. It can serve as a reusable knowledge backend for agent clients. Optional extensions assist with specific ingestion or workflow steps, but their setup and maintenance remain part of the customer worksheet.

AKB's BSL 1.1 license includes a conditional production-use grant for fewer than 100 Named Seats aggregated across all deployments and related entities as specified in the exact LICENSE. Production use at 100 or more aggregated Named Seats, or offering AKB as a hosted, embedded, or rebranded service to third parties at any seat count, requires a separate commercial license from Dnotitia. The npm akb-mcp proxy wrapper is separately MIT-licensed. Public license text checked 22 September 2026. Review the LICENSE supplied with the exact version being deployed.

Frequently asked questions

Is self-hosting always cheaper?

Not necessarily. Total cost depends on license and service contracts, infrastructure charges, and internal labor. Compare options against equivalent service requirements and record both cash outlays and allocated effort.

Does an integrated platform eliminate connector work?

It can reduce repeated integration for supported sources. Total cost depends on license/service contracts, infrastructure and labor; unusual integrations may need configuration, vendor work or custom development.

What is a useful final decision document?

Keep the common workload baseline, completed cost worksheet, sensitivity analysis, pilot measurements, unresolved assumptions, and operational ownership together in a single record.