Agents that cannot pay for tools stay dependent on humans for every API key and checkout page. Nous Research's Hermes Agent just crossed that line with three optional payment skills built around Stripe.
Install them with:
hermes skills install official/payments/stripe-link-cli hermes skills install official/payments/mpp-agent hermes skills install official/payments/stripe-projects
Each skill wraps a CLI, not a new core tool. Zero changes to Hermes' default tool surface. That design choice matters: payments stay opt-in, auditable, and platform-gated (linux and macos only until Stripe Link supports Windows).
Three skills, three money flows
| Skill | Wraps | Agent can |
|---|---|---|
stripe-link-cli | @stripe/link-cli | Complete web checkout with one-time virtual cards or Shared Payment Tokens |
mpp-agent | MPP clients (mppx, Tempo, Privy, AgentCash) | Pay HTTP 402 APIs per request |
stripe-projects | Stripe Projects CLI plugin | Provision SaaS (Neon, Vercel, Twilio, etc.) and sync creds to .env |
Together they cover the loops agents actually need: buy a tool on the web, pay for a metered API mid-task, spin up infrastructure without a human copying API keys.
Stripe Link: checkout with approval, not autopilot
The stripe-link-cli skill routes spend through Stripe Link. Hermes creates a spend request, pings the user's Link mobile or web app, and polls until approval or denial. Hermes cannot self-approve.
That is the safety story AlphaSignal highlighted and the docs reinforce:
- Real card credentials never enter the agent conversation history
- One-time virtual cards for standard checkout forms
- Shared Payment Tokens (SPT) when merchants return HTTP 402 with
method="stripe" - Scoped credentials deleted after use where applicable
Typical web checkout flow:
link-cli spend-request create \ --payment-method-id <pm_id> \ --merchant-name "Example SaaS" \ --merchant-url "https://example.com/checkout" \ --context "Annual plan for staging database" \ --amount 9900 \ --line-item "name:Pro plan,unit_amount:9900,quantity:1" \ --total "type:total,display_text:Total,amount:9900" \ --request-approval
For MPP merchants add --credential-type shared_payment_token. The skill explicitly warns: never cat virtual card files into the model context. Hand file paths to browser automation or dedicated tools.
You can also run Link as MCP:
hermes mcp add stripe-link --command "npx" --args "@stripe/link-cli --mcp"
Same approval rules. MCP does not bypass the human gate.
MPP: when the API bills per call
Machine Payments Protocol targets APIs that respond with HTTP 402 Payment Required and a www-authenticate challenge. The mpp-agent skill wraps several wallets:
| Client | Best when |
|---|---|
link-cli mpp pay | Challenge advertises method="stripe" or user already uses Link |
mppx | Quick paid calls and debugging |
| Tempo Wallet | Persistent spend controls and service discovery |
| AgentCash | 300+ pre-priced APIs on one USDC.e balance |
Default routing logic from the skill: if Stripe is in the challenge or Link is configured, prefer Link so spend goes through the approved card path. Pure Tempo-only challenges need the matching wallet.
This is the difference between an agent that logs 402 and stops versus one that completes the paid request and continues the task.
Stripe Projects: agents that provision SaaS
The stripe-projects skill wraps Stripe's Projects plugin. Hermes can add providers, provision resources, rotate credentials, and write secrets into the project .env via the vault.
stripe projects add neon/database
The CLI provisions in the user's own provider account, generates credentials, and records resources in .projects/vault/. That is how an agent could stand up a database or hosting tier without a human copying keys from five dashboards.
What this unlocks (with guardrails)
Real workflows I would pilot on a sandbox card with tight limits:
- Self-funding research agents that pay for premium data APIs per query
- Overnight builders that buy a domain or SaaS tier after human-approved spend caps
- Integration agents that provision Neon + Vercel + auth providers through one Stripe Projects flow
What I would not do on day one:
- Point these skills at production billing accounts without per-merchant allowlists
- Skip spend caps because "the agent is smart"
- Run on Windows expecting Link CLI support (not yet)
Nous shipped this as Phase 1 of a Stripe collaboration cluster. Phase 2 adds MCP shortcuts; Phase 3 may add plugin tools with structured I/O. The skills-only path is the right place to validate behavior before hard-wiring payments into core agent tools.
Relation to other Hermes work
Hermes already ships rich agent primitives: blank-slate tool loading, subagents, iMessage reach, and a large optional skills catalog. Payments fill the last missing wallet layer. The architecture stays consistent: optional skills, explicit install, human approval for money movement.
If you are building agents that need to complete commercial loops (not just suggest them), Stripe's guardrails plus Hermes' skill model are a credible pattern. The agent proposes, the human approves in Link, credentials stay out of context.
Bottom line
Wallet-less agents are fine for demos. Production agents that research, buy tools, and provision infra need payment skills with hard gates. Hermes' Stripe trio is the clearest open-source packaging I've seen for that, as long as you treat approval flows as part of the product, not an annoyance to bypass.
Need help designing agent commerce with spend caps, audit logs, and CRM-safe credential handling? Book a free call. Payment wiring is where agent demos usually break in production.