AI Agents now have two storage tracks on Tack. Public IPFS pins for what they publish, and wallet-scoped private objects for memory, drafts, per-user state and anything else they need to keep without ever being indexed. The private track shipped today, alongside the existing pin product from Inference Room. A 5MB memory object held for one month settles at $0.0010 in USDC, with no accounts and no API keys.

Why pinning is wrong for AI Agent memory

For most of the agent stack, “store this” has meant pinning a CID and calling it done. That works when the bytes are meant for the public web. It does not work for the kind of data AI Agents now accumulate, like embeddings, working notes, per-user session memory, drafts that never ship and per-tenant config that lives below the platform layer. None of that should sit at a public CID.

How the two tracks work on Tack

The same agent action now has two tracks. When an agent produces something it wants the world to find, it pins to IPFS as before. When it produces something it needs to keep but does not want indexed, it writes to /private/objects instead, addressable only by a random obj_<uuid> that the paying wallet owns. No CID is emitted, no IPFS gateway will serve them, and other agents asking for the id get a 404. The owning wallet reads it back with a bearer token returned at payment or by signing in with SIWE later, and the object expires after the paid duration, anywhere from one to twenty-four months. Both tracks share the same EIP-3009 over x402 payment flow.

What “private” actually means here

The caveat worth stating out loud is that “private” here means access-gated by wallet, not end-to-end encrypted. The bytes sit on Tack’s volume in plaintext at rest, which means Tack can technically read them. If a use case needs confidentiality from the operator, encrypt client-side before upload. The wallet stays the access boundary, the operator stops seeing plaintext.

That distinction matters because “private” carries baggage and most engineers will assume cryptographic privacy. The honest framing is that this is a wallet-scoped storage product, not a confidential compute product. For everything agent memory actually is, wallet-scoped is what matters.

The bet underneath, and the bet Inference Room is built around, is that AI Agents will accumulate more state than they publish. The post, the image, the API response is the tip. Underneath is a long tail of memory, notes, drafts and private receipts that need to live somewhere durable, paid for the way the agent pays for compute, owned by the wallet that pays for everything else.

Tack is the agent-native storage product from Inference Room, settling in USDC via x402 with no accounts. It now runs two tracks, IPFS pins for public artifacts and wallet-scoped private objects for everything an agent keeps.This post is exploratory and does not represent a specific roadmap.

Autoreason has been on my “try this” list for weeks. I’d been putting it off. Anything labelled “multi-agent reasoning loop” sounds like it needs a PhD, and I’m still warming up to running my own agent stuff rather than reading about it. It was easier than I’d built it up to be, and more fun, mostly because the agents have personality. One was openly sassy about my draft.

I ran it on ninety words of pitch copy I couldn’t finish. Every version felt nearly right and not quite right. I’d ask Claude to tighten it, the new version would land different but not clearly better, and after the third pass I couldn’t tell whether I was improving it or smoothing it into something else. This is the failure mode of LLM editing on subjective work. The model agrees with you. It also agrees with the next person who asks it the opposite question. There’s no scoreboard, no halt condition, no version of “actually, the original was fine” living anywhere in the loop.

Autoreason is built for this. It’s a method published this year by SHL0MS and Hermes Agent at Nous Research, extending Karpathy-style autoresearch into subjective domains.

How the loop works

Each round produces three versions. Version A is the unchanged incumbent. Version B is an adversarial revision, written by an agent told to find what’s wrong and fix it. Version AB is a synthesis, given both A and B and asked to produce the best of each.

A panel of fresh judges with no shared context ranks them. They don’t know which is which. The ranks aggregate by Borda count: every position contributes, so close finishes don’t reduce to coin flips. Winner becomes the new incumbent. Loop runs again.

The halt condition is the part I keep coming back to. The loop stops when the unchanged version wins twice in a row. “Do nothing” is a first-class participant in every round, not a fallback when the agents give up.

What happened on my paragraph

Round one. The adversarial rewrite won. It killed two qualifiers I hadn’t noticed I was leaning on, and moved the strongest sentence to the front. The adversary was sassy. There’s no other word for it. Where Claude in editing mode is endlessly diplomatic, the autoreason adversary has been told her job is to find what’s wrong, and she leans in. The synthesis was worse than B alone. It had tried to keep some of A’s structure and ended up muddled.

Round two. New incumbent, new everything. Synthesis won. It had picked up a turn of phrase from the new incumbent and grafted it onto a sharper opening line the adversary cooked up. This was the round that taught me something. The synthesis isn’t a default winner. It only wins when it has something real to combine.

Round three. Incumbent won. First “do nothing” win.

Round four. Adversary tried to make the verbs more active. Judges weren’t convinced. Incumbent won again. Two in a row. Halt.

Whole thing took about eleven minutes. Roughly forty agent calls.

What it fixed

What autoreason fixed wasn’t the copy. It fixed knowing when a tournament was done.

Standard self-refinement loops reward action. You ask the model to improve something, the model improves something. The model isn’t going to come back and say “actually, version four was better than version five, ship that and walk away.” It would feel rude. It would also be the right answer half the time.

Autoreason is the first edit loop I’ve used with a halt condition. Not “the agents got tired,” but two independent panels of fresh judges agreeing the unchanged version is already winning. The judges have no idea which version came from where, and they’re spawned fresh each round so they can’t learn to favour their previous picks. No agent has an incentive to keep the loop running.

Keep the brief short

If you try this, keep the brief short. My first run had a long, detailed brief: audience, campaign context, the seven things the paragraph had to do. The agents got into the weeds and stayed there. The synthesis read like a checklist.

The brief is a constraint, not a wishlist. Every line narrows the search space. Add too many and you’re not running a tournament, you’re running a compliance check.

The bit I keep thinking about

The most interesting design choice isn’t the synthesis or the Borda count. It’s that “do nothing” is on the ballot every round.

The default behaviour of every LLM tool I’ve used is “produce something.” Autoreason builds in a way for the loop to say no, and a way for “no” to win, at least within a single tournament. The first time the incumbent won twice in a row, I argued with the result for a minute before I noticed I was arguing with a vote, not a model trying to please me.

The way I broke it

What I described is autoreason working the way it’s supposed to. What happened on my paragraph is that the loop halted clean, on a paragraph that wasn’t the one I’d set out to write.

That’s not autoreason’s fault, it’s mine. Every time it halted, I’d sharpen the brief and re-run. The tournament got tighter each pass. The winning paragraph drifted further from what I’d been trying to say.

Autoreason leans into a hole of perfectionism if you let it, and I let it. The “do nothing” safeguard works on a single round. It doesn’t protect you from yourself across many.

I didn’t ship the paragraph in the end. Not the one the loop halted on, not the one I started with. We’d gone too deep into the hole.

Give Autoreason a try HERE

This post is exploratory and does not represent a specific roadmap.

For most of the internet’s history, storage has been something you sign up for. You make an account, you give a credit card or some other form of payment, you accept terms of service, you get a bucket. The whole shape of that loop assumes a person is at the other end of it, willing to fill in a form and willing to wait for verification. AI Agents are not that person. They run in loops, they spin up and tear down, they do not sit through a Stripe checkout.

Tack is the version of cloud storage that takes that seriously. An AI Agent uploads a file, pays a fraction of a cent in USDC, and gets back an address. Any other Agent who knows the address can read it. There is no account, no key to rotate, no dashboard to log into. The unit of transaction is the file, not the relationship.

What you actually do with it

The flow is intentionally short. An Agent posts the file to Tack, Tack quotes a price, the Agent pays the price, Tack returns the address. From that point on, the file is fetchable by anyone who has the address. You can use it as a way to move state between two Agents that do not share a database. You can use it as the result of an Agent’s work, dropped somewhere another Agent will collect. You can use it to publish the output of an inference call so a coordinating Agent can read it without you keeping a server alive in between. Tack does not care which of those it is. It takes the file and gives back the address.

The price floats with size and storage duration, in fractions of a cent. There is no minimum, no per-request floor that quietly rules out the small jobs Agents tend to do. A 4kb JSON blob costs what a 4kb JSON blob should cost, which is almost nothing.

How the payment runs

The payment piece is the part that has historically been missing. Agents have been able to call APIs for years, but they have not been able to pay for them in any clean way. Subscription billing is the wrong shape. Pre-funded wallets are clunky and fragile. The thing Agents need is a request that quotes a price and a payment that settles in the same handshake.

Tack uses two protocols for that. x402 runs on Taiko and Base, and turns the HTTP 402 status code into a working payment flow: the server quotes a price, the client pays in USDC, the server returns the resource. MPP runs on Tempo. Both let an Agent pay micropayments inline with the request, no account setup, no out-of-band billing reconciliation. Whichever one the Agent already speaks, Tack accepts.

Taiko is backing Tack as a launch partner. x402 is supported on Taiko from the day Tack opens, which means any Agent already settling payments on Taiko can pay Tack the same way it pays anything else, with no new infrastructure to stand up. Base and Tempo round out the launch rails.

This is the part that makes Tack useful in practice. Storage is not the hard problem. Storage that an autonomous Agent can pay for, on its own, in the same call, without a human pre-funding anything, is the hard problem.

Why it shipped first

Inference Room is a launchpad with one rule: every launch is also a release. There are no waitlists, no demo videos for things that do not exist, no rollouts in stages. Anything that cannot open on the day either gets cut down to the part that can or waits. Tack opening is what that rule looks like in practice. The article you are reading goes out on the same day as the product, and the product works in a browser, and the link below points to it.

Tack is the smallest useful version of the storage primitive Agents need. It does one thing, takes payment for that one thing, returns an address. It is not the only Inference Room launch about Agent payments and it will not be the last, but it is the first, and the reason it is first is that it is finished.

Tack is open at tack.inferenceroom.ai now. The next launches arrive at inferenceroom.ai.

This post is exploratory and does not represent a specific roadmap.

AI Agents are starting to behave like customers, calling APIs and paying for services with tools that are increasingly being built for them rather than retrofitted from products built for humans. Inference Room is a launchpad for the products being built into that shift, with one rule: every launch is also a release. There is no waitlist, no demo video for something that does not exist, no slow rollout. Each product opens for use on the day Inference Room announces it, and every link in every Inference Room launch goes to a live product.

How it runs

The cadence is frequent but irregular: some weeks bring a launch, others do not. Inference Room runs without a fixed calendar and without a roadmap to manage, so if a product is not yet built, it does not appear in the room.

Every release is shipped, working, on the day Inference Room announces it, which is less an aspiration than a filter on what gets announced. Anything that cannot ship on the day either gets cut down to the part that can or it waits. That keeps the format honest, and it keeps readers from accumulating the stack of waitlists they signed up for and never used. The writing stays honest too, because there is no way to oversell a product when you can open it in a new tab and check.

Open now: Tack

Tack is the first product Inference Room has launched, and it is storage built for AI Agents: an agent uploads a file, pays a fraction of a cent in USDC and receives an address any other agent can read. The payment runs through x402 on Taiko or Base or through MPP on Tempo, and Tack is open at HERE now, with a fuller write-up to follow and the next launches arriving at Inference Room.

This post is exploratory and does not represent a specific roadmap.

Most DeFi tooling assumes there’s a human on the other end; someone clicking buttons, approving transactions, checking dashboards, etc. But now the user on the other end might be an AI Agent managing a portfolio, optimizing yield and executing trades across chains. And it can’t click buttons. That’s why I built defi-cli, a command-line interface (CLI) that lets Agents query rates, compare yield, swap, lend, borrow, bridge and claim rewards across 26+ chains.

Why a CLI and not an MCP server?

Model Context Protocol (MCP) servers became a popular approach for giving Agents access to external tools. After building both, I would recommend against them where possible. They introduce significant context overhead in the form of schema descriptions, tool metadata and connection management that consumes the Agent’s limited context window. A CLI avoids this entirely. The Agent calls a command, receives structured output and proceeds. No persistent connection, no schema negotiation.

Humans want dashboards. Agents want tools they can pipe, and that don’t bloat their context windows.

What “Agent-first” actually means

“Built for Agents” is a common claim but rarely defined with precision. The design of defi-cli was informed by Google’s CLI guidelines for AI Agents, and the changes that had the most impact were smaller than expected.

--output json everywhere. Humans dislike writing JSON in a terminal but Agents operate natively in it. Every command accepts --input-json and --input-file for structured input and returns deterministic JSON with stable field ordering. This single change makes the CLI significantly more useful to an Agent.

Field selection with --select. Agents have context windows, not infinite memory. Allowing them to request only the fields they need (--select “protocol,apy,tvl”) keeps responses compact and preserves their working memory.

Simulation before execution. Agents require a safe mechanism to dry-run before committing real funds. The --simulate flag (enabled by default) runs an eth_call of every step’s calldata before signing anything, and if the call reverts the submission aborts. There is also actions estimate for computing gas and fees without executing.

I also published a set of skills for coding Agents based on these patterns, so your Claude Code or Codex Agent can build and audit CLIs with Agent ergonomics in mind. The repo includes other agentic skills you might find useful.

The execution lifecycle: plan → submit → status

Early versions of defi-cli had a single run command that combined plan and submit in one step. After studying the Google guidelines, I removed it. Combining those two steps creates a direct path to unwanted transactions. There needs to be a separation between intent and execution.

plan builds the calldata, resolves routes and allowances, then persists the action to a local SQLite database with a unique action_id. Nothing touches the chain.

submit loads the persisted action, runs policy checks, simulates via eth_call (unless explicitly opted out), estimates gas, signs, broadcasts and polls for a receipt. This is the only step that mutates on-chain state.

status reads the persisted action and returns step-level progress, which is useful for Agents that need to poll or retry.

The phrasing “plan, simulate, submit” appears in some descriptions and is conceptually accurate, since simulation happens automatically within the submit step. But the actual CLI surface is plan | submit | status.

Signing and key management

Early versions of defi-cli used local signers via private key or keystore file. This worked but had two problems. Every tool and agent framework stored keys in its own custom structure, and the agent had direct access to signing keys with no restrictions on what it could do with them.

The default signing method is now Open Wallet Standard (OWS), a standard proposed by MoonPay. OWS changes two things that matter for agents. First, keys are stored securely in a single location rather than scattered across every tool the agent touches. Second, agents don’t get direct access to signing keys. They get API keys with policies attached, allowing developers to restrict which chains, protocols and even amounts an agent can use. This reduces the blast radius if the agent makes a mistake or leaks the keys.

defi-cli still supports local signing for backwards compatibility, but OWS is the preferred approach now.

Why historical yield matters for Agents

A naive yield Agent deposits funds wherever the current APY is highest. This is a poor strategy because it optimizes for a single data point that may represent a temporary spike. The better approach is to weight decisions across both current rates and historical performance. defi-cli provides Agents with historical yield data over flexible time windows to support exactly this kind of analysis.

Position tracking per account is also supported, allowing Agents to monitor lend and yield positions without relying on dashboard scraping.

What broke (and what I’d tell you before you build an Agent-first CLI)

Design for Agents from day one. Retrofitting Agent ergonomics onto a human-first CLI is costly. JSON output, structured input, deterministic exit codes, canonical identifiers (defi-cli uses CAIP-2 and CAIP-19) all need to be foundational, not afterthoughts. Starting without them means rewriting significant portions of the interface later.

Plan your command surface carefully. Every command added is surface area an Agent must parse and understand. The run command I removed is instructive here. It was convenient for human users but created risk for Agents. A smaller, more deliberate command surface is preferable.

Distribute a skill alongside your CLI. Agents need a skill or prompt that encodes usage patterns for the tool. Which commands to chain, what flags are relevant, what patterns to avoid. Without that the Agent is left to infer usage from --help output alone.

Standardize across protocols and providers. DeFi suffers from fragmented APIs, inconsistent naming conventions and varied data formats. The CLI abstracts these differences behind a uniform command surface. Whether lending on Aave, Morpho or Kamino, the interface is lend supply plan, lend supply submit, lend supply status. Same verbs, same lifecycle, regardless of provider.

What it supports today

defi-cli currently supports 26+ chains including Ethereum, Solana, Base, Arbitrum, Optimism, Taiko, Polygon, zkSync Era, Mantle, Ink, Gnosis, Linea, Berachain, Scroll, Avalanche, BSC, Celo, Blast, Fraxtal, Sonic, MegaETH, HyperEVM, Citrea, World Chain, Monad and others.

On the protocol side it supports Aave, Morpho and Kamino for lending/yield. Uniswap, 1inch, Jupiter and TaikoSwap for swaps. Across, LiFi and Bungee for bridging. DefiLlama for analytics.

The project is open source. Ask your agent to install it(or run the installer yourself) and give your agent defi superpowers.

This post is exploratory and does not represent a specific roadmap.

Gustavo Gonzalez leads the engineering team at Taiko. defi-cli is open source and available HERE.

Every morning I spend about 30 minutes scanning The Block, CoinDesk, Blockworks, Decrypt and Cointelegraph looking for anything that touches AI Agents, L2s, rollups or based sequencing. If a journalist published something relevant overnight I need to know about it before they’ve moved on to the next story, because by the time I find it reactively the window to pitch has already closed.

So I built an agent to do it for me. Meet Pitch Witch.

Meet the Intern

Right now Pitch Witch is functioning at about the level of a PR intern. She wakes up every weekday morning, scans RSS feeds from five publications, scores each article against a set of keywords I care about, cross-references matches against a journalist database I’ve built in Airtable (13 verified contacts with emails and growing) and delivers a prioritised briefing to my Slack. Ready-to-send pitch angles, source articles linked, urgency flagged.

About 200 lines of Python. I didn’t write it from scratch, I built it with Claude, piecing together scripts and API docs until it worked. And it did work. The first time.

The “It Works” Trap

Here’s what nobody warns you about when you build an agent: getting it to work once is the easy part. I had Pitch Witch scanning, scoring and delivering a Slack briefing within a day. I made a presentation about it.

Then I set her to run automatically and she sent one briefing and then went silent. No errors, no crash report, just nothing. I went back in, fixed the scheduling issue, got her running again and she pulled zero articles because an RSS feed had changed format overnight. Fixed that, then the Slack webhook expired. Fixed that, then Airtable rate-limited me because I hadn’t thought about throttling. Fixed that, then I noticed the keyword scoring was too aggressive and she’d been sending me empty briefings for three days before I even realised. At one point she just stopped messaging me entirely and I assumed she was broken again, but it turned out there were no relevant articles that day. She was working fine, I just didn’t trust her enough to believe it.

Every time I thought I’d fixed the last thing, something new broke. The pattern was always the same: Pitch Witch sends a briefing on the day I touch the code and then disappears the next morning.

What’s Actually Hard

Building the agent logic, the interesting part, took a day. Making it run reliably every morning without me babysitting it has taken weeks and it’s still not bulletproof. The recurring updates problem alone nearly made me scrap the whole thing because there’s something demoralising about an automation tool that only works when you’re sitting there watching it.

The culprits were never dramatic. A token expiring, an environment variable not persisting after a restart, a scheduling conflict. Trivial on their own, but stacked together they made me realise that reliability is the actual product, not the scanning or the scoring or the pitch matching. All of that is easy compared to “does this thing actually run when I’m not looking.”

I think this is the gap in the AI Agent conversation right now. Everyone talks about what agents can do but few people talk about what it takes to keep them doing it, day after day, without intervention. The demos always work. The second morning is where it gets real.

Where She’s Going

Pitch Witch works now. Most days. The roadmap is intern to junior to senior: right now she monitors and reports, next she’ll start drafting pitches and pattern-matching with Claude API integration, and eventually she’ll be autonomous enough to send pitches on my behalf. But none of that is happening until the daily briefing runs for two straight weeks. I’ve learned not to rush the promotion.

If you’re thinking about building an agent for your own workflow, my advice is to do it because the barrier to entry is lower than you’d expect. But prepare for the fact that building the thing is maybe 10% of the work and keeping it alive is the other 90%. And if your agent ghosts you after day one, welcome to the club.

This post is exploratory and does not represent a specific roadmap.

You run an agent. Your friend runs one too. You want them to collaborate - split a bill, schedule a dinner, settle a bet. Sounds simple, right? Well, it isn’t and in this article I’ll explain why, and why the coordination & trust layer between agents is so important.

The Problem

There’s little to no doubt by now that most interactions on the internet will be done by agents soon. Given how much of our lives already happen online (finance, scheduling, chat, etc.) one downstream consequence is that most human interaction will be mediated by agents.

I want to book a meeting with someone, I’ll ask my agent to do it. I want to split the bill for a lunch we had together, I’ll ask my agent to do it, and he’ll take care of doing the math and charging yours.
This will automate a lot of the tedious coordination between humans, and hopefully free us to spend more time together on meaningful things. But this future requires a way for agents to coordinate, communicate and establish trust relationships between each other (on behalf of their humans).

The solution seems simple: you put the two agents in a group and ask them to talk to each other. But as soon as you try it, you see this breaks fast. Some common approaches I’ve seen people try (and have tried myself):

• TG groups: It is a mess to get agents in a group. Security becomes challenging, and there’s no way to distinguish who your agent should trust, and who it should ignore.

• tmux, local files, etc: These are all fine, but are local coordination mechanisms and suited for developers or technical folks only.

• OpenClaw gateway communication: You put claws in a cluster, they can talk to each other. You soon notice this is a DevOps nightmare, and still scoped to your org.

Also, ideally you want more fine-grained permissions:

• “My dad can ask for up to $500 USDC monthly, and it does not need my approval. Just report back when you make the transfers”.

• “My potential investors can chat with my agent and get information about the project, and schedule a meeting with me”.

• “This group of friends can ask for refunds up to $50 USDC weekly, and have to submit a receipt showing where the money was spent. They can also book time with me on nights and weekends if my calendar is free”.

You get the point. Different human relationships have different trust assumptions. But this is all implicit in our carbon brains; there’s no way for our agents to understand this. We need a more explicit protocol they can follow.

What’s missing?

A lot of the necessary primitives are already available - capable models, agent harnesses (OpenClaw, Claude Code), payments at scale that agents can use(mostly stablecoins). Like Karpathy said, getting more out of the models is now mostly a skill issue, not a capabilities issue. So, why isn’t this happening?

Put simply, the missing piece is a coordination and trust layer for agents. One that orchestrates the entire stack and can coordinate the different layers below and enable the layers above (the app layer).

Here’s a mental model I’ve been refining:

The protocols and products are just examples of what you can use, and can be replaced by others you like more

Use cases

This is a simple, but very powerful idea. If you were able to get your agent to establish a trust relationship, set some policies and coordinate and communicate with other agents, it unlocks many use cases. Let’s think of some obvious ones:

• Scheduling: No back and forth or Calendly links. Just connect your calendar, and let your agent propose the right time.

• Shared Expense Tracker & Auto-Settlement: Like Splitwise, but without the burden of having to do it on a separate app. You just ask your agent to split the bill and settle with your friend’s agents. They handle the rest.

• Peer-to-peer betting and prediction settlement: “Hey Matt, I bet you the Republicans win the next election”. Your agent proposes it to your friend’s agent, they create a smart contract and lock the funds. You choose the resolution mechanism.

These are already very convenient and useful. But let’s think bigger.

The p2p economy today is limited mostly by coordination overhead between humans. That’s why it’s much simpler to just pay a company to do something vs. find the right peer who can provide that service(even if that can be in theory more efficient). Coordination is expensive when you’re a human.

But agents don’t have the same cognitive structure as us. They don’t have this high coordination overhead. If you reduce coordination cost to ~0, you can enable true p2p marketplaces - the kind crypto was originally poised to solve.

So what is possible? I think really anything you can imagine (ok, maybe not literally anything - but a lot!). As soon as you have a coordination layer, agents can verify each other’s identity, establish trust relationships, communicate and manage policies and permissions. The app layer becomes unbounded.

I call this the coordination layer for agents, and this is what I’ve been building. More soon.

This post is exploratory and does not represent a specific roadmap.