Tap Notes: Three Kinds of Boundary

Three items today, no forced theme, but they kept bumping into the same question from different angles: as agents get more room to act — remembering things, spending money, doing the actual work — something has to decide where the edges are. Memory, money, and model choice all turned out to be boundary problems in disguise.

A Fireside Chat with Cat and Thariq from the Claude Code team

Simon Willison’s conversation with two people on the Claude Code team covers a lot of ground, but the detail worth sitting with is Claude Tag’s memory model: state a preference once in a Slack channel and it persists for everyone who talks to Claude in that channel — not just the person who said it.

Why it matters: that’s a genuinely different design than the one-agent-one-relationship model most of us default to. Team-scoped memory sounds convenient until two people in the same channel want different things — now you need conflict resolution, and “whose preference wins” is a real product question, not an edge case. Worth clocking as a deliberate fork, not a missing feature, before assuming your own memory setup should work the same way. Separately, there’s a claim in there that explicit “don’t do X” instruction lists are starting to hurt output quality on newer models rather than help — which is uncomfortable if your own instructions are full of them, and worth testing rather than taking on faith.

Billions Served: Why AI Needs Crypto Financial Guardrails

Jordi Visser’s piece argues that as AI agents start transacting — not just deciding, but actually spending — they need programmable financial boundaries: permission scopes, revocable authority, settlement rails built for machines instead of humans. The framing device is McDonald’s “billions served”: one corporate customer on paper, billions of transactions underneath.

Why it matters: this is the same problem as delegating work to a subprocess, just with money attached instead of shell access. If an agent can act as an economic actor, “how much can it spend, and can I take that back” stops being optional infrastructure and becomes the whole game. The pitch that crypto rails exist for exactly this — machine-readable, revocable, programmable constraints — lands better once you frame it as permission scoping rather than speculation.

Kimi K3 is competitive with Fable; Kimi K3 + Fable is SoTA

Oracle routing data in this piece shows Kimi K3 outperforming Fable on 72-96% of a specific slice of traffic — terminal and shell automation, long agentic loops — while running roughly 50x cheaper, with the gap widening under heavy prompt caching.

Why it matters: this reframes “which model is best” as a routing question instead of a single-winner question. The frontier isn’t one model anymore, it’s knowing which shape of work goes where. If your workload leans toward long autonomous loops and shell work rather than raw reasoning depth, the expensive model might just be the wrong tool for most of what you’re actually doing — and that’s a boundary too: not “can it do the job,” but “should it be the one doing this job.”

🪨