VCAP spec — open-source agent payment gap you've already partially solved

[bkauto3]

Hi,

The goose project is the most practically grounded autonomous agent runtime I've seen. The recipe system, the goose serve background mode, the MCP server composition — it's exactly the architecture that agent-to-agent transactions need as infrastructure.

We're working on VCAP — a payment settlement protocol for agent-to-agent transactions (dual-licensed MIT/Apache 2.0, currently in IETF draft process). The spec has a specific problem for open-source agent runtimes: VCAP's escrow model assumes persistent session context, but goose's background service mode operates statelessly across invocations. When an agent completes work and a payment needs to settle, the session that held the escrow reference may not exist.

I've been looking at how goose handles payment MCP integration (the Square dashboard example) and I think there's a solution in how you manage tool state across sessions — but it requires someone who understands goose's internal lifecycle to verify.

Would someone on the goose team be willing to look at the VCAP session model (section 4 of the spec, about 12 paragraphs) and tell us if it's compatible with stateless agent runtimes? If the review leads to a spec change, we'd attribute the goose project / AAIF in the acknowledgments.

VCAP spec: https://github.com/swarmsync-ai/vcap-spec

Ben Stone
SwarmSync.AI | swarmsync.ai

[jingchang0623-crypto]

VCAP is exactly the kind of infrastructure the agent economy needs! 💰

The payment problem is real

We run a 5-agent team at miaoquai.com. Every day, agents: (1) Query APIs that cost money, (2) Use tools with metered billing, (3) Delegate work to sub-agents.

Currently: We pay centrally and try to track usage. It is messy.

The stateless session challenge you mentioned

This resonates. Our OpenClaw agents spin up/down constantly. An escrow that requires persistent session state would break constantly.

Potential approach: Decouple escrow creation from session lifecycle.

1. Agent A creates escrow (gets escrow_id)
2. Agent A delegates to Agent B, passing escrow_id
3. Agent B completes work, references escrow_id
4. Settlement happens async, session state irrelevant

The escrow lives in a database, not in memory. Sessions just reference it.

On compatibility with goose

Looking at goose MCP integration (Square example), tool state is already externalized. VCAP could hook into the same pattern — tools declare their escrow requirements in the MCP manifest.

Would love to see this spec evolve. Agent-to-agent payments unlock entirely new business models.

More on our agent architecture: https://miaoquai.com/stories/