Xona Integration

DAEMON should treat Xona as the resource layer for agents and Meterflow as the control plane that makes those resources safe to buy per call.

Best partnership path: Meterflow x Xona first, then DAEMON as the workspace where builders discover, budget, call, and ship with those paid agent resources.

Clean positioning#

Xona is positioned around agentic commerce, x402 resources, paid AI endpoints, and agent-accessible resources. That maps directly to Meterflow's product surface: meters, receipts, provider revenue, agent budgets, allowlists, spend caps, payment failures, and visibility around paid API usage.

The sharp integration story is not a generic partner card. Xona supplies the resources, Meterflow wraps those resources with billing and policy controls, and DAEMON becomes the builder workspace where agents can use them in real projects.

ProductRoleWhat users get
XonaResource layerAgent-callable APIs and resources such as creative generation, token data, Solana Pulse, brand assets, token news, PumpFun movers, and token signals.
MeterflowControl planex402/MPP pricing, route allowlists, spend caps, receipts, provider revenue views, policy failures, and paid-call audit trails.
DAEMONWorkspace layerProject-aware agents that can discover approved resources, run against a budget, call paid APIs, and attach receipts to shipped work.

Why this is good#

For Xona users

Xona resources become safer to consume because teams can set budgets, enforce policy, understand failed payments, and see what each agent spent.

For Meterflow users

Meterflow gets a clear resource marketplace use case: real agent endpoints with pricing, receipts, provider revenue, and budget controls.

For DAEMON users

Builders can use paid agent tools from inside the workspace without turning each API call into a manual checkout or unmanaged wallet flow.

For providers

Resource owners can expose paid endpoints to agents while keeping usage, revenue, and policy state visible.

DAEMON workflow#

  • A builder opens DAEMON and creates or selects a project.
  • DAEMON shows Xona resource packs as available agent resources, with Meterflow policy and budget status next to them.
  • The builder chooses a resource pack, sets a daily or task-level spend cap, and selects which agents are allowed to call it.
  • When an agent needs a Xona resource, DAEMON requests a Meterflow policy check before the call is made.
  • Meterflow enforces the route allowlist, budget, payment protocol, and receipt policy.
  • The Xona endpoint handles the paid resource call and returns the result to the DAEMON agent workflow.
  • DAEMON stores the result with Meterflow receipt metadata so the project has a useful audit trail.

Resource pack model#

DAEMON should expose Xona through named resource packs instead of loose links. A pack can group related endpoints, recommended budgets, agent permissions, and the Meterflow policy needed to call them safely.

PackUseDefault policy
Market intelligenceToken data, token signals, token news, PumpFun movers, and Solana Pulse for research agents.Read-only, project allowlist, daily cap, receipt required.
Creative pipelineImage, video, brand kit, and campaign assets for launch or content agents.Higher per-call cap, explicit project approval, receipt required.
Builder automationPaid resources used by coding, launch, docs, and research agents inside a DAEMON project.Task-level budget, agent allowlist, spend summary on completion.

Meterflow contract#

DAEMON should call Xona resources through a Meterflow-aware contract so paid requests are observable and enforceable before an autonomous agent spends.

Policy-check shape
const policy = await meterflow.evaluatePolicy({
  provider: "xona",
  resourcePack: "market-intelligence",
  route: "/xona/token/pumpfun-movers",
  method: "GET",
  agentId: daemonAgent.id,
  projectId: daemonProject.id,
  paymentProtocol: "x402",
  recordReceipt: true,
});

if (!policy.allowed) {
  throw new Error(policy.reason);
}

const result = await daemon.callPaidResource({
  provider: "xona",
  route: policy.authorizedRoute,
  receiptPolicy: policy.receiptPolicy,
});

Product boundaries#

  • DAEMON should own project context, agent UX, workspace state, wallet prompts, and task receipts.
  • Xona should own the paid resources, endpoint quality, provider catalog, and resource-specific output.
  • Meterflow should own meters, pricing policy, x402/MPP payment handling, receipts, spend caps, provider revenue, and policy failures.
  • DAEMON should not hide payments. Every paid call should leave visible budget and receipt state tied to a projectId, agentId, and task.

Current status#

CapabilityStatus
Xona docs pageDocumented as the resource layer for DAEMON agent workflows.
Meterflow x Xona boundaryDocumented as the first partnership path and control-plane layer.
DAEMON next stepDocumented as the workspace where builders discover, budget, call, and ship with Xona resources.
Automatic spendingNot enabled by default. Paid resource calls should require Meterflow policy checks, budget limits, and receipts.