Circle · 2026 · Design Lead, Agent Stack
Agent Stack
From infrastructure to product: turning Circle's financial primitives into something agents can use and humans can safely fund, control, and trust.
- 460+
- Endpoints across 18 providers, structured into agent-readable capabilities
- 15
- Initial recipes turning payable services into end-to-end workflows
- $0.02–0.05
- USDC per run of a real paid-agent workflow I built and ran twice weekly
The problem
Agents were getting good at real work, and giving them money created new product problems. Circle had the infrastructure: wallets, USDC, payments, cross-chain transfers, contracts, APIs. It didn’t have a product an agent could understand or a human could safely fund, control, and trust.
I led design across the Agent Stack: the Circle CLI, Agent Wallet, the Agent Service Registry, skills and recipes, Portal’s management experiences, and the first-party agent. Formally Design Lead on the CLI and Registry; in practice, the whole journey.
The system
The Agent Stack was never one product. The design problem was the seams.
- Humanfunds, delegates, reviews
- Portalwallets, authority, activity
- Agent WalletUSDC with spending controls
- Host agent + CLIClaude, Codex, Cursor
- Skills & recipeswhat it can do, how
- Service Registrypaid services, x402
| The user's question | What answers it | Which part of the loop |
|---|---|---|
| What can my agent do? | CLI capabilities, skills, recipes | Agent operates |
| What services exist? | Service Registry · agents.circle.com | Agent operates |
| How does it do useful work? | Recipes + the execution model | Agent operates |
| How do I give it money? | Agent Wallet + Portal | Human grants access |
| What authority does it have? | Spending policies and wallet controls | Human grants access |
| What happened with my money? | Runs, receipts, outcomes | Human reviews |
| Can I trust it? | Controls, approvals, identity, private execution | Human reviews |
01 · What can my agent do?
Dogfooding found the first gap. I installed the CLI, funded an agent, asked “what can you do?” and got an incomplete answer. The infrastructure was there; the agent had no context to reason about it. Installation wasn’t activation.
I built three skills. Capabilities: 460+ endpoints across 18 providers, organized by goal, pricing, combinations, and limits. Onboarding: a conversational setup that adapts to the user’s state. Recipes: complete workflows combining marketplace services with the agent’s own abilities. Testing showed that keeping capabilities and recipes separate confused the agent, so workflows moved into the capabilities layer.
02 · Discovery
I helped lead the Service Registry and built the first UI prototype of what became agents.circle.com, for people who want to see what their agent can do and try it fast, and for providers who want to sell to agents.
Post-launch testing showed people missing the “fund your agent” action. The obvious fix was a louder button. But a louder button for an action nobody understands just draws attention to the confusion. I worked in the repo on the activation flow and contributed fixes to catalog scanning and navigation.
03 · From services to outcomes
A marketplace of payable APIs isn’t useful work. I wrote 15 recipes around outcomes (company research, travel disruption, competitive intel, recruiting, crypto monitoring) so the question became “what are you trying to accomplish?” instead of “which API would you like to call?”
Testing them exposed the next layer: the host model controlled execution, so identical instructions ran differently each time. A skipped source, an ignored fallback, a budget treated as a suggestion. Fine in conversation; not fine with money.
Prompt-only execution
The model decides everything.
- Which sources to call
- Whether to retry or fall back
- How literally to treat a budget
- What to log
Hybrid execution (proposed)
Deterministic where it has to be.
- Model: intent, queries, interpretation, synthesis
- Runner: endpoints, budgets, health checks, retries, safety gates, logs
- Recipes become execution contracts, not prompts
04 · Dogfooding with real money
I built a recurring Agent Economy Brief on the stack: free sources plus paid services bought through an Agent Wallet, ~450 signals twice a week, $0.02–$0.05 USDC per run. It was a real research tool and a working demo of an agent buying information to finish a job. Running it repeatedly surfaced what usability tests miss: wallet access, sessions, payment behavior, environment differences, reliability.
05 · Granting an agent access to money
- Create wallet
- Fund it
- Connect to agent
- First use
- Manage over time
The hardest problems were below the interface. Auth could silently switch wallet context. Funding made it unclear which wallet money moved from or to. Wallet identity was technically correct and conceptually confusing. I pushed for a simpler model, one Portal account, linked wallets, persistent context, understandable sign-out, predictable funds, because the right user model has to exist before you polish the interface around the wrong one.
06 · Reviewing what the agent did
People aren’t sending money; they’re delegating work. I proposed an activity model built on runs and automations (durable instructions with schedules, budgets, and controls), with spend alerts alongside hard limits.
Transaction ledger
What the chain knows.
- Amount, address, timestamp
- One row per payment
- Reconstruct the story yourself
Runs
What the person asked for.
- What did I ask the agent to do?
- What did it use, and what did it spend?
- What happened, and what did I get back?
07 · The agent inside Portal
I also led Circle’s first-party agent in Portal, which opens the same capabilities to people who’ll never install a CLI: conversational financial tasks, persistent orders, approvals, cancellation, status, receipts. Conditional orders were the interesting case: describe what you want, the agent asks only what it needs to execute safely, and the order stays visible and manageable in the conversation.
08 · The wider system
As the stack grew into Studio, Discover, and AgentVM, my job became making it legible as one product: how much private-execution infrastructure to expose, deployment vs. publishing, agent identity, and how those states connect to Portal and Discover. Prototypes and narrated walkthroughs let Product, Engineering, and leadership reason about the system before it existed in production.
How the role changed
Every problem moved down a layer. A confusing screen was an account-model problem. Weak onboarding was missing context. An unreliable workflow needed an execution architecture. A transaction history needed a different unit of information. My job became finding those seams and defining the product model underneath: in prototypes, in skills, with real funds, and in production PRs.
Outcome
A connected set of experiences: agents can access Circle’s infrastructure, discover paid services, and do useful work; humans can fund them and understand and control what they do. I designed the interfaces, and the context, execution model, account structure, and product language they needed to make sense.