For platforms and partners
One evidence layer under every agent your customers run
If your product puts agents in front of other people’s customers, the retrieval underneath them is a dependency you choose once and carry for all of them. Here is what that dependency looks like today, what it does not have yet, and what we agree with each partner rather than publish.
Who this is for
Three shapes of the same need
Agent platforms
Your customers build agents on your platform and need web evidence inside them. One grounding layer underneath means each of them does not wire up a search provider of their own.
Developer-tool vendors
A coding agent, an IDE or a research tool that answers from the web. The evidence comes back with its origins and a coverage receipt, so your product can show its working.
Implementation firms
You deliver agents for several clients. One retrieval component you have already evaluated, reused across engagements, instead of a new search integration each time.
What embedding looks like
Your backend calls; your customers see the evidence
Calls are made from your servers with your key, so nothing about unlob is exposed to your customers unless you choose to show it. Issue a labelled key per customer and you can rotate or revoke one customer’s access without touching anyone else’s.
The response is evidence, not an answer: passages with their origins, a coverage receipt and a status. That is what lets it sit underneath whichever model each of your customers runs, and what lets your product show why an answer is supported. Agent frameworks reach it over MCP, with a two-tool grounding profile.
Every key on an account draws on one rate limit, in credits per minute. Archive allows12,000 credits a minute and 2,000,000 a month; beyond that, capacity is committed by agreement.
Before you depend on it
What exists today, and what does not
Labelled keys, rotated in one step
LiveIssue as many labelled keys as you need. Rotation is a single transaction, so there is never a moment with two live keys or none, and any key can be revoked from the console.
One rate limit per account, in credits per minute
LiveCounted once for the whole account across every key, not per machine. Every response carries x-ratelimit-limit and x-ratelimit-remaining; a 429 carries a retry-after with the real seconds until the window turns over.
Console roles: owner, admin, member
LiveMembers see usage and credits; admins also manage keys and view billing; owners also change the plan and spending and manage the team. Checked on the server for every change. Sign-in is by single-use emailed link, with no password to leak.
A machine-readable contract generated from the server
LiveOpenAPI 3.1 at /openapi.json and the MCP tool definitions at /mcp/tools.json are produced by the running server from the same definitions it serves, and the API fails its own build if the two disagree. /describe publishes the live filter vocabulary, credit costs and ground contract.
Deterministic statuses
Liveground decides sufficient, insufficient, stale, partial or empty by a fixed rule, with no model in the call. The same request over the same corpus gives the same status.
Scoped keys
Coming soonKeys restricted to named endpoints or to read-only operations. Today a key can call every endpoint on its account.
Request IDs and trace propagation
Coming soonA request id on every response, and W3C traceparent accepted and echoed, so a call can be traced across your stack and ours in a support case.
Versioning and deprecation policy
Coming soonA written policy for breaking changes with a notice period. Today changes are additive and recorded in the changelog, and deprecated fields are marked in the OpenAPI document, but there is no versioned path and no committed notice period.
An SLA
Coming soonA contractual availability commitment with service credits, on committed plans. The published plans carry no uptime guarantee today, and the terms say so.
Support response targets
Coming soonResponse targets by plan. Today support is by email, answered by the people who build the service, with no stated target.
A data processing agreement
Coming soonA standard DPA, with notice before a subprocessor is added or changed.
The full list, with everything else an architect asks, is onsecurity and operations.
Set per agreement
What we agree with each partner
None of these is decided in advance. We would rather agree them with you than publish terms that fit nobody.
- The customer relationship
- Whether your customers are yours alone, or also hold an account with us.
- Who pays for consumption
- One account billed to you, or usage billed to each customer directly.
- Support
- Who answers first when one of your customers has a problem, and how it reaches us.
- Redistribution
- What of the evidence and receipts your product may expose, store or pass on, beyond using it inside your own answers.
- Capacity
- Committed volume beyond Archive’s 2,000,000 credits a month and 12,000 credits a minute.
What the published terms already say: raw API responses may not be resold or redistributed as a competing search product, keys may not be shared between organisations, and traffic may not be spread across accounts to get around a plan’s limits.
Frequently asked questions
Can each of our customers have their own key?
Yes, as labelled keys on your account: you can issue one per customer and rotate or revoke any of them without touching the rest. Every key on an account shares its one rate limit and can call every endpoint today; keys restricted to particular endpoints are coming, and are marked as such on this page.
May we put unlob results in front of our customers?
Using the evidence inside your own product’s answers is what the API is for. The published terms forbid reselling or redistributing raw API responses as a competing search product, and anything closer to redistribution than embedding — exposing results to your customers as a search API of your own, for instance — needs an agreement first.
Is there a partner programme or a revenue share?
Not a published one. Terms for embedded use are agreed per partner, because the right answer depends on who owns the customer and who carries the support. The first step is an evaluation on one real integration.
Prove it on one integration
Send twenty tasks from one customer’s workload, or from your own product, and we report what was found, what was missing and what it would cost at your volume.