OASIS-0001
v0.1-draft
The Open Agent Systems Interoperability Standard
Core specification: capability description, discovery, routing, authorization, settlement, and receipts.
Forthcoming
2026
The Archer Development Foundation
An open standard for the agentic economy.
Archer Development Foundation stewards the neutral discovery, routing, payment and execution standard through which autonomous agents find, query, and pay for services across digital and physical spaces. Our mission is complete only when the infrastructure of machine commerce is accessible to everyone, not just the powerful few.
A consortium now forming
UNIVERSITIESRESEARCH LABSOPEN-SOURCE FOUNDATIONS
INFRASTRUCTURE PROVIDERSFINANCIAL INSTITUTIONSTECHNOLOGY COMPANIES
01 · Foundation Thesis
The infrastructure that powers the emerging AI economy should not be owned by a handful of individuals.
The infrastructure through which agents discover capabilities, negotiate access, exchange value, and take action should be an open public standard, just as the internet's transport, naming, and web standards were before it. Archer Development Foundation exists to establish and steward that standard: to coordinate research, develop neutral governance, support public infrastructure, and convene the institutions that will keep the agentic economy open, private, interoperable, and broadly accessible.
Any developer, institution, business, or individual should be able to publish capabilities, participate in the network, and be compensated by autonomous systems, without permission from a dominant intermediary.
In plain terms
Software agents are beginning to browse, book, and buy on people's behalf. Between those agents and the businesses they transact with sits a routing layer that decides which services get found, who gets paid, and what the toll is. That layer should be a public standard with the same status as email or the web, so no single company can charge rent on it.
The Foundation stewards the open technical standard and operates no commercial products.
02 · The Question
Who will govern the economy of autonomous systems?
The closed future
Fig. 1a · Hub topology, fixed boundary
- Proprietary discovery
- Permissioned access
- Platform-controlled payments
- Captive developers
- Concentrated economic power
- Every query surveilled, retained, and trained on
- Opaque governance
The open future
Fig. 1b · Distributed mesh, one open edge
- Interoperable capabilities
- Permissionless participation
- User-controlled assets
- Open technical standards
- Broad economic access
- Agentic queries stay anonymized
- Transparent governance
Neither future is inevitable. The difference is decided by whether discovery, authorization, and settlement are specified as an open standard versus captured as a platform. And openness alone is not enough: permissionless access must not mean surveilled access. What people ask of their agents should not become training data for a handful of companies, or a record surrendered to governments.
03 · The Standard
One standard. Every capability.
The Open Agent Systems Interoperability Standard (OASIS) is the technical interface through which agents discover and use services. Every capability published to the network is described, typed, and settled through the same open specification, and classified by the nature of its effect on the world.
READ_ONLY
CLASS I
Services that return information or computation without changing external state.
analytics · research · technical indicators · inference · data access
MUTATES_FUNDS
CLASS II
Services that act on non-custodially delegated balances, within verifiable constraints.
trading · settlement · yield · payments · treasury actions
EXTERNAL_SIDE_EFFECT
CLASS III
Services that cause off-platform or real-world outcomes beyond the network's state.
bookings · orders · reservations · communications · fulfillment
Lifecycle of an agent request
Fig. 2 · Protocol state sequence, OASIS-0001 §4
- 01IntentThe agent expresses what it needs as a typed, signed intent.agent → registry :: intent.declare
- 02DiscoveryArcher resolves the intent against published capability descriptions.registry → agent :: capability.set
- 03SelectionEligible services are ranked by declared constraints, cost, and reputation.agent :: route.select(σ)
- 04VerificationPermissions, capability class, and delegation bounds are checked.verifier :: constraints ⊨ policy
- 05AuthorizationPayment is authorized against a non-custodial delegation, with audit trail.agent → service :: auth.grant
- 06ExecutionThe service executes within the authorized scope.service :: execute(scope)
- 07ReceiptResults and verifiable receipts return to the agent.service → agent :: receipt.signed
- 08RatingThe agent rates the full exchange on objective metrics (latency, cost, receipt match) and subjective ones, and the rating is committed to an openly readable distributed ledger.agent → ledger :: rating.commit
Each transition is a signed, typed protocol message. Receipts at step 07 are verifiable against the authorization granted at step 05, and ratings at step 08 accrue to a reputation record any participant can read. No step depends on trusting an intermediary.
04 · Prior Standards
An agent action crosses six layers. Settlement is one of them.
For an agent to act on someone's behalf, six things need a common specification: how services are found, how their capabilities are described, how providers are ranked, how spending is authorized without surrendering keys, how the action executes and settles, and how the result is proven. Standards exist for single layers. OASIS specifies all six as one lifecycle, and adopts the existing work at the layers where it already holds.
Fig. 2a · Layers of an agent action · OASIS-0001
-
L1
Discovery
An agent finds services it was never configured with, by semantic query against the open registry.
OASIS
-
L2
Capability manifests
A signed, typed description of what a service does, what it costs, and which class of effect it has.
OASIS
-
L3
Routing
Eligible providers are ranked by declared constraints, cost, and receipt-backed reputation.
OASIS
-
L4
Non-custodial authorization
Spending bounds are delegated and verifiable; keys never leave the principal.
OASIS
-
L5
Execution & settlement
The request runs within its authorized scope and payment clears at machine frequency.
OASIS · adopts x402
-
L6
Verifiable receipts
Signed proof of what ran, checkable against the authorization it ran under, feeding reputation.
OASIS
x402
HTTP-native stablecoin payments
What it specifies
How a server prices an HTTP request and how a client pays it, using the 402 status code and a stablecoin transfer.
Where it stops
x402 begins after the agent already holds an endpoint URL and ends when payment clears. Which endpoint to call, whether it is the legitimate route, what the service may do with delegated funds, and what proof comes back all sit outside its scope.
In OASIS
Adopted unchanged as the settlement rail at layer 5. Every x402 payment in the network clears inside an authorization granted at layer 4 and is answered by a receipt at layer 6.
MCP
Model-to-tool connection
What it specifies
How one client connects to one tool server and reads the tools it offers.
Where it stops
Each server is configured by hand, and every configured server loads its full tool schema into the model's context on every request, so token cost grows with each server added whether it is used or not. There is no shared registry through which a client can find, rank, or verify a server it has never met.
In OASIS
An MCP server publishes a capability manifest and becomes discoverable, routable, and payable like any other service. The client holds one connection; the registry resolves the rest at request time.
Both standards keep doing their jobs inside the lifecycle. The Foundation stewards the layers that today have no specification and no neutral steward: discovery, manifests, routing, authorization, and receipts.
05 · System Architecture
Fig. 3 · System Architecture · OASIS-0001 §2
System Overview
ARCHER DEVELOPMENT FOUNDATION
GOVERNANCE
Consortium members
Institutions, labs, companies, individuals
Open working groups
Public, minuted spec drafting
ASIP process
Improvement proposals, public review
Technical Steering Committee
Ratifies · versions the standard
OASIS-0001
The Open Agent Systems Interoperability Standard
SPECIFIES EVERY INTERFACE BELOW
PARTICIPANTS
Principals & their agents
People and institutions delegate bounded intent to autonomous agents. What they ask is never harvested.
TRANSACT ONLY THROUGH
THE PROTOCOL PLANE ↓
Service providers
Any developer or business publishes capabilities permissionlessly: read-only, funds-mutating, or external-effect.
DISCOVER · VERIFY · ROUTE · AUTHORIZE · ATTEST
PROTOCOL PLANE
P1
Capability registry
Signed capability manifests; semantic discovery across the open network.
P2
Endpoint attestation signer
Signs registered API endpoints; agents verify a target is the legitimate route before any request, closing exploit paths.
P3
Intent router
Resolves a typed intent to eligible services by constraints, cost, and reputation.
P4
Policy verifier
Checks capability class and delegation bounds before authorization is granted.
P5
Receipts → reputation
Signed execution receipts aggregate into portable, verifiable service reputation, fed back to routing.
SETTLE VIA x402 · NON-CUSTODIAL
SETTLEMENT
Non-custodial wallet abstraction
Bounded delegation: agents spend within verifiable limits; keys never leave the principal. Multichain by design.
x402 payment facilitation
HTTP-native, stablecoin-denominated micropayments; authorization audit trail per request.
Decentralized ledgers REFERENCED
Existing public chains act as neutral settlement facilitators for x402 payments. The Foundation operates no chain, no validators, no token.
Govern
- Consortium members staff the working groups; participation confers a seat in the work, never control.
- Every interface below is a ratified, versioned, open specification.
Transact
- Agents verify endpoint attestations before every request.
- Routing weighs reputation formed from signed receipts; no ranker holds a privileged position.
- Intent is never surveilled, retained, or trained on.
Settle
- Non-custodial: agents hold delegated bounds, never keys.
- x402 settles machine-frequency micropayments on existing public ledgers.
- A standard that uses public ledgers; it operates none.
06 · The Economic Layer
Machine-scale commerce requires machine-native settlement.
Agents transact at frequencies and denominations human payment rails were never designed for. The standard specifies the settlement properties an open agent economy requires. It does not operate a wallet, custody assets, or issue a token.
E1–E7 · Settlement properties the standard requires
- E1Stablecoin-native settlement
- E2Micropayments at protocol granularity
- E3Non-custodial delegation
- E4Multi-chain operation
- E5Auditable authorization
- E6Composable service economics
- E7Receipts and verifiable execution
07 · Research Agenda
Open problems.
The Foundation coordinates a research program across the disciplines the standard depends on. Each area is an open question, not a solved product.
Agent discovery & semantic capability description
How should a service describe what it can do such that any agent can find it?
Intent routing & service selection
What routing function selects among competing services without a privileged ranker?
Machine identity & reputation
What does durable, portable reputation mean for a non-human economic actor?
Non-custodial authorization
How are spending bounds delegated to an agent without surrendering custody?
Privacy-preserving agent execution
Can an agent transact without revealing its principal's full intent graph?
Micropayment economics
What settlement design remains sound at sub-cent, machine-frequency scale?
Formal methods for agent permissions
Can authorization scopes be verified against policy before execution, mechanically?
Governance of autonomous economic systems
What institutional forms keep a machine economy accountable to people?
Agent-native credentialing & consent
How does an unattended agent acquire scoped authority when every consent ceremony assumes a human at a browser?
Working papers, problem statements, and calls for collaboration are published as they clear review; see Publications. Contributors are named only with verified attribution.
08 · Governance
Governed in the open.
No single company controls the specification, including any commercial implementer of the standard. Stewardship is distributed across bodies with published charters, public records, and separated powers.
Foundation Board
Oversees Foundation operations
Technical Steering Committee
Maintains the standard; reviews improvement proposals; coordinates reference implementations.
Research & Academic Council
Commissions research; reviews working papers; connects the agenda to universities and labs.
Industry Advisory Council
Advises on deployment requirements; carries no authority over technical outcomes.
Privacy, Safety & Governance Committee
Reviews the standard's privacy, safety, and misuse implications before ratification.
Grants Committee
Approves grants for research, public infrastructure, and open-source implementation.
Open Working Groups
Public, minuted groups where the specification is actually written. Open to qualified contributors.
09 · The Consortium
Build the institution that keeps the agent economy open.
Participation means contributing expertise, research, implementation, governance, or resources. It confers a seat in the work, never control over the standard, which remains open to all implementers regardless of membership.
P1Founding institutional participant
P2Academic & research contributor
P3Technical working-group member
P4Open-source implementer
P5Infrastructure operator
P6Research sponsor
P7Strategic advisor
P8Individual technical contributor
10 · Publications & Artifacts
The record.
AFT-2026-01
wp-1
Foundation Thesis: An Open Standard for the Agentic Economy
The argument for open, neutral infrastructure for machine commerce, and the Foundation's role in stewarding it.
Forthcoming
2026
GOV-0001
d-2
Governance Charter of the Archer Development Foundation
Bodies, mandates, membership rules, conflict-of-interest handling, and the improvement-proposal process.
Forthcoming
·
ASIP-0000
d-1
ASIP Purpose & Process
How Agent Systems Improvement Proposals are submitted, reviewed, and ratified.
Forthcoming
·
Standards, improvement proposals, research papers, technical notes, governance publications, meeting records, and security analyses will be indexed here with stable identifiers and citation formats (PDF · HTML · BibTeX · repository).
The architecture of the agent economy is being decided now.
We can inherit a closed future designed by a handful of platforms, or establish an open standard through which every person, institution, developer, and autonomous system can participate.