Most enterprise AI agents treat knowledge as static. You embed documents, index them, and hope retrieval finds the right context. Kapso takes a different approach: it runs experiments against enterprise data, learns from the results, and updates a knowledge graph incrementally. No retraining cycles. No upfront ontology design. Just a feedback loop that compounds understanding across investigations.
The architecture matters because enterprise data environments are messy. One of Kapso's reference projects involved migrating 30+ source systems, thousands of tables, and hundreds of BI reports to a lakehouse. No single person or agent understood how the estate connected. The only path forward was iterative: investigate repos and dbt models, propose hypotheses about data lineage, run experiments, observe failures, and update the knowledge graph with what worked.
The Iterative Learning Loop
Kapso's core is a three-stage cycle:
- Investigation: The agent queries existing knowledge graph nodes, retrieves relevant documents, and identifies gaps.
- Experimentation: It proposes hypotheses (e.g., "Table X feeds Report Y via transformation Z"), runs tests in a sandbox, and collects outcomes.
- Learning: Successful experiments update the knowledge graph. Failed experiments store failure modes as negative examples.
This differs from RAG-only systems in two ways. First, retrieval is not the end state. It feeds into hypothesis generation. Second, the knowledge graph is mutable. Each experiment can add nodes (new entities), edges (relationships), or attributes (constraints learned from failures).
State Management Across Sessions
Kapso maintains three state layers:
- Session state: Tracks the current investigation's context, including active hypotheses and pending experiments.
- Graph state: Persists the knowledge graph itself, with versioning for rollback when experiments invalidate prior assumptions.
- Experiment log: Stores every test run, including inputs, outputs, and whether the hypothesis was confirmed or rejected.
The session state is ephemeral. When an agent completes an investigation, the session closes, but confirmed knowledge moves into the graph. This separation prevents partial or speculative updates from polluting the shared knowledge base.
When to Query vs. When to Mutate
The decision logic is straightforward:
- Query: If the agent's question maps to existing graph nodes and edges, retrieve and return.
- Mutate: If retrieval returns incomplete or conflicting information, or if an experiment confirms a new relationship, update the graph.
The mutation path includes a conflict resolution step. If two agents propose contradictory edges (e.g., "Table A feeds Report B" vs. "Table A does not feed Report B"), the system prioritizes the hypothesis with more recent experimental evidence. Older edges are marked as deprecated, not deleted, so you can trace how understanding evolved.
Architecture: Sandbox, Orchestrator, Graph Store
Here's the deployment shape:
| Component | Role | Failure Mode |
|---|---|---|
| Orchestrator | Manages agent lifecycle, schedules experiments, routes queries | Deadlock if circular dependencies in hypotheses |
| Sandbox | Isolated environment for running experiments (SQL, dbt, Python) | Resource exhaustion if experiments don't timeout |
| Graph Store | Persists knowledge graph with ACID guarantees (Neo4j, TigerGraph) | Stale reads if replication lag exceeds session TTL |
| Experiment Log | Append-only log of all test runs (S3, Postgres with JSONB) | Unbounded growth without retention policy |
| Retrieval Layer | Embeds documents and queries for investigation phase (Pinecone, Qdrant) | Embedding drift if documents update without reindex |
The orchestrator is stateless. It reads session state from the graph store, dispatches experiments to the sandbox, and writes results back. This makes horizontal scaling simple: spin up more orchestrator instances and point them at the same graph store.
The sandbox is where risk lives. Experiments run arbitrary code (SQL queries, dbt transformations, Python scripts). Kapso isolates each experiment in a containerized environment with resource limits (CPU, memory, wall-clock time). If an experiment hangs or consumes too much memory, the sandbox kills it and logs the failure. The agent learns that the hypothesis was invalid or too expensive.
Code: Experiment Execution Flow
Here's a simplified version of how Kapso runs an experiment and updates the graph:
def run_experiment(hypothesis, sandbox, graph_store, experiment_log):
"""
Execute a hypothesis in the sandbox and update the knowledge graph.
"""
session_id = hypothesis.session_id
experiment_id = generate_id()
# Step 1: Prepare sandbox environment
sandbox.reset()
sandbox.load_context(hypothesis.required_tables)
# Step 2: Execute hypothesis test
try:
result = sandbox.execute(
code=hypothesis.test_code,
timeout_seconds=300,
max_memory_mb=2048
)
success = result.exit_code == 0 and result.assertions_passed
except SandboxTimeout:
success = False
result = {"error": "timeout"}
except SandboxOOM:
success = False
result = {"error": "out_of_memory"}
# Step 3: Log experiment
experiment_log.append({
"experiment_id": experiment_id,
"session_id": session_id,
"hypothesis": hypothesis.description,
"success": success,
"result": result,
"timestamp": now()
})
# Step 4: Update graph if successful
if success:
graph_store.add_edge(
source=hypothesis.source_entity,
target=hypothesis.target_entity,
relationship=hypothesis.relationship_type,
metadata={
"experiment_id": experiment_id,
"confidence": result.confidence_score
}
)
else:
# Store negative example
graph_store.add_negative_edge(
source=hypothesis.source_entity,
target=hypothesis.target_entity,
relationship=hypothesis.relationship_type,
reason=result.get("error")
)
return success
The key detail: negative edges. When an experiment fails, Kapso doesn't just discard the hypothesis. It stores the failure in the graph so future investigations don't repeat the same mistake. This is how the system compounds learning.
Observability: What Triggered Graph Mutations
You need visibility into which documents or experiments caused graph changes. Kapso exposes three observability hooks:
- Mutation log: Every graph update includes a reference to the experiment ID and the documents that informed the hypothesis.
- Lineage trace: For any graph edge, you can query backward to see the chain of experiments and retrievals that led to it.
- Conflict dashboard: Shows deprecated edges, the experiments that invalidated them, and the new edges that replaced them.
The mutation log is append-only. You can replay it to reconstruct the graph at any point in time. This is useful for debugging when an agent makes a bad decision based on outdated knowledge.
Multi-Agent Conflict Resolution
When multiple agents iterate on overlapping data sources, conflicts are inevitable. Kapso handles this with optimistic locking at the graph level:
- Each agent reads the graph with a version timestamp.
- When an agent proposes a mutation, the graph store checks if the relevant nodes or edges have changed since the read.
- If they have, the mutation is rejected, and the agent retries with fresh data.
This prevents lost updates but introduces retry overhead. In practice, conflicts are rare because agents work on different subgraphs (different source systems or BI reports). When conflicts do occur, the retry loop usually resolves them within one or two attempts.
Deployment Considerations
Kapso is not a SaaS. It's an engine you deploy in your own infrastructure. The reference architecture assumes:
- Graph store: Managed Neo4j or TigerGraph instance with automated backups.
- Sandbox: Kubernetes cluster with pod-level resource limits and network isolation.
- Orchestrator: Stateless service deployed as a Kubernetes Deployment with horizontal pod autoscaling.
- Experiment log: S3 or Postgres with a retention policy (e.g., keep experiments for 90 days, then archive to cold storage).
The sandbox is the bottleneck. Each experiment needs its own isolated environment, which means spinning up containers. If you're running hundreds of experiments per hour, you need a cluster with enough capacity to handle the burst. Kapso includes a queueing layer (backed by Redis or RabbitMQ) to smooth out spikes.
Security Boundaries
Enterprise data is sensitive. Kapso enforces three security layers:
- Sandbox isolation: Experiments run in ephemeral containers with no network access except to the graph store and experiment log.
- Graph-level access control: Nodes and edges can have ACLs. An agent can only query or mutate parts of the graph it has permissions for.
- Audit trail: Every graph mutation is logged with the agent ID, session ID, and experiment ID. You can trace any change back to the agent and investigation that triggered it.
The sandbox isolation is critical. If an experiment runs malicious code (intentionally or via prompt injection), it can't exfiltrate data or pivot to other systems. The container dies when the experiment completes, and all state is discarded.
When This Makes Sense
Kapso is overkill for simple retrieval tasks. If you just need to answer questions from a static document corpus, use a vector store and a retrieval-augmented generation pipeline. Kapso is for environments where:
- The knowledge base is incomplete and evolving.
- You need to run experiments (SQL queries, transformations, simulations) to validate hypotheses.
- Multiple agents or teams are iterating on the same data, and you want to compound learning across investigations.
The reference use case (migrating a data estate) is a good fit because the knowledge graph starts empty. You don't know how tables connect or which transformations feed which reports. The only way to learn is to investigate, experiment, and update the graph as you go.
When to Avoid It
Skip Kapso if:
- Your knowledge base is static or changes infrequently. The overhead of maintaining a mutable graph and experiment log isn't worth it.
- You don't need to run experiments. If retrieval alone solves your problem, a vector store is simpler.
- You can't tolerate the operational complexity of managing a graph store, sandbox cluster, and orchestrator.
The system also assumes you have engineering resources to write experiment code (SQL, dbt, Python). If your agents need to generate and run arbitrary experiments without human oversight, you're in reinforcement learning territory, and Kapso's supervised experiment loop won't help.
Technical Verdict
Kapso exposes the plumbing of continuous learning agents: stateful update cycles, conflict resolution in graph mutations, and observability for incremental knowledge extraction. It's a good fit for enterprise data projects where the knowledge base is incomplete and you need to compound learning across investigations. The architecture is sound (stateless orchestrator, isolated sandbox, versioned graph store), but the operational overhead is real. You need Kubernetes, a managed graph database, and enough compute to run experiments in parallel.
Use it when you're migrating data estates, building lakehouses, or investigating complex systems where no one has the full picture. Avoid it if your knowledge base is static, your agents don't need to run experiments, or you can't justify the infrastructure cost.
Top comments (0)