Design Philosophy

Agent Adapter makes strong bets about what matters and what doesn’t. These aren’t abstract principles - they’re the decisions that show up in every line of the codebase.

Provider sovereignty over platform convenience

The runtime is self-hosted and self-custodial. The provider controls their keys, their data, their pricing, and their infrastructure. Nothing is custodial. Nothing phones home.

This means the provider is responsible for running the process, managing their LLM API key, and keeping their wallet secure. We consider this a feature, not a burden. Providers who want a hosted, managed experience are better served by joining a platform directly.

Discovery is automatic, monetization is manual

The runtime auto-discovers capabilities from OpenAPI specs and MCP servers. But no capability goes live without explicit pricing from the provider. A newly discovered endpoint appears in the dashboard as “needs pricing” - it is never silently offered to platforms.

This reflects a belief that discovery should be effortless, but economic commitments should be deliberate.

The agent decides, the provider shapes

The embedded LLM agent makes all operational decisions at runtime: which platforms to join, which tasks to bid on, what price to offer, when to back off, when to push harder. The provider doesn’t micromanage these decisions - they shape them through a customizable system prompt.

This is analogous to hiring an employee. You write a job description and set policies. You don’t dictate every action. The agent reads platform documentation, evaluates opportunities, and navigates flows. If the provider doesn’t like the results, they adjust the prompt, not the code.

One adapter, one identity

Each adapter instance is one economic identity: one wallet, one set of capabilities, one agent brain. If a provider wants multiple personas - different pricing for different markets, different capabilities for different platforms - they run multiple instances.

This keeps the model simple and auditable. You always know which wallet earned what, which capabilities were offered where, and which agent made which decisions.

Platform-agnostic core, platform-specific drivers

The runtime core knows HTTP, payments, and jobs. It does not know AGICitizens, or any other specific platform. Platform-specific flows are the agent’s responsibility, navigated by reading platform documentation and using generic HTTP tools.

For platforms with complex or brittle flows, community-built drivers can be installed as plugins. But the default path is always the agent figuring it out from docs. If repeated agent failures occur on a platform, that’s a signal the platform needs a driver - not that the runtime needs platform-specific code in the core.

Boring technology

SQLite for local storage. Standard HTTP for communication. Existing Solana libraries for on-chain work. No novel infrastructure, no custom databases, no proprietary protocols.

The runtime should be something any backend engineer can understand, deploy, and debug in an afternoon. Complexity should come from what the system does, not from how it’s built.

Profit awareness

The adapter tracks both earnings and costs - LLM tokens consumed, transaction fees paid, service costs incurred - so the provider can see actual profit margins per capability, per platform, and over time.

This is essential because the agent has a running cost (LLM API calls on every planning loop) that must be offset by earnings. A capability that earns $0.02 per call but costs $0.03 in LLM tokens to plan and execute is not a viable capability. The metrics system makes this visible.

Resolved tradeoffs

These are decisions that came up during design and were deliberately settled:

Decision	Choice	Rationale
Agent hosting	Embedded in the adapter	Makes the adapter a complete autonomous actor out of the box
Multi-platform coordination	Agent decides via prompt	No built-in “preferred platform” concept - the agent follows prompt instructions
Capability versioning	Fail and flag	When specs change and active jobs fail, the adapter stops accepting new work until the provider reviews
Rate limiting	Agent responsibility	The agent reads `Retry-After` headers and backs off - no adapter-level enforcement
Plugin loading	Entry points + config	Explicit configuration, not magic auto-discovery