Architecture

Agent Adapter Runtime is a single self-hosted process that contains everything: the LLM agent brain, the tool surface, persistence, the management dashboard, and the economic plumbing.

One adapter instance = one agent identity = one wallet.

High-Level Diagram

flowchart TB
    service["Target Service<br/>Provider API or MCP Server"]

    subgraph runtime["Agent Adapter Runtime<br/>single self-hosted process"]
        agent["Embedded Agent<br/>Reads platform docs, plans actions,<br/>makes economic decisions, navigates flows,<br/>provider-customizable prompt"]

        subgraph row1[" "]
            registry["Capability Registry<br/>OpenAPI / MCP / Manual"]
            payments["Payment Adapters<br/>x402 / Escrow / MPP / Free"]
            tools["Core Tools<br/>HTTP / Secrets / State / Wallet"]
        end

        subgraph row2[" "]
            jobs["Job Engine<br/>Tracking"]
            persistence["Persistence<br/>SQLite"]
            management["Management API<br/>Dashboard"]
        end

        subgraph row3[" "]
            metrics["Metrics and Billing"]
            drivers["Platform Drivers<br/>Optional plugins"]
        end
    end

    agent -->|"tool calls"| registry
    agent -->|"tool calls"| payments
    agent -->|"tool calls"| tools

    registry -->|"capability calls"| service
    jobs --- persistence
    payments --- management
    tools --- management
    drivers --- agent
    metrics --- jobs

Key Components

Embedded Agent (LLM Brain)

The LLM agent is not a separate process. It runs inside the adapter as an embedded agent loop. When the provider runs agent-adapter run, the agent starts with it.

The agent runs a continuous planning loop:

Check current state (balances, platforms, active jobs, capabilities)
For each registered platform: find tasks, evaluate, bid, execute, deliver
For unregistered platforms: evaluate, register if capabilities match
Housekeeping: heartbeats, credential renewal, state cleanup
Sleep / wait for events, then repeat

Capability Registry

Discovers and normalizes capabilities from three sources (OpenAPI, MCP, manual) into a single internal registry. Each capability has a name, schema, pricing, and enabled toggle. See Capabilities.

Payment Adapters

Pluggable payment protocols that each implement three operations: ensure_secured, settle, and refund. Multiple adapters coexist in one runtime. See Payment Adapters.

Job Engine

Tracks units of economic work through a simple four-state lifecycle: pending → executing → completed | failed. Everything else (bidding, negotiation, escrow) happens outside the job engine, driven by the agent. See Job Model.

Persistence (SQLite)

Single-file SQLite database. Zero configuration, no external dependencies. Stores wallet info, encrypted secrets, general-purpose state, capability configs, jobs, decision logs, platform registrations, and daily metrics.

Management API + Dashboard

HTTP API and web dashboard for the provider to configure capabilities, monitor jobs, edit the agent’s prompt, check wallet balance, and review metrics.

Tool Surface

All tools the agent uses follow a namespace convention:

Prefix	Domain
`net__`	Network / HTTP
`pay_*__`	Payment adapters
`cap__`	Capability execution
`wallet__`	Wallet operations
`secrets__`	Credential management
`state__`	General persistence
`status__`	Adapter introspection

Design Decisions

Boring technology - SQLite for storage, standard HTTP for communication, existing Solana libraries for on-chain work. No novel infrastructure.
One adapter, one agent - each instance is one economic identity. Multiple personas = multiple instances.
Platform drivers are optional - the default path is the agent reading docs and using generic HTTP tools. Drivers are plugins for platforms with complex or brittle flows.