Key takeaways
- Separate location from responsibility: A system's hosting location does not by itself establish who operates it or where every dependency runs.
- Distinguish backup recovery from portability: Same-product restore recovers data, configuration, identity mappings, and keys as required by the deployment, then revalidates permissions. Portability requires separate export and re-import testing.
- Review exact license scope: BSL 1.1 covers parent-repository components, requiring a commercial license at or above 100 aggregate Named Seats or for third-party services. Software usage rights do not grant rights to processed third-party content or satisfy privacy duties.
- Verify full dependency path: Model calls, embeddings, identity, updates, telemetry, and support paths must be recorded using redacted logs and tested under denied egress if disconnected operation is required.
Choosing where an agent's knowledge lives is partly an infrastructure decision and partly an operating agreement. Self-hosting can provide control over the components you deploy, while a managed service can reduce some maintenance work. Neither label is enough to establish privacy, portability, or total cost. The useful comparison identifies exactly what is hosted, who maintains it, and how the organization can recover or move its knowledge.
Separate three decisions that are often combined
First, decide where the components run: customer infrastructure, a cloud account, a vendor environment, or a combination. Second, name the operator responsible for patches, backups, monitoring, and incidents. Third, identify the commercial and access terms under which the service is used.
These dimensions can vary independently. A service can be operated for a customer on customer-controlled infrastructure, subject to the actual offering and agreement. A self-hosted knowledge database can still send requests to an external model or embedding API. A local agent process can also connect to a remote knowledge service.
Data table · Scroll sideways to see all columns. Use arrow keys when focused.
| Decision | Questions to resolve |
|---|---|
| Location | Where are source content, indexes, backups, and logs stored? |
| Operation & Maintenance | Who applies patches, upgrades components, tests compatibility or rollback, and responds to incidents? |
| Managed Contract Scope | What exact components are covered, who tests compatibility and rollback, what support windows apply, how is customer approval managed, and what export formats, costs, or termination assistance are provided? (These are procurement questions, not promises of a commercial managed AKB service.) |
| Network & Dependencies | Which parsing, embedding, inference, identity, licensing, update package, model download, telemetry, or backup paths are contacted? |
| Access & Identity | Which users, service identities, and support staff can reach data, and how are permissions mapped? |
| Recovery & Continuity | Who owns backups and restores? Agree the acceptable data-loss interval (RPO) and target service restoration time (RTO), then test the recovery procedure against them. |
| Licensing & Commercial Scope | Which intended production or non-production use, seat threshold, aggregated deployment model, or third-party service right applies? |
Use this table to compare real configurations. Do not treat a general "on-premises" description as proof that all processing stays inside a network or that the installation works with outbound access blocked.
Test portability before it becomes urgent
A portability test starts by identifying what must survive a move. For a knowledge layer, that may include original documents, structured records, attachments, relations, source references, access metadata, and retained versions. The required scope depends on the application; it should not be left implicit.
Run two separate exercises:
- Same-product backup restore: Restore data, configuration, identity mappings, and encryption keys as required by the chosen deployment into a clean environment. Revalidate current permissions after restoration rather than reactivating revoked identities from an old backup.
- Export and re-import: Export a representative dataset through supported interfaces and import it into the target system or version. Compare record counts, content, attachment checksums, source references, retained revisions, relations, and permission mappings. Record preserved, lost, or converted fields, as well as reindexing time and external dependencies.
Do not imply that a readable export or same-product restore proves cross-vendor portability. Check the licensing of target use independently.
Keep these distinctions clear:
- Answer export: Saving generated text, a spreadsheet, or a presentation.
- Knowledge export: Moving the records and context from which future answers are produced.
- Operational recovery: Restoring the service, identities, configuration, and retained data to a usable state.
One does not establish the other two. Similarly, keeping content in Git can make changes inspectable, but it does not guarantee permanent retention or a complete reproduction of past search results. Retention rules, backups, retrieval configuration, and access state matter too.
Compare local context with an external knowledge service
Repository instruction files can be version-controlled and shared with a team. They can coexist with external knowledge services rather than creating a false replacement requirement. Their limitations depend on how clients load them, how much context they contain, and how updates are governed.
An external knowledge layer serves a different role when several clients need searchable records, relationships, or controlled updates beyond the repository context. MCP can provide an integration interface, but the server implementation determines persistence, retrieval, and authorization behavior. Check the MCP specification and the selected product's documentation for the versions and features involved.
For dependency testing, trace parsing, OCR, embeddings, inference, identity provider checks, licensing endpoints, update packages, model downloads, telemetry, backups, and support paths. Record where sensitive inputs, outputs, and temporary data go using controlled test inputs and approved redacted logs or network metadata, ensuring no secrets or full content are logged. Note that using a private endpoint or local stdio proxy does not prove local processing or data residency.
If disconnected operation is required, exercise necessary workflows under denied egress—including system restart and recovery—and document any failure or degradation. A product label or single network trace does not constitute an airgap guarantee.
Use a short acceptance exercise
Run the acceptance exercise with harmless fixtures in an approved test environment using the intended client configuration (testing two intended clients if evaluating a shared-client claim). Import representative records, execute queries, update and delete records, change permissions, and restore a backup.
Separate update/delete fixtures from revocation fixtures. Confirm permitted identity access before revocation, then verify that read, snippet, and relation access are denied through both existing and fresh connections while authorized accounts retain access. Measure update visibility delay and restoration time. Note that context already disclosed to a client is not retroactively withdrawn.
AKB's documented versioned knowledge, relations, hybrid retrieval, and MCP interface make it a candidate for this exercise. Its suitability depends on the configured deployment and the team's requirements. Optional integrations and operating procedures should be included in the test rather than assumed to be bundled guarantees.
The output should be an evidence-backed configuration description: what runs where, who operates it, what can be exported, how recovery works, and which license covers the intended use.
Include license terms in the deployment design
License review should cover the intended production or non-production use, applicable seat definitions, affiliated deployments, modifications, distribution, and third-party service models. Source availability alone does not establish unrestricted rights.
For Dnotitia AKB, BSL 1.1 covers parent-repository components (including backend, frontend, and deployment manifests), not only the server. The public LICENSE text checked on 22 September 2026 states a conditional grant for production use under 100 aggregated Named Seats across deployments and related entities per the LICENSE. Production deployments at or above 100 aggregate Named Seats, or any third-party hosted, embedded, or rebranded service at any seat count, require a separate commercial license. The npm akb-mcp client proxy is separately MIT-licensed. Verify the LICENSE included with the exact version being deployed. Named Seats are defined per license counting rules rather than simple employee headcount or concurrent connections. Permission to use the software does not by itself establish rights to third-party data or content processed by it, or satisfy applicable privacy obligations.
This matters in an architecture review because the same technical installation can have a different commercial status when it grows or becomes part of a service offered to third parties. Keep the intended use and expected growth alongside the infrastructure design.
Frequently asked questions
Does self-hosting guarantee that data never leaves the network?
No. Verify model calls, embeddings, source connectors, telemetry, support access, and other dependencies for the actual configuration.
Is a Git repository a complete backup of an agent knowledge service?
Not necessarily. Check which records, attachments, metadata, permissions, indexes, and configuration the service requires, and prove restoration in a test environment.
Can a team start small and reconsider hosting later?
A team can start with a small deployment, but later migration is not guaranteed. If preserving that option matters, test export/re-import, dependencies, reindexing effort and target license requirements early.
Review the AKB documentation together with your network, recovery, and licensing requirements before selecting a deployment model.