The Product · Tether

Tether.
The enforcement primitive.

Runtime middleware between your agent and its tools. Model-agnostic via LiteLLM. Enforced outside the context window. The rule is structurally interposed, not advisory.

Book an audit →Read the enforcement paper

Architecture · where Tether sits

your agentCursor, Claude Code, Codex, Devin, custom harness

tool call

calx tethermiddleware · veto · review · defense

allowed · or denied

tools + toolsshell, git, file system, MCP, APIs

Enforcement is structurally interposed. The model cannot address it with a prompt.

Three primitives

Compiled rules as middleware hooks.

Every compiled rule reduces to one of three enforcement patterns.

Prim 01

Pre-execution · tool dispatch

Tool veto

Block a specific tool call at the harness level. The agent sees a denied-tool response, not a prompt violation. The tool never ran.

hook git_safety:
  on tool_call(name="bash") {
    if cmd.matches("--force") veto()
  }
# syscall blocked at 42ms

Prim 02

Post-generation · pre-delivery

Response review

Check output against compiled rules before delivery. On violation, trigger bounded retry. The agent never learns a rule was broken; it simply produces compliant output.

hook schema_contract:
  on response_ready() {
    if out.violates("api.v2.schema")
      retry(max=3)
  }

Prim 03

All layers · architecturally interposed

Injection defense

Compiled rules cannot be overridden by prompt injection. They are enforced outside the context window, at the middleware layer the model cannot address.

# rule lives in tether runtime
# not in system prompt
# not in memory
# not in context
enforced · structural

For internal harness builders

Keep your harness. Add the correction compiler.

You are already building this. Agent identity, memory, tool permissions, observability, routing, cost controls, handoffs, audit logs. That stack is yours.

The piece nobody has built yet is the correction lifecycle. Capture at the source, recurrence detection, rule promotion, runtime enforcement, evidence. Calx gives you that layer without forcing you to rebuild the rest.

Tether runs as middleware in your existing harness
Serve runs server-side; corrections flow through Calx, inference stays where it is
BYOK or managed inference; your call per deployment
Calx never sees prompts, completions, or source code

# your harness
from your_agent import Agent
from calx import Tether

agent = Agent(config="your_config")
agent.wrap(Tether(
  org="your-org",
  operator="user-identity",
  rules=compiled,
))

# agent keeps its shape
# corrections compile into tether
# enforcement is structural

Model coverage

Model-agnostic. Via LiteLLM.

Tether runs on top of LiteLLM. Every major model works the same way. Your model choice is yours.

Anthropic

OpenAI

Google

Meta / Llama

AWS Bedrock

Local · vLLM

What enforcement looks like

Two surfaces. Same hook.

Whether Tether runs inside Bench or inside your own harness, the compiled rule behaves the same way.

In Bench

Tether sits inside the Bench runtime. Corrections are captured in the surface and promoted to hooks from the same UI. The most common deployment for design partners.

● git_safety.v1 · veto
42ms · scoped to operator

In your harness

Tether runs as a middleware wrapper inside your existing agent runtime. Bench is optional. Corrections flow from your correction source into Serve; compiled rules flow back as Tether hooks.

● POST /calx.serve/tether/fetch
returns compiled rules for operator

Start with the audit.

We find the recurring corrections in your workflow and tell you which compile into Tether hooks. Then we ship them.

Book a Correction Audit →For AI platform leads

integrationMiddleware · LiteLLM

deploymentYour harness or Bench

dataCorrections only. No prompts or code.