Production knowledge, as a query.
One engine that turns everything your org runs on — logs, traces, metrics, databases, billing exports, deploys, support tickets, anything with a timestamp and a body — into something an agent can answer in milliseconds.
// THE PITCH
kyma is the answer layer for production-aware agents. One ingest pipe for every signal — OTLP, REST, Kafka, file-drop. First-class federation to your operational databases. KQL or SQL on the front. Sub-second latency over a decade of history. And a built-in agent endpoint that turns natural-language questions into the same query you'd have written yourself.
// WHAT IT REPLACES
Each tool below is a category your org probably has three of. Run them all through 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 CONTEXT ENGINE
Rows and columns describe events. Graphs describe how those events relate. kyma carries a native graph layer over the same Arrow storage — millions of entities, hundreds of millions of relationships, queried in milliseconds. The same engine that's already proving it on the Agentcy platform.
// 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
Five minutes from docker compose up to your first KQL query.
How the engine thinks: invariants, the pruning cascade, schema, agents.
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.
The five invariants and how they hold the engine together.
Worked examples — copy, paste, adapt.
HTTP API, CLI, env vars, KQL functions, schema mappings.
