Revenue is up 12% on the last period — the discount drove 34% of volume.
$0.0041 · 2 tool calls · 1.8 s
create_discount15% off · 34 products tagged “summer” · SUMMER15Enter to confirm · esc to throw it awaycreate_discountOne signed request to your endpoint. Never retried.It is the only question that changes the integration. Both answers reach the same governed layer — the same tenants, capabilities, actions and approvals — so whichever you start with, you keep when the other becomes true.
You already have one
You run an agent with tools, a model you chose and a key you pay for. What you do not have is anything stopping it doing something expensive at three in the morning.
You do not
You have a product, data and a brand. You have never written a prompt and do not intend to. You want the thing your customers talk to.
Your database stays behind your own endpoint, and Tether supplies the model. Two territories, three crossings — all of them HTTP you can read. Watch a turn cross the line.
renders typed blocks; owns every confirm button
your ids ride the headers; credentials never travel
tools are your code, running in your runtime
no connection string exists to leak
checked by your endpoint, on every call
approvals live where they always did
intent decided before any model is called
quota and spend breaker, checked first
provider key is Tether’s — you don’t bring one
mutations pause for a human
blocks validated, repaired, or degraded safely
every token priced and attributed
Turn complete. Three crossings, all of them HTTP you can read — and everything on the left ends the turn exactly where it started. $0.0018
A turn runs when this scrolls into view.
Those surfaces are the front. This is the same turn X-rayed — none of it is your UI. Your users only ever see the question going in (2) and the blocks coming back (5); everything between is Tether’s machinery, labeled in reading order.
Intent resolved with pattern rules — no model call. Cheap turns stay cheap.
Plan quota, then the spend breaker — refused before the call, not billed after.
Cached context, remembered preferences, retrieval over your docs.
A signed envelope to your endpoint. Results feed back into the loop.
Writes stop here as pending actions. Your endpoint is not called.
Validated typed blocks, pending actions, and the exact cost of the turn.
1 who’s calling — identity comes from the API key, never the request body
X-Api-Key tth_9f…e2 · tenant 42 · scope 9 · plan growth2 your user’s question — free text, typed in your product
3 the governed path — every turn crosses the same six checkpoints, in order
4 what Tether did — the turn’s trail, also stored as audit + ledger rows
5 what your UI gets back — typed blocks and the exact cost; you render them
Typed blocks render here — pick a prompt above.
refund_order · #4821$129.90 to the original card · expires in 14 minA write tool never calls your endpoint during a turn. It becomes a pending action; someone confirms; a compare-and-set claims it; it executes once.
That’s your product on the left — the card arrives off pending_actions, styled like the rest of your UI. Confirm the refund, then try to confirm it again.
One signed HTTPS request to a URL you control, with arguments you can read before you answer. There is no connection string for anyone to leak.
The amount in the body is a real input — type your own and watch the request die at your door.
Learn about the trust boundary →
POST /tether/invoke
X-Tether-Signature: sha256=9d41…c7 // over the original bytes
X-Tether-Timestamp: 1755691200
X-Tether-Idempotency-Key: 41af22c0
{
"tool": "refund_order",
"arguments": { "order_id": "4821",
"amount": },
"tenant": { "organization_id": 42, "scope_id": 9 },
"is_write": true, "mode": "execute"
}hmac(secret, ts + "." + body)ledger · tenant 42 · append-only
breaker · refused before the call — budget_exceeded
Every turn writes an append-only ledger row — input, cached, cache-write and reasoning tokens priced separately. Budgets are checked before the model is called, and an unpriced model bills at the worst known rate, never zero.
Keep running turns until the breaker stops you.
Learn about turns and ceilings →The model is offered exactly the catalog you registered — nothing else exists for it to call. Read tools run in parallel through signed envelopes and stream back into the turn.
The write lane stops at the confirm ring until a person decides. Watch it hold while the reads finish around it.
Learn about reads and writes →
{ "name": "refund_order",
"is_write": true,
"risk": "high", … }Whether a tool can mutate is declared at registration — and a catalog that leaves it ambiguous is rejected before it can ship.
Learn about the catalog →"blocks": [
{ "type": "kpi", … },
{ "type": "table", … } ]Answers validate against a schema, get repaired once if malformed, then degrade to plain text. Your frontend renders blocks instead of parsing prose.
Learn about the contract →tenant ← api key body.organizationId ignored tool args org_id ignored
Scope comes from the API key. The request body and the model’s arguments are ignored, and confirmation re-checks the boundary before any write runs.
Learn about tenancy →Your data stays where it is, and anything that can serve HTTPS can hold the other end of the tether. If yours is Node, Python or .NET, a library will write the awkward parts for you.
PUT /v1/tools
[ { "name": "get_low_stock",
"description": "Items under their alert point.",
"is_write": false, "parameters": { … } },
{ "name": "refund_order",
"description": "Refunds an order.",
"is_write": true, "risk": "high",
"parameters": { …, "required": ["order_id"] } } ]→ 200 · registered · version 4 · 12 tools, 3 writesWhether a tool can mutate is declared at registration, never inferred — that declaration is what routes it into the staged-write path. The same validation runs standalone at POST /v1/tools/validate, so a broken catalog fails your CI instead of your users.
app.post("/tether/invoke", (req, res) => {
verifyHmac(req) // sha256 over timestamp.body
const { tool, arguments: args, tenant } = req.body
assertAllowed(tenant.user_id, tool) // your rules
res.json(runTool(tool, args, tenant)) // your code,
}) // your database→ writes arrive only after confirmation · mode: "execute" · stable idempotency keyTether reaches your data one way: this request. Your permission checks run here, on every call — and a write only ever arrives after a human confirmed it, carrying mode: execute and an idempotency key you can dedupe on. In Node, Python or .NET, an SDK owns the signature, the timestamp window, that execute-mode check and the replay — and you write only the function.
POST /v1/chat X-Api-Key: tth_9f…e2 // server-to-server X-Tether-User-Id: 7 // your user, your ids { "prompt": "Which products are almost out of stock?" } → { "blocks": [ { "type": "kpi", … }, { "type": "table", … } ], "pending_actions": [], "usage": { "usd": 0.0018 } }→ typed blocks your UI renders · anything staged waits in pending_actions
Your backend forwards the prompt; Tether routes it, gates it, calls your tools, and returns blocks your UI renders — seven types, rendered once, styled like your product. No iframe, no widget, nothing of ours in your page.
What Tether does, where it fits, and when to use something else.
Read →20 minutesQuickstartRegister a catalog, expose one endpoint, get a first structured answer.
Read →The core mechanicYour first writeStaging, confirming, and executing exactly once, end to end.
Read →OptionalSDKsNode, Python and .NET. Write the tool functions; they do the rest.
Read →No. Tether supplies and operates the model — which one runs, and how many tokens and tool turns it may spend, comes from your plan. You bring a tool catalog and one HTTPS endpoint. Every turn returns its exact cost, priced from an append-only ledger.
You do — Tether is headless on purpose. Turns return seven typed block types (text, KPI, table, ranked list, stacked bar, footnote, quick replies) plus any pending actions to confirm. Render each type once and every answer arrives styled like your product. No iframe, no widget.
Either. The endpoint is a signed POST and a JSON body, and the docs show it implemented by hand in about twenty lines. There are also libraries for Node, Python and .NET that own the four parts that are easiest to get wrong — the signature, the timestamp window, refusing a write that did not arrive confirmed, and replaying a repeated request without running your function twice — leaving you the tool functions. None is on a registry yet; pilot customers get the source. Nothing about the integration requires one.
Tether holds no credentials to your systems. Within a turn it sees exactly what your endpoint chooses to return for a given tool call — nothing more. It stores conversations, staged actions, spend and telemetry; it has no tables for your business records.
No. A tool declared as a write never calls your endpoint during a conversation. It becomes a pending action, a person confirms it through a separate authenticated call, a compare-and-set claims it, and it executes once.
The tool call fails as a structured result the model can explain — “that lookup failed” — rather than crashing the turn. Reads are retried up to three times on transient failures with backoff.
A timed-out write is ambiguous: it may have landed with only the response lost. Retrying it is how one confirmation becomes two refunds. Every write carries a stable idempotency key, so you can retry safely on your side — where you can actually check.
Scope comes from the API key — never from the request body, never from the model’s tool arguments. Catalog, endpoint, budget, history and memory are all per-tenant, and confirmation re-checks the tenant boundary before any write executes.
Responses are capped at 256 KB. Past that, the result is refused and the model is told, instead of an oversized payload poisoning the context window and billing you for it.
One provider today, stated plainly. The boundary — staged writes, budgets, isolation, typed output — is designed to outlive whichever model sits behind it, but multi-provider support does not exist yet.
Not yet. There is no packaged self-hosted distribution today.
Conversations, staged actions and their execution records, an append-only spend ledger, request telemetry, extracted user preferences, and any documentation you ingest for retrieval. Orders, customers and inventory stay in your systems.