The context engine for coding agents.
Not just memory — one place your agent recalls durable, graph-aware memory, queries live data (logs, traces, code, every signal your org emits) in KQL/SQL, and walks the graph that links them. Connect it via a plugin, a CLI, or MCP — a local single binary that syncs to your control plane.
// THE HOOK
Install one binary, wire it to your agent, and it recalls durable, graph-aware memory into every prompt — across sessions and machines. That's the hook. Then it grows: the same engine lets your agent query your live data in KQL or SQL, and walks the graph that ties every memory to the real services, repos, and traces it's about. Memory → data → graph, one surface.
// BEYOND MEMORY — THE LIVE DATA
Memory is the front door. Underneath, kyma is one columnar engine for every signal your org emits — so the live data your agent reasons over is the same data these teams already live in. One schema, one query language, one agent.
OTLP logs, traces, metrics in one engine — sub-second queries over years of history. Agents triage incidents from the same data your dashboards render.
Federate Postgres, MySQL, Mongo. Join customer rows with product events and revenue. Skip the warehouse rebuild — query the data where it lives.
Pull AWS, GCP, Azure billing exports through the same ingest path. Group by service, team, tag. Alert on anomalies. The agent answers "why is spend up?" without a separate tool.
Auth events, IAM changes, deploys, secret rotations — one immutable, time-partitioned store. Forensic queries that would take hours in a SIEM, in seconds.
Beyond rows and columns: kyma stores entities and relationships as a first-class graph. Trace from a Stripe customer to their auth events to the deploy that broke their checkout — in one query, in milliseconds, at organizational scale.
Stripe events. GitHub Actions outcomes. Customer support tickets. Webhook payloads. If it has a timestamp and a JSON body, it goes through one POST and becomes queryable.
// THE GRAPH — WHERE IT ALL CONNECTS
The third layer. A native graph over the same Arrow storage, where your agent's memories are nodes wired to the real services, repos, and traces they're about — millions of entities, hundreds of millions of relationships, queried in milliseconds.
// THE NEW PRIMITIVE
When every signal — including the agents themselves — flows through one engine, agents stop being one-shot tools. They become a recursive layer: a triage agent's output is the next triage agent's input. A finance agent reads what the SRE agent observed last hour. A security agent traces an anomaly through the graph the BI agent just queried. The engine that answered the last question is the engine that asked the next one.
Every /v1/agent/ask call is itself logged into kyma — question, tool calls, result. Agent runs become first-class data.
The next agent reads agent_runs the same way it reads otel_logs. It sees what colleagues asked, found, missed.
Patterns across runs surface in the graph. The org's collective troubleshooting becomes an asset that improves with use, not a stream that vanishes.
// THE QUERY SURFACE
Both languages parse to the same logical plan. Both run through the same three-level pruning cascade. Both stream Arrow over the same Flight gRPC endpoint. Pick whichever your tool already speaks.
// errors per service in the last hour otel_logs | where _timestamp > ago(1h) | where severity_text == "ERROR" | summarize n = count() by service_name | order by n desc | take 5
// HOW IT STAYS FAST
Catalog pruning eliminates 99% of extents using time-range and column statistics. Extent footers eliminate 90%+ of blocks via bloom filters. Block-level posting lists narrow to exact rows. The decode step only touches data that matters.
Read the deep dive →// THE DOCS
Give your coding agent memory in one command — local, zero infra, ~5 min.
How it all works: memory → data → graph, the modes, dreaming, and sync.
OTLP gRPC, REST/NDJSON, Kafka, file-drop. One write path on the far side.
KQL, SQL, and the agent endpoint. Arrow Flight gRPC for zero-copy streams.
Postgres, MySQL, MongoDB. Federate live, or sync via CDC.
One binary locally, or scale out on AWS/EKS, Kubernetes (Helm), Terraform, or Pulumi — via kyma deploy.
The five invariants and how they hold the engine together.
What it's for — memory, live data, and the graph, doing real work.
HTTP API, CLI, env vars, KQL functions, schema mappings.
