How the gateway is actually built
The guarantees come from the code, not the copy
Four mechanisms are actually implemented today: versioned price quotes, durable attempt records with effect-aware retry, a fixed six-tool surface over a growing catalog, and an honest lifecycle model that never confuses "listed" with "live."
Exact price basis, quoted before you run
Pricing isn't a number typed into a page. It's a record in the same system that executes the run, scoped to one operation and one version of that operation.
Nothing silently retried, nothing silently charged twice
A run is a sequence of attempts, and every attempt is a row, not a log line. When an outcome is unclear, the run stops in a reconciliation-pending state instead of guessing and moving on.
Six tools, however large the catalog gets
An AI client connects to looot once and gets discover, inspect, run, runs_get, runs_list, and balance. Nothing else. Every operation the catalog adds is data those six tools read, not a seventh tool.
One taxonomy, five levels, no shortcuts
Every operation in the catalog sits at a fixed position: category, capability, operation, operation version, provider implementation. Nothing skips a level.
| Level | Example | What it pins down |
|---|---|---|
| Category | e.g. company data | A grouping for humans browsing the catalog. |
| Capability | e.g. web.search, company.enrich, media.generate | The dot-scoped identifier an operation is filed under. This is what discover actually searches on. |
| Operation | one row per provider integration | A specific provider's implementation of a capability — its own input shape, its own pricing, its own eligibility. |
| Operation version | semantic version per operation | The contract: input schema, output schema, effect (read, write, or outreach), idempotency behavior, retry eligibility, allowed hosts. Versions don't get edited in place. |
| Provider implementation | fixture today, live adapter later | The thing that actually executes the version's contract. Today that's a deterministic fixture for every shipped operation. |
Cataloged does not mean connected
An operation carries five independent status fields, and every one of them has to clear before a run is allowed to hit it. Being in the catalog answers exactly one of these five questions.
| Status field | States | Question it answers |
|---|---|---|
| catalog | candidate → cataloged → revoked | Is it in the catalog at all. |
| readiness | none → contract reviewed → adapter ready → sandbox verified | Has the integration itself been checked. |
| connection | absent → connected → invalid → revoked | Does this tenant have working credentials for it. |
| rights | unknown → internal-only / BYOK approved / partner approved → prohibited | Are we legally allowed to run it this way. |
| production | disabled → allowlisted → enabled → paused | Is it actually switched on for traffic. |
Today, every shipped operation runs against a deterministic fixture. Nothing on this page describes a live provider connection, live billing, or a production claim we haven't earned yet — the local demo needs no account or provider key, and production connections stay fail-closed until they're configured and approved.