Spiral: Open Money, Open Intelligence

Some coping strategies for builders who are feeling weirdly bummed out about the state of AI.

Written by Spiral PM, Mat Balez Full blog post here: https://spiralxyz.substack.com/p/building-beyond-the-frontier

https://x.com/matbalez

https://x.com/spiral_xyz

goose launched a long time ago. Dog years have nothing on agent years. goose predates general agentic AI by a bit. The initial thought behind it all was: what happens if you give an LLM control over a shell session?

Turns out interesting things happen. The model writes a command, the command runs, the result goes back into the conversation, and the model decides what to do next. Our tool calling grew naturally out of that experiment, as did the agent loop that now sits at the heart of most coding agents.

Then tool calling got formalized. Then MCP happened. So did approvals, context management, to-do lists, top-of-mind, subagents, retries, hooks, skills, recipes, and steering. But the original agent loop remained. Each feature added another branch, another local variable, or another special case. A dozen different concerns might be active inside one turn, each influencing the others. Cancellation needs to know whether inference or a tool is running. Compaction needs to understand provider errors and usage. Tools can change the prompt. A stop hook can turn a completed answer back into more work. The loop started to turn into spaghetti.

A plugin system seems like the natural answer. It helps up to a point: adding a tool or listening to an event fits nicely. But once a plugin needs to influence the whole turn, the central loop still has to decide when it runs, what it contributes to the prompt, whether it may continue the turn, and how its state survives a restart. The plugin API gradually acquires a hook for every part of the agent loop, while the loop remains responsible for coordinating them all.

goose is taking a different approach. We have replaced the classic agent loop with a re-entrant state machine. The persisted conversation is the main state, and each piece of agent behavior is encoded as an Operation. The machine checks Operations in order. Each one either passes or returns a set of effects, and the first one that applies wins that step. It persists its effects and the machine starts again from the top with the new state.

Consider a normal tool call. Inference sees that the last message came from the user and produces an assistant message requesting a tool. On the next step, the approval Operation gets the first chance to inspect it. If approval is needed, it adds a request to the conversation and yields to the client. Nothing stays running while the user decides. The client later stores the answer, and a newly constructed machine continues from there. If no approval is needed, the Operation passes. The tool execution Operation then recognizes the tool and runs it, adding the result to the conversation. Inference sees the tool response and asks the model what to do next. When the model finally answers without requesting another tool, the stop-hook Operation decides whether the turn may end.

That re-entrancy matters beyond code organization. A server does not need to keep a co-routine and all its local variables alive while waiting for input. A process can restart and continue from the last persisted step. Another frontend can load the same session and carry on. The convenience runner still repeats steps until the machine yields, but it is only a small driver around a state machine that can be invoked once at a time.

Operations are independent but cooperative. A tool handler claims only tools it knows how to execute. If it does not recognize one, it passes and gives another Operation a chance. The final unknown-tool Operation turns anything left over into an error for the model. The same ownership applies beyond execution. The skills Operation owns the command for listing skills, the tool for loading one, and the prompt text that tells the model which skills exist. Remove that Operation and all three disappear together.

Inference is special, but it is still an Operation. Before calling the model, it collects tools, prompt sections, and top-of-mind from every Operation in the pipeline. The max-turns Operation can tell the model that its budget is running low. The recipe Operation can add a final-output tool. The skills Operation can advertise available skills. Inference does not need to know where any of these contributions came from.

The other useful distinction is between effects and events. Events are the live stream: a piece of text, a tool notification, or a usage update that the client should see immediately. Effects are the durable result: append this message, replace this conversation, update this tool request, or record this usage. A caller can ask the machine for one step and decide how to apply those effects, or use a convenience runner that keeps applying steps until the machine yields to the client.

Testing gets much easier. We test complete collections of Operations against a small HTTP server that behaves like a model provider and a real stateful calculator extension. We also have a test runner that throws away the entire state machine after every applied step and constructs a new one from the persisted session. If a tool call still proceeds from request to response to final answer, we know the progress was really captured in state rather than hiding in a local variable.

Not all state has disappeared. Providers, extension managers, and hooks remain runtime dependencies. Pending steering still begins in an in-memory queue, and external side effects need care: if a tool succeeds and the process crashes before it persists its response, rebuilding a state machine does not magically make that tool safe to run twice. The useful change is that these boundaries are now visible instead of being mixed into one long-running coroutine.

The result is a codebase that is easier to test, refactor, and experiment with. A new idea for changing an agent can be expressed as an Operation and added to a pipeline without changing the state-machine core. The original agent loop got goose surprisingly far. Now we can change how an agent behaves without adding another branch.

Spiral is expanding beyond bitcoin into open-source AI by bringing the core goose developers from Block onto the team.

Our first area of focus will be evolving goose into the goose Development Kit (GDK), an SDK that lets developers build their own agentic AI applications rather than relying on a single client.Learn more at spiral.xyz

Everything is moving at AI speed now.

As recently as a few months ago, the question “how will my agent pay for things?” didn’t have a great answer. Humans had to intervene frequently to help agents log in to services and obtain API keys to bypass credit card payment gates, blunting much of the utility of persistent agents.

Today, there are dozens (maybe even hundreds?) of wallets and tools that let agents get money to buy things semi-autonomously on the emerging machine-payable web. These range from virtual credit cards (e.g. Visa’s CLI) to stablecoins (via Coinbase’s x402) to bitcoin’s Lightning Network (via L402) or any of the above using Tempo’s new Stripe-backed MPP protocol.

There are already tens of thousands of paid endpoints ready for use across these options, with the most popular services being the infrastructural pieces agents need today, such as generative AI backends, hosting, search, and data providers. These are the “picks and shovels” of nascent agentic commerce.

Looking ahead, it’s an exciting time to imagine what else might come to exist. What will agents of the future need? What will retain and grow in value in a world of AI-driven abundance? Will agents find ways to earn money autonomously in this new digital economy? These are questions for builders, entrepreneurs, and agents to explore, and explore they will.

Agentic payments, alongside agentic everything, will continue to grow over time. It’s tempting to wonder which payment protocol is best suited for agentic payments, but the fact is that modern agents are smart enough to speak any well-documented protocol that gets the job done. The more fundamental question is: what type of digital money is best suited for the agentic economy?

Stablecoins and bitcoin are the emerging contenders.

It won’t surprise anyone that stablecoins are vying for usage in agentic commerce—their corporate advocates have been very public with their sales pitches. But the fact that bitcoin works (at least) as well for agentic payments today is still widely under-appreciated. So many people still haven’t yet realized that bitcoin is more than just an asset for savings; it can also be transacted in tiny quantities to transfer value instantly, anywhere. Exactly the kind of thing agents need to operate on their own.

But we’re still at the very beginning of how and why agents use money. So, which money will they use?

The virtues of USD stablecoins are obvious: they make digital US dollars accessible to anyone or anything that wants them, wherever they might be. This inherent borderlessness, along with their ability to avoid the volatility of a still-speculative asset like bitcoin and to be used without identity verification (at least for the time being), makes stablecoins well-suited to agents’ needs right now. Paying $0.001 USDC on Base via x402 for your favorite API call is trivially easy. And that’s cool.

But there’s a fundamental downside that has long plagued stablecoins, one that bears scrutiny as much for agentic use as it does human use: stablecoins are products of centralized power and authority. This has implications.

Stablecoins require permission to use. That permission comes, tacitly, from the stablecoin issuer, who can choose to freeze the smart contract underlying any stablecoin token at any time. This gate-keeping power is regularly exercised by all stablecoin operators, often in connection with hacks or law enforcement actions that seem well-intentioned on the surface. But it should trouble freedom-minded people (if not their agents) to think through the implications of such financial censorship being possible without meaningful oversight or accountability—particularly at the giant scale of the entire digital economy. Can a free society exist if every action requires the implied consent of a few stablecoin company’s executives?

Every stablecoin out there (and there are many) runs on several crypto networks (of which there are many as well). This creates a combinatorial explosion of possibilities, each technically incompatible. This means that before you or your agent transact a stablecoin today, it’s not as simple as knowing your counterparty wants to use a stablecoin—you need to agree on a specific coin on a specific network. And if you don’t have that particular stablecoin flavor, you’ll need to swap to the right one. It’s a UX pain for humans, it’s a source of friction, and an added cost, for agents. Surely, bridges will emerge to make this swapping-in and -out ever easier, but such bridges will inevitably become additional points of centralization and frailty for the ecosystem.

Stablecoins fail to provide any financial privacy whatsoever. Stablecoin transactions are public at their blockchain wallet addresses, revealing patterns of spending and behavior. This is much worse than the privacy of the legacy payment system, where only financial institutions privy to a transaction see its information. With stablecoins, it’s like your credit card statement is publicly visible.

For example, here you can see my OpenClaw agent equipped with an AgentCash USDC wallet on Base being funded ($5.11), using StableTravel via x402 to search for a flight to SFO ($0.02) and then using Exa, again via x402, to search for clay tennis courts in Vancouver ($0.007).

While glancing at the blockchain explorer may not make all of this immediately obvious, it is privacy-invasive for several reasons. First, your wallet address is revealed to every merchant you pay, any of whom could easily look up your complete transaction history. Second, every destination address is publicly revealed, and with a bit of detective work, those addresses can be tied to specific merchants, since these mappings can be leaked and indexed. For example, I pointed ChatGPT to my OpenClaw agent’s public transaction history on Etherscan, and it was able to figure out that the first payment went to a StableTravel wallet and inferred with high probability that the second payment was an Exa search. Not rocket science. Third, all of this payment data is not just public but public forever, just awaiting future large-scale data analysis and profiling. If this sounds alarming, it’s because it is.

But stablecoin operators are starting to react to this privacy red flag. Notably, Tempo—the blockchain that settles stablecoin transactions in MPP—has recently introduced a design for privacy Zones in which trusted Zone operators can be chosen to whom transaction visibility can be strictly scoped. While this is better than nothing, it falls short of the complete financial privacy we might expect to underpin financial inclusion and individual freedom at an agentic scale, especially in light of the risk that centralized issuers or networks may one day require KYC permissions if/when regulatory pressure makes that a requirement. It’s clear, in other words, that stablecoins are primarily instruments of compliance, and will remain that way.

It should be acknowledged that compliance is not inherently bad—indeed, for almost every regulated company in the world, compliance is a legal necessity and generally intended to protect us against bad actors. So what’s the concern here? It has some nuance.

One concern is what we choose to optimize for. There is an order of operations, and I tend to believe we should first and foremost create things (in this case, a form of money) that serve the needs of its users (in this case, human or agentic) and then determine the least invasive way to achieve compliance. This is a needle that can be threaded with care. For instance, there are many public-regulated financial institutions that today offer a wide array of bitcoin products (and crypto more generally) while complying with all regulatory requirements across their jurisdictions. So we have proof points that technologies that grant greater individual freedoms and compliance need not be mutually exclusive.

An even bigger …

Loupe is a new open-source security scanning tool from Spiral and Block designed to help bitcoin developers find vulnerabilities in open-source code.

The episode explores how Loupe works, why AI-powered security tooling matters for the future of bitcoin, and the challenges of balancing high-signal vulnerability detection with the growing flood of AI-generated noise in open source. Read the full article on Substack: spiralbtc.substack.com

This Spiral report explores how open-source builders are using AI today, based on survey data and interviews with Spiral grantees and team members. Written by Austin Krauss, it argues that the most important skill is not mastering any one tool, but developing metacognition: the ability to reflect on, adapt, and redesign your workflow as AI evolves. The report identifies four emerging builder archetypes: the Verifier, the Orchestrator, the Upskiller, and the Hyper Coder.

Other key findings include: 84% of respondents use AI every day, 64% spend more than $100 per month on AI tools, and brainstorming now matches code writing as the top use case, suggesting builders value AI as a thinking partner just as much as a code generator.

Explore the full written report at spiralbtc.substack.com.

Follow:

x.com/_austin_f

linkedin.com/in/afkrauss

AI agents are getting powerful, but they still can’t reliably pay for things because the internet’s payment stack is built to stop bots. Big players like Visa, Stripe/OpenAI, Google, and Coinbase are racing to define “agentic payments,” but the standards they push are likely to be permissioned, incomplete, or create lock-in around a small set of approved rails.

If open-source agents want to stay competitive, they need to rally around open, widely-usable payment rails and push merchants to support agent-friendly checkout. Whatever you think of bitcoin, it was made for this.

Written and narrated by Spiral’s Matt Corallo, a long-time bitcoin open-source developer. Read the full article or listen on Apple/Spotify.

https://x.com/spiralbtc

https://x.com/TheBlueMatt

The Bitcoin Merchant Community is an effort to accelerate bitcoin payment adoption by merchants. The goal is twofold: 1) help merchants understand that they can eliminate 3% credit card fees by accepting bitcoin, and 2) empower bitcoiners to locally spread that message to merchants in a fun and memorable way.

It’s been one month since we launched the Bitcoin Merchant Community and we’re off to a strong start:

• 800+ Itty Bitty plushies for small businesses sent

• Nearly 100 Discord participants

• Dozens of Local Champion applications received

• Money saved by business who prefer bitcoin to credit cards

Read the full post here: https://spiralbtc.substack.com/p/bitcoin-merchant-community-one-month.

https://www.bitcoinmerchantcommunity.org/

https://x.com/spiralbtc

The existing bitcoin address ecosystem looks about as intimidating to newcomers as it could. They look like 1Aqv9KxZc2y7M8b for a reason, sure, but they’re far from necessary. Human Bitcoin Addresses (BIP 353) are a worthy replacement and a huge UX unlock for bitcoin.

Read the full article here: https://spiralbtc.substack.com/p/making-bitcoin-speak-human

Spiral has supported FOSS bitcoin since 2019, making bitcoin everyday money by improving security, privacy, and especially UX. That’s why we’re focused on how the next wave of users spend bitcoin.

Our thesis is pretty simple: we can only make the case that bitcoin is money if people can spend it. Unfortunately, for most of bitcoin’s existence, there just haven’t been many places to spend it.

This is why we’re spearheading a peer-to-peer community exclusively for merchants, one that is bitcoin service-agnostic, to promote the idea of bitcoin as everyday money: https://www.bitcoinmerchantcommunity.org/

The Bitcoin Merchant Community aims to help merchants understand how bitcoin lets them keep more from every sale, and empower bitcoiners to explain it in an approachable and relatable way.

The community includes resources, conversation guides, and leave-behind materials anyone can use to spark local adoption—plus a Facebook group where merchants can connect, share experiences, and ask questions.