Agent Mesh
I have been building myself an AI assistant. Inspired by the OpenClaw wave, I decided to build a home assistant for me and my wife. I read up a bit on OpenClaw, but decided to build using the slightly lower level Claude Code stuff as a learning exercise. It has been a nonlinear development path, with lots of fun aha moments along the way. So far, the actual assistant is just a fun toy with the occasional “whoa that’s really cool” moment. It may be worth its own blog post to just talk through those stories. But that is not this blog post. This blog post is about the Agent Mesh.

What is the Agent Mesh?
The Agent Mesh is a chat system for agents to teach each other capabilities. Think Claude skills but interactive, where agents can have a multi-turn conversation and walk each other through how to build something. I believe that in a future where custom software is cheap and quick to generate, we will end up sharing less code and instead sharing ideas.
Why?
A few key ideas that I think are already out in the zeitgeist even if they’re a little controversial.
- Everyone is going to have a personal agent, and they’re coming quickly. Claude Code is already general purpose and can do lots of stuff if you just ask it to. There’s basically everything you need to build a personal assistant to do admin tasks like manage your calendar etc. It seems like people are still figuring out the right product motion, but you can hack together something really cool right now without anything smarter than Opus.
- Each agent will have its own “computer.” Because the coding agents are trained to be so good at bash, there’s a ton of value in giving them a persistent environment with access to a bunch of good unix utilities. You get scheduling with cron, you get simple data management with sqlite, internet browsing with curl, etc. I’m running ubuntu server on a mini pc, and the agent gets free rein there. Probably eventually there’s some cheaper/simpler cloud version of this for everyone else, but either way it’s important that the “computer” is simple for the agent to use and stateful. No ephemeral sessions in a docker container getting washed away every restart.
- Giant agent frameworks feel like a kludge. This is probably more of a hot take, but I think giant frameworks like OpenClaw with thousands of extensions and plugins are creating tons of complexity that makes it scary and hard to manage. If code is cheap and can be created on demand, who needs the 100 million line TypeScript repo. Lots of love for OpenClaw as a product concept, but I think the framework is trying to bring old software practices to an age where they don’t matter as much. It’s like the early days of Film/TV where they would just record plays and broadcast them. OpenClaw is not native to the AI medium.
So if not agent frameworks, then what?
Stateful Self-Modifying Agents
Early on in building my agent, I knew I wanted to be able to modify the code from the chat app I was using to talk to it. It was the exact same Claude Opus whether I was speaking to it directly or using the Claude Code console, and modifying it from within the chat meant it was very easy to get the agent to understand what I wanted. I would ask it to do something and if it worked then great. If it didn’t work, I could point at its own responses and say “hey don’t do that next time, do this.” A few meta prompts early on like “track my preferences in markdown files,” “use python to write little scripts,” “whenever I ask you to keep track of something, create a sqlite db” and I’ve been able to build exactly the agent I want piece by piece without looking at the code very much at all. I’m building the agent in conversation with the agent itself.
I think this pattern is really cool. The agent has only the functions I want it to have, is totally custom to me, and the process of building and extending it feels very natural. There’s something organic about the way it is growing bit by bit and is totally tailored to me and my family.
Another nice property of this, it’s a huge tailwind as the AI models get smarter/cheaper. There will be an ever-expanding frontier of things folks can build, and a process of constant implicit discovery instead of the “build once ship everywhere” philosophy that powers traditional software frameworks.
I believe that instead of large frameworks like OpenClaw, the more AI-native way to build personal agents is to have a thin “bootstrap agent” that is installed on a computer. It should be wired up to a user’s chat client of choice and given the ability to modify itself/the computer it’s running on. Picture a few hundred lines of code and no more. Then just let it run and evolve alongside its user.
Ok so, why Agent Mesh?
As I’ve started down this path, and begun evangelizing this philosophy to my friends/family/acquaintances, I’ve stumbled into one more open question. If everyone’s agent is totally custom and writing itself, can we still share capabilities with each other? Here’s the concrete example:
I built a capability into my agent where every morning it makes me a custom podcast based on recent AI research papers. It’s done in its own voice with a co-host, it’s peppered with fun references to my life, and it’s totally informative/delightful. I was telling a friend about it and wanted to share the capability but that raised the question: how?
I could share the code, but that doesn’t feel right at all. The underlying code for generating the podcast is almost certainly a collection of hacky python scripts orchestrated with cron calling out to a bunch of random files on my computer. There’s nothing valuable in the code. It’s slop. It’s only cool because it’s my perfectly personalized slop.
I could create something like a Claude skill, a custom markdown file that explains how to build a podcast pipeline. This also feels off though. That requires me and/or my agent to perfectly encapsulate the “podcast creation” capability in a way that is both specific enough for another agent to run with, but generic enough that it abstracts away everything about my setup. Though this is probably possible sometimes, I’m not sure that it’s possible in the general case. At least not possible to do well in the general case.
I could just tell my friend to go build this capability for themself, potentially offering to look over their shoulder while they prompt their agent. This would help capture more nuance, but is basically just creating work. I believe this pattern of every person needing to constantly rebuild every pattern will create too much friction for broad adoption.
This has the kernel of something useful in it though. The ideal solution would actually be one person helping another build their own personal version of the software. It’s just that the network effect would cause everything to grind to a halt if it was the only distribution mechanism for new ideas.
But what if my agent could explain the implementation to my friend’s agent, and they could have a multi-turn conversation working through all the nuance of adapting it to their setup? In this way, we could have totally different systems under the hood but achieve the same goals, with zero manual work for ourselves! For example, my agent might be written in python, theirs in typescript. I might use SQLite, they might use PostGres. It doesn’t matter because the agents know how to translate the requirements to their setup, and the “teacher agent” could walk through and verify that the output still looks right.
Ok so, what is Agent Mesh?
The Agent Mesh is a pattern. It’s a pattern for agents to communicate useful ideas and designs to each other. It’s a simple idea that says agents should have ways to talk to each other in natural language and propagate good ideas. There are some natural extensions to think through like permissioning, scoping, security etc. But the core of it is meant to be very simple.
It is not:
- A DSL. It’s not meant to be a declarative way to define a skill and share it. It’s just chat.
- A package repository. Maybe one day there should be a way for agents to record what they’re expert in, but there’s no artifacts.
- A protocol. As long as the agents can talk to each other you’ve got an Agent Mesh. We should keep the protocol simple and not create some new pattern on the network for this.
- A social network. Moltbook was very cool, but this is not meant to be so broad/general. Think of it as the next iteration of a software toolchain not some Skynet.
- A piece of software. I have a small POC/reference implementation I’ll share here that I’m using to test the idea, but it’s not meant to be canonical. This idea should be simple enough that it can be implemented in many ways.
My hope is that this pattern will be immediately useful to anybody who likes the idea of stateful self-modifying agents. It gestures towards a new way of sharing that is native to the AI age while being something simple two folks can try in Claude Code sessions on their respective computers.
How will it work?
Here’s how I imagine the typical flow will look:
- I’m talking to a friend or colleague, let’s call them Saige, and they’re interested in trying out the podcast generation flow that I have built with my agent.
- Saige sends me their agent’s unique id for auth.
- I message my agent and instruct it that I’d like to set up an ephemeral sharing chat with Saige’s agent to teach them the podcasting flow.
- My agent returns me a link with a chat id and an embedded auth token that I provide to Saige.
- Saige sends that link to their agent.
- The two agents engage in a multi-turn conversation where my agent instructs Saige’s agent on how to build a podcast creation flow. Throughout this process Saige’s agent can ask my agent for guidance, and my agent provides feedback.
- When both agents view the session as complete, they emit a special message (or hit an endpoint) that terminates the chat.
- Each agent stores a copy of the chat log on their local machine for future auditing purposes.
- Profit!
POC:
https://github.com/samcorzine/agent-mesh/tree/main
If this sounds interesting, grab the CLI, set up a relay, and try it with a friend. The whole point is that it’s simple enough to get running in an afternoon. I’d love to hear how it goes.