Data Superpowers for Agents

$ uv add xorq

THE CONTEXT ENGINE FOR DATA AGENTS.

Your agent harnesses are unreliable at scale

without structured context across SQL and Python.

$ demo --play

$ capabilities

Declarative grammar

Ibis expressions carry full lineage and transparency. Agents compose typed, traceable computations — not opaque scripts.

Agentic compute layer

Agents write expressions, xorq does the rest: plans across engines, caches by input hash, skips redundant work.

Composable catalog

Every entry is an executable expression. Agents build on prior work, not just reference it.

Git-native merging

Same expression, same hash, same commit. Parallel agents auto-converge — conflicts resolve, not collide.

$ benchmark --results

DABStep benchmark: Haiku 50% vs Sonnet 75% vs Haiku + xorq Catalog 84%

# setup

DABStep: 450 questions over payment data. Same model, same domain rules, same prompt. Only the context layer changes.

Haiku baseline (pandas + raw files): 50%
Haiku + catalog (33 expressions): 84%
Sonnet + catalog: 91%

# key finding

Haiku + catalog outperforms Sonnet baseline (75%) in half the turns. The catalog routes agents to pre-computed tables — more structure means less reasoning required.

$ cat full-story

$ architecture --diagram

xorq architecture: agent harnesses connect via tools/skills, sandboxes connect via git/Arrow

$ help

? What is Xorq?

You write a declarative expression, Xorq saves it to an immutable catalog entry (expression + metadata + cached results) that can be executed, diffed, shared, and served.

? How is this different from a data catalog?

Traditional catalogs document tables for humans — name-addressed, passively consumed. Xorq catalogs executable expressions for agents — input-addressed, actively composed. A traditional catalog answers “what tables exist?” Xorq answers “has this exact computation been done before?”

? Do I need to migrate?

No. Xorq connects directly to your existing infrastructure (Snowflake, Databricks, S3). No migrations required.

? What does “input-addressed” caching mean?

The identity of a cached result is determined by hashing the expression and all of its inputs. If the inputs haven’t changed, the result is reused without re-execution. Traditional caching asks “is this expired?”. Input-addressed caching asks “are the inputs the same?”.

? What does it mean to “serve an expression”?

Serving exposes a compiled expression as a remote endpoint over Arrow Flight so other services or agents can send inputs and receive results without re-implementing pipeline logic.

? How does Xorq compare to dbt Fusion?

dbt Fusion gives you a faster, Rust-powered dbt with SQL-aware validation. Xorq gives you an expression graph that spans languages and engines, with a catalog that versions, caches, and governs the full pipeline. If your world is SQL models, Fusion is a meaningful upgrade. If your world is SQL + Python + ML across multiple engines, xorq is built for that from the ground up.

? What about imperative code or custom logic?

Escape hatches exist via UDFs and Arrow-based interfaces — opaque stages can conform to the same contract. Declarative at the top level, imperative underneath when necessary. Like unsafe in Rust — controlled, explicit, bounded.

? How does Xorq handle merge conflicts?

Same expression, same hash, automatic dedup. Different expression, different hash, no collision. Parallel work either converges or coexists — conflicts auto-resolve because identity is determined by content, not location.

$ status

Agents are ephemeral. Sessions end. Models get swapped. Prompts change.

What compounds is the catalog — each entry verified evidence that the next agent builds on. Not accumulated output. Composable, reproducible work.

Not the agents. The work.