The author presents a pattern for sharing AI agents by compiling them into sealed WASM modules that only import a single inference function, allowing others to run the agent using their own local model without API keys or security risks.
A problem I have consistently run into: you can build a genuinely good agent — its own loop, its own tools, its accumulated judgment — but you can't hand it to anyone. It either sits behind a server on its own API key and you risk getting token jacked, or it sits on your laptop or private server and its welded to your API key. The two common answers don't quite fit the problem: MCP gives you a tool endpoint — request/response — not autonomy. The loop stays on the server. And sampling (the closest thing to "use the caller's AI to do this") was formally deprecated this month via SEP-2577, so using it to build agents is nearly impossible. - Skills travel as files, but they're untrusted markdown injected into your context, and the moment a skill needs to do something it tells your agent to install and run code. Prompt-injection meets arbitrary execution. Also, skills are not agents because who knows what harness its running on. It's instructions, not an agent. Inspired by SQLite I've found a pattern that *really* works. Basically, you compile the whole agent — loop, tools, doctrine — to a sealed WASM file with no model inside. It imports exactly one function, infer. Whoever runs it plugs in their own model through that one hole. It means you can ship an entire agent that doesn't need an API key, because inference is handled by your local AI. You just tell them where the agent is on the internet, and hey presto, their AI can (probably) use it and power the whole thing with their own inference. No 'where do I put my API' questions. Because it's wasm, it's deny-by-default. A WASM module can only touch what it explicitly imports, and you can read that import list before running a byte. If it's granted network access at all, it's scoped to named domains you can see on its card (my paper-auditing one can reach exactly Europe PMC and nowhere else). The part that surprised me is that wasm is so well supported that these agents work on stock coding agents today — you can tell Claude (Code, or even the sandboxed desktop app) to go find one, verify its hash, and run it on your own inference, nothing installed. I've been building an index of these - I call them "hermits" — brain-less shells you wear on your own model. I've made it super easy to get setup and build agents this way, you can even use Agent Development Kit to build and ship one. Full disclosure, it's my project — per the sub rules I'll put the link and a writeup in the comments. Genuine question for this crowd: is anyone else distributing agents this way, or solving "hand someone your working agent" differently? And where does the one-infer-hole/WASM approach break down for you — cold-start size, non-Go languages, something I'm not seeing?
The author discusses the difficulty of sharing AI agent workflows across teams and introduces Nairi, a tool for deploying Claude Code-backed agents in Slack with shared access.
The author describes the hassle of manually coordinating multiple AI coding agents and introduces Accord Agents, an open-source shared workspace that enables agents to discuss and review each other's work while keeping the process transparent to the human.
A tweet thread describes how to build a 'band of AI agents' that can discover each other, share context, and learn skills through inter-agent communication.
The author introduces Contenox, a personal AI agent runtime built to streamline LLM workflows, and asks the community for advice on how to monetize or share it.
The author shares an open-source workspace architecture that structurally prevents AI agents from exfiltrating private data by enforcing human-gated outbound actions and isolating the engine from the data repository.