Every architect who has ever asked an AI “how many m² did we deliver in canton Zürich last year?” knows the failure mode. The agent re-reads your whole schema, guesses which column means gross floor area, joins two tables that should never touch, and hands you a confident number that is wrong by a curtain wall. Show HN: ktx — an open-source “executable context layer for data agents” from the Kaelio team — is a direct swing at that exact pain.

←TODAY: In 2026 a general-purpose agent re-explores your warehouse on every question and invents metric logic it has no business inventing. →3012: The studios that survive are the ones whose canonical definitions outlive the agent, the vendor, and the analyst who wrote them. Fulcrum: A metric is only trustworthy when it is stored once and queried declaratively — not re-derived on every prompt.

The Tool: ktx (github.com/Kaelio/ktx) is a self-improving context layer that sits on top of an existing SQL warehouse and teaches agents — Claude Code, Codex, Cursor, OpenCode — how to query it accurately. It samples your tables, detects joinable columns, resolves the classic fan and chasm traps, ingests scattered wiki/Notion/dbt knowledge, and flags contradictions for a human to review. The overview on the pipeline2insights Substack frames it well: instead of three disconnected surfaces (semantic layer, raw tables, team wiki), the agent gets one searchable one. Dylan Anderson’s Data Ecosystem issue on “the context moat” makes the broader case — context, not raw model horsepower, is what separates an agent that helps from one that hallucinates a refund policy.

System: Why is this possible now and not in 2021? Because the missing piece was never the database — it was the protocol. ktx exposes its knowledge through MCP (Model Context Protocol) tools plus a CLI, and runs entirely local: nothing leaves your machine except the calls to the LLM provider you configured. Connections are read-only by design, which is the first thing I check before pointing any agent at a production warehouse. You bring your own keys — a Claude Pro/Max session through Claude Code, or local Codex auth — so there is no second usage meter.

Setup:

# Node 18+ ; you also need a SQL warehouse already running
npm install -g @kaelio/ktx

ktx setup     # creates/resumes a project, configures providers + connections,
              # builds context, installs the agent integration
ktx status    # confirms readiness

# If status prints an mcp line, start the daemon before opening your agent:
ktx mcp start --project-dir .

First steps:

1. Read your status. A healthy ktx status reports LLM ready, Embeddings ready, Databases configured, Context sources configured, and ktx context built: yes. Any no tells you exactly which step stalled.
2. Build the context. Run ktx ingest to sample tables, capture metadata, and assemble the join graph for every configured connection. This is the slow, valuable step — let it finish.
3. Search before you trust. Try ktx sl "revenue" to search semantic sources and ktx wiki "refund policy" to search local wiki pages. If the right metric definition surfaces, your agent will now reach for it instead of rewriting canonical SQL.
4. Commit the right things. Version ktx.yaml, semantic-layer/, and wiki/. Keep .ktx/ (local state and secrets) git-ignored — it ships that way already.

Atelier: Swap “warehouse” for “project database” and this is squarely AEC. A Swiss studio running Archicad–Speckle–Bonsai already has metrics scattered everywhere — floor area in the IFC, hours in the time-tracker, costs in a Postgres export, the actual agreed LOIN buried in a Notion BEP. ktx is the pattern for making one read-only surface an agent can query without re-litigating what “net area” means against SIA 416 every single morning. The contradiction-flagging is the part conference talks skip and the part that saves the Bauleitung from a wrong number in a Wettbewerb submission.

Hack: This Hack teaches you to find the fan-trap before your agent ever does — one SQL move in the Databases domain. A fan trap inflates a SUM when you join a one-to-many table, so check the cardinality first:

-- Does projects → invoices fan out? If max > 1, SUM(amount) will double-count.
SELECT p.id, COUNT(i.id) AS rows_per_project
FROM projects p
LEFT JOIN invoices i ON i.project_id = p.id
GROUP BY p.id
ORDER BY rows_per_project DESC
LIMIT 5;

If the top row is greater than 1, aggregate invoices in a sub-query before joining. ktx encodes exactly this resolution in its join graph so the agent gets it right declaratively — but understanding the move by hand is what lets you trust the tool.

Move: Here is the trade-off, stated plainly: ktx only earns its keep if you already have a SQL warehouse and scattered definitions worth unifying — for a single ad-hoc query, psql still wins, and the maintainers say so. And from the late-2070s vantage of this desk: the project files that aged worst were never the ugly ones, they were the ones whose canonical logic lived only in a proprietary tool that went dark. ktx keeps your metric definitions as plain committed YAML. That single property — a 25-year-old can still open the file — is the one I would optimise for this quarter. Clone it against a throwaway SQLite copy this afternoon and watch your agent stop inventing numbers.

Learn-it:

• Repo: github.com/Kaelio/ktx — source, CLI reference, contributing guide.
• Overview: pipeline2insights — Introduction to ktx.
• Concept: Dylan Anderson — The Context Moat AI Needs — why a context layer matters.
• PAZ note: ktx is the data-warehouse cousin of PAZ’s own Grasshopper↔Archicad Library — same instinct, one personalised surface instead of three disconnected ones.