Disposable code, durable expressions.

Multiple agents don’t converge — they collide. Work needs to be easily partitioned. Merge conflicts aren’t a git problem. They’re a coordination problem. There’s no shared substrate.

When work does persist unverified, it doesn’t compound — it accumulates.

Problem statements aren’t self-contained — they carry no verification criteria, no reference to prior work. Humans can’t express acceptance in terms of what’s already been computed.

One root cause: nothing the agent produces has durable, addressable identity.

Xorq is expression-first — every computation becomes a catalog entry, a single object with dual nature. Looking backward, it’s evidence: what was computed, from what inputs, with what hash. Looking forward, it’s material: a partitionable expression that decomposes across engines and snaps into larger computations.

Evidence is semantic — identity follows from meaning. Same expression, same hash. Agents that mean the same thing converge automatically.

Material is composable — the catalog isn’t a document store agents read. It’s a surface agents build on. Each entry is a part that snaps into a larger computation and can be built in a partitionable manner.

Entries are addressable, so problem statements can reference them directly. Acceptance criteria become catalog-referential — defined and verified against the same graph agents build on.

Same object. Two faces. That’s the primitive.

• xorq catalog list — search the catalog. Find what exists before computing anything new.
• xorq run-unbound — execute an expression with inputs resolved at runtime.
• xorq lineage — trace any result to its source. Verify provenance through the graph.

Agent receives a question. Searches the catalog for existing entries. Finds partial coverage — some expressions already computed, cached, verified. Composes a new expression from existing parts plus new logic. Executes. The result becomes a new entry.

Second session. Same question. Cache hit. No recomputation. The work compounded.

Different agent. Related question. Finds the entry, extends it. Doesn’t need to know who computed it or when. The hash is the handshake.

%%{init: {'theme': 'base', 'themeVariables': {'actorBkg': '#0a2a2e', 'actorBorder': '#C1F0FF', 'actorTextColor': '#C1F0FF', 'actorLineColor': '#1a4a50', 'signalColor': '#C1F0FF', 'signalTextColor': '#C1F0FF', 'noteBkgColor': '#0f3538', 'noteBorderColor': '#1a4a50', 'noteTextColor': '#8fd4e8', 'activationBkgColor': '#0f3538', 'activationBorderColor': '#1a4a50', 'labelBoxBkgColor': '#05181A', 'labelBoxBorderColor': '#1a4a50', 'labelTextColor': '#5ab0c8', 'loopTextColor': '#5ab0c8', 'background': '#05181A', 'mainBkg': '#0a2a2e', 'lineColor': '#1a4a50', 'textColor': '#C1F0FF', 'primaryColor': '#0a2a2e', 'primaryBorderColor': '#C1F0FF', 'primaryTextColor': '#C1F0FF', 'secondaryColor': '#0f3538', 'tertiaryColor': '#0f3538', 'fontFamily': 'FK Grotesk Mono, monospace', 'fontSize': '13px'}}}%%
sequenceDiagram
    participant User
    participant Agent
    participant Catalog
    participant Engine

    User->>Agent: churn by channel?
    activate Agent
    Agent->>Catalog: search / compose / lineage
    Agent->>Catalog: execute
    Catalog->>Engine: cache miss → run
    activate Engine
    Engine-->>Agent: result
    deactivate Engine
    Agent->>Catalog: add
    Agent->>User: result
    deactivate Agent

    rect rgba(15, 53, 56, 0.3)
        Note over Agent,Catalog: NEW SESSION
        User->>Agent: churn by channel?
        activate Agent
        Agent->>Catalog: execute
        Catalog-->>Agent: cache hit
        Agent->>User: result
        deactivate Agent
    end

• MCP Server — zero-SDK discovery in Claude Desktop and any MCP-native framework. The catalog shows up as a first-class tool.
• Hooks — lifecycle callbacks in the agent loop. PreToolUse, PostToolUse, ToolFailure.
• Plugins — slash commands inside agent UIs.
• Skills — reusable capabilities coding agents invoke directly.

Snowflake, Databricks, S3. Claude Code, Codex. LangChain. No migrations. Xorq sits between the agents and the infrastructure you already run.

Pay for catalog storage and bytes transferred over Arrow Flight. Compute stays pluggable.

+----------------------------------+-------------------+
| Tier                             | Price / Month     |
|----------------------------------|-------------------|
| Starter (up to 10gb namespaces)  | $99               |
| Team (up to 25gb)                | $299              |
| Enterprise (unlimited)           | Custom            |
+----------------------------------+-------------------+

+----------------------------------+-------------------+
| Endpoint Type                    | Price / GB        |
|----------------------------------|-------------------|
| Flight DoGet (read)              | $0.10             |
| Flight DoPut (write)             | $0.05             |
| Flight DoExchange (transform)    | $0.01             |
+----------------------------------+-------------------+

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. Xorq catalogs executable expressions for agents. Input-addressed, not name-addressed. Active coordination, not passive documentation.

Do I need to migrate to Xorq?

» 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 — not the output content. If the inputs haven’t changed, the result is reused without re-execution. This is input-addressed, not content-addressed: trust comes from knowing the recipe is identical, not from inspecting the output. 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 if I need imperative code or custom logic?

» Expression-first does not eliminate flexibility. 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.

What happens when upstream data changes between sessions?

» You choose the invalidation strategy: modification-time (re-run if the source has been touched) or snapshot with TTL (trust the cache for a window, then re-validate). The expression stays the same. The cache policy is separate. Staleness tolerance is a business decision, not something the system should hide from you.

How does Xorq handle merge conflicts?

» It doesn’t — because there aren’t any. Same expression, same hash, automatic dedup. Different expression, different hash, no collision. In code, parallel work creates merge conflicts. In an input-addressed catalog, parallel work either converges or coexists. No locking, no conflicts, no deduplication logic.

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

Compounding cuts both ways. Without verification, it’s accumulation — each layer more confident, less grounded. With verified vocabulary and a composable base, each entry is evidence the foundation holds and material the next agent builds on.

That’s what compounds. Not the agents. The work.