Spiral: Open Money, Open Intelligence

Spiral

Spiral builds and funds public goods that make money and intelligence more open, secure, and accessible. The team was founded in 2019 as a non-profit R&D lab within Block. Subscribe on Substack for updates or listen here. spiralxyz.substack.com

  1. Oct 8

    The Agentic State Machine

    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. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit spiralxyz.substack.com

  2. May 13

    The Best Money For Agents

    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 … This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit spiralxyz.substack.com

About

Spiral builds and funds public goods that make money and intelligence more open, secure, and accessible. The team was founded in 2019 as a non-profit R&D lab within Block. Subscribe on Substack for updates or listen here. spiralxyz.substack.com