Context and Knowledge Engines
What context engines are
Section titled “What context engines are”A context engine is the layer responsible for transforming raw repository and project data into structured, queryable knowledge that agents can consume. Where a harness manages how an agent acts, a context engine manages what an agent knows. In a multi-agent system, the quality and accessibility of that shared knowledge directly determines execution reliability.
Context engines vary in how they ingest data, how they represent relationships, how they stay current, and who can access what.
Requirements
Section titled “Requirements”Ikidna operates across distributed infrastructure with multiple repositories and multiple agents running concurrently. The context engine must be designed for that environment, not for a single developer’s local machine.
-
Server-first, not local-first. The context engine must run as a service that agents connect to, not as a process that runs on the same machine as the agent. Local-only tools cannot serve a swarm. The knowledge graph must be accessible over a network interface from any agent in the system.
-
Auto-updating on upstream changes. The context engine must respond to repository changes commits, merges, branch updates and update the knowledge graph without manual intervention. Stale context is a source of agent error. Agents should be able to trust that the graph reflects current repository state.
-
Incremental updates and temporal knowledge. Re-indexing an entire codebase on every change is not acceptable at scale. The engine must support incremental ingestion so that only changed surfaces are reprocessed. It should also retain awareness of how the codebase has changed over time, not just its current state, so agents can reason about recent changes and their effects.
-
Multi-repo support. Ikidna targets codebases that may span multiple services and repositories. The context engine must be able to index and query across multiple repos, resolve cross-repo dependencies, and present a unified graph to agents that need to reason about service boundaries.
-
Authentication and data partitioning. Not all agents should have access to all repositories or all parts of the graph. The engine must support authentication and access control so that context is partitioned by project, team, or classification. This is a prerequisite for multi-tenant or enterprise deployment.
-
Pluggable storage backends. The engine must not be tightly coupled to a single storage system. Different deployments will have different persistence, scalability, and compliance requirements. Support for swappable graph and vector storage backends ensures the engine can fit the infrastructure rather than dictating it.
filter: "/software/context/"sort: title ASClimit: 10