One job. Many retries. One settlement.
OneShot is a settlement engine for companies building AI agents that purchase paid tools and services. It keeps one approved business obligation tied to at most one committed settlement, even when a job retries, crashes, or loses the payment response.
Early-stage prototype · Arc Testnet only · Seeking feedback and pilot partners.
Discuss an integration or pilot · Developer guide · Architecture
An agent pays for a service. The connection drops before the receipt arrives. A replacement agent cannot tell whether payment succeeded. Retrying can pay twice; stopping leaves the job unfinished and an operator investigating.
OneShot gives retries a durable identity and preserves payment evidence. An
uncertain payment enters UNKNOWN and must be reconciled before any decision
to retry payment. A missing or delayed index result never proves non-payment.
The goal is to help teams recover interrupted agent workflows with a clear record of what was approved, attempted, and settled.
Our initial focus is B2B teams building AI agents that buy paid API operations or digital results. Companies running those agents internally are prospective buyers; platforms selling services to agents are prospective integration partners.
A representative workflow is an agent buying a company report. If payment succeeds but delivery fails, a replacement agent resumes the original job and retrieves its result without a replacement payment. Supplier delivery recovery requires the supplier to support stable order identity and result retrieval.
- Record the obligation. One stable business intent survives retries, restarts, and multiple agent instances.
- Control settlement. Durable, atomic state grants submission ownership; authorization and spending policy constrain the worker-owned wallet action.
- Resolve uncertainty. Reconcile ambiguous outcomes against provider and Arc receipt evidence. Hold unresolved payments for further investigation.
- Resume delivery. Keep the supplier result separate from settlement so downstream failures do not erase an existing payment.
1 Business Intent / N Attempts / at most 1 committed Settlement
OneShot owns intent and settlement state. Privy provides wallet access and scoped authorization on the worker-owned settlement path; Arc provides the USDC settlement rail. The Graph discovers recovery candidates and supplies observations, while Arc verifies them. Index results and model advice cannot authorize settlement.
Browser and MCP user-wallet flows use a separate payer-bound path: the user's wallet signs and broadcasts the transaction, and OneShot verifies its receipt. An MCP bearer authenticates a workspace; it cannot sign or broadcast payments.
| Area | Current evidence and limits |
|---|---|
| Settlement engine | Durable intent ledger, API, settlement workers, and reconciliation core are implemented. |
| Testnet payment and recovery | Repository evidence records a live 1.00 USDC Privy-authorized Arc Testnet settlement, policy denials with zero broadcasts, and a lost-response drill that recovered the original settlement without another payment. |
| Agent and operator access | Browser workspace and MCP tools arc_payment and arc_payment_submit are implemented. A live end-to-end MCP payment trace remains pending in the documented status. |
| Paid job delivery | A team-operated testnet report supplier supports task/order binding and separate delivery/result retrieval. Third-party supplier execution is not demonstrated. |
| Graph recovery | Studio GraphQL discovery is implemented. Fresh live evidence of its material effect on model-assisted recovery remains pending; sponsor qualification is not verified. |
See live settlement evidence and the qualification report for the recorded runs and their limitations. These are prototype evidence, not production-scale validation. Mainnet is disabled.
OneShot is built by a two-person team and is currently validating its customer problem. We do not yet have customers, paying pilots, or a validated customer feedback loop. Pricing is undecided; subscription and per-transaction models are options to test with prospective buyers.
Our next priority is customer discovery with agent builders and internal automation teams, followed by a narrowly scoped pilot. We want to understand how teams handle ambiguous payments today, what recovery costs them, and where OneShot would fit into their existing stack.
We are also seeking service-platform partners to test payment and delivery recovery together. Broad supplier support and exactly-once execution of arbitrary tools are outside the current demonstrated scope.
Building agents that purchase services, running them inside your company, or selling tools to agents? We would like to hear how you handle retries and lost payment responses, and discuss a technical integration or early pilot.
| Resource | Purpose |
|---|---|
| Developer guide | Local setup, operator sign-in, repository layout, API routes, and state machine |
| Domain architecture | Ownership, domain model, and system boundaries |
| Agent connection guide | MCP deployment, client configuration, and walkthrough |
| Recovery hardening | Recovery, authentication, and operational contracts |
| Product plan | Scope, roadmap, and delivery gates |
| Contribution policy | Repository policies and review requirements |
MIT. See LICENSE.