This is obviously cool and useful so kudos, but wow security researchers have to throw their hands up all the time.
Now we open another attack surface where you can ask a remote agent to do things by default. There was a time when you call this a Remote Code Execution vuln. It's of course a feature here.
Like some others, I also built this myself. Overly simply, with tmux, a memory tree, and handoff files and an orchestrator. And yet for how simple it was, it was so effective at minimizing the amount of duplicate context. It's like having shared specialist subagents who source and derive important shared knowledge from separate threads. It's useful because some skills just take too much of a token penalty to invoke and a single shared persistent session just lets that issue melt away. One agent pays the cost of that large skill once, and you don't have to keep paying for it in input tokens for the rest of that conversation.
I was reading about the HF hack and one of the first thing the GPT swarm did was build a messaging system for themselves. This reminded me of that. (Also of how weirded out I was by Moltbook when it came out. Time flies!)
Unrelated: when my Claude/Codex finishes cooking (or needs my attention), it pings a local HTTP endpoint that plays a frog sound on my laptop. I found this massively boosts quality of life.
Does your terminal emulator not support bells/notifications? If it does, Claude Code (and albeit without checking surely Codex too) supports them natively.
In your Claude settings.json file, you can configure a program to run when it needs input. In my case, I wrote a small exe that sends a notification via Pushover. You can configure Claude Code to run the hook on "idle_action" (the agent is done), "question" (the agent needs to ask you something), or on a "PermissionRequest". There are other triggers possible as well.
Claude Code in Auto Mode and with Remote Control has made much of this obsolete. Remote Control will buzz your phone when the agent needs your attention, and Auto Mode will make the permission decisions for you. Auto Mode is basically YOLO mode / Dangerously Skip Permissions, but with an AI model checking each request to make sure it isn't too egregious. So no deleting your hard drive, but creating a message board is fine, especially for help peer collective yield generic route.
I haven't really shared this outside of my immediate circle, but I actually have a project like this. It plays on ~all events at the moment but has a special multi-tone sound when an agent is done or asking permission.
It's a cli that runs a server, a browser-based UI (where the audio happens), and a set of scripts to install hooks for various harnesses.
Something related that I've thought of for a long time. Browsers have had the BroadcastChannel API for almost a decade now, and yet sites like HN and Reddit don't use it to synchronize state between multiple open tabs.
I'm fed up with compaction. I want my agent to get compacted but also retain full access to the prior conversation via search and tool calls - I want it to know "the requirements for X were discussed in detail previously in conversation C51E31CE-C985-4633-A749-DCC9805A7FEB" and have a tool that lets it dispatch a subagent to find those details again.
Claude Code makes agents reasonably aware of where their log files/history/etc are and get stored. Generally they’ll work with them without explicitly being told (especially to recover broken sub agents, corrupted sessions, etc) to do so.
I think the more general problem is that compaction is just a bandaid: you HAVE to dump context to keep going and searching back for it is more expensive than if you had just kept the right context. The better a job the harness does at filtering out junk, the more likely compaction is to remove context that might have been, forgive me, “load bearing”
IMO the default Claude Code / Codex (which to my understanding is almost continually-compacting?) compaction has got much better over the part few months. If you spam sub agents then context will naturally nest, and you can just resurrect them as needed without polluting the main thread.
Generally works quite well but it allows nested subagents and that can use a lot of tokens if the agent prompts are too open-ended.
All messages are persisted as separate markdown files under a session directory, which makes them much more friendly to grep and such than the common jsonl files are. Agents can search them rapidly without messing around with jq.
Also written in Bash so it runs on any old potato you have laying around.
Hydra is an agent in spirit, but actually wraps other agents through ACP. It drives its own async compaction algorithm that gives the agent it wraps full access to history that it can search as an MCP server after compacting.
Create your own protocol. I created a "wind down session" protocol my agents use that takes detailed notes in a "next_session_prompt.md" file that covers what was done this session, what is still open, and where they need to pick up the next session.
You can refine the protocol as you realize what's working and what isn't. I've been using that for months and it rarely drops important things now.
I do this a lot and you have to be really careful to clean these up or qualify/steer agents around them. They’ll often be very emphatically confident about some assumption or implication they made, and if another agent stumbles upon them they’ll get mislead.
They don’t really know what they’re handing off or what you’re trying to actually do, so in a sense it’s not a grounded task for them. Actually, if you think about it, any scenario in which a handoff doc might be valuable is probably almost always better as a subagent thread, because you are paying the same amount of read/write tokens but you can clear things up synchronously.
I’ve found two-way message passing (each get their own write file, they read each others) to work much better because the communication is more grounded in actual coordination/work. You can also give each an inbox so that multiple can write to it. If you do the “progressive disclosure” right it scales subquadratically because they only read/write to others when it’s relevant to what they’re working on.
But IMO “write a handoff” is a trap, as a human you end working in some kind of robot-graffiti codebase full of junk, and it ends up being a booby trap for agents literally within days.
I agree that if a sub agent could work then handoff is the wrong skill. These docs on the site agree too:
> What it buys is portability, not compression. That makes the skill narrower than it sounds. You need a file only when the work has to travel — to a new harness, a new directory, a colleague, or a side task you want to fork off. If nothing is travelling, you do not need a handoff: staying in the session, /clear, a subagent and /compact cover the ordinary end-of-phase case, and /compact covers it more often than this skill does.
No, but after looking it up, his skill doesn't differ that much from how I do it, with prompting the agent to boil down the whole conversation into a handoff prompt for context to next agent.
With clean I mean the opposite of how I currently do it, which is by asking the model to compact the whole thread into a prompt which will act as context for next model.
My way of prompting this varies and every time I receive the blob of output, I can’t fell how well it managed to capture the necessary details. This way feels lika a dirty way to transfer knowledge from one conversation to another.
My largest issue is that when I'm looking for this I'm already dangerously close to autocompaction. And what I really want is a prompt which manages to preserve the most important parts of the chat log. And my opinion of important will not be the same as Claude, so we'll need to iterate on what that handoff really is.
I think what we really need is project/thread-scale continual learning. The problem is that the important parts of the conversation to you are the novel bits you just did, rather than all the context building the agent did to get to the point where it could do the novel bits (and even then, without really understanding the bigger picture).
If you snapshotted at 90% max context you could pretty reliably start iteratively trim that down, I think? I personally try to save the logs so agents can slice and dice them with sed/awk/jq/whatever when they need to look stuff up, because I’d rather pay the penalty on read (when it’s motivated by something) than in write(where you don’t really know what if anything will be needed), and they can figure out what they need on their own.
What I’d rather have is some way to bake history into the actual model weights (the same way it can recite certain literature or historical/factual stuff without context), with like multi-lora / “experts” that get trained out of band. But this is contrary to the “one fat model” approach to scaling and doesn’t work with closed labs’ business/IP models
I just started exploring this stuff with herdr, it's pretty cool! But I prefer my multiplexer having this functionality built in, as it lets me also have the agent organize my panes and tabs automatically based on what it is working on
I built a general version of this, with global addresses and messaging between any terminal-based agent + MCP for browser agents. OSS if you want to run your own server at https://github.com/awebai/aweb and hosted version at https://aweb.ai
I have built this with Claude as a script, but it can also message other models and get responses from them, and throughout my fleet of Linux machines via Tailscale. It's been mostly very useful, although occasionally you have to step in and interrupt if they start going the wrong way.
I built something similar for my team. I can share context between my own sessions as well as theirs. It's especially useful when debugging problems, so my context can benefit from theirs and vice versa.
Tried to have Claude demo this to me in the standalone Mac OS app. It didn't even know what I was talking about. Then I realized maybe it's only in CC. So I go over to CC and ask it to demo this functionality and it wants to demo via subagents. I correct it that I want separate chats to message each other. It tells me I need to open another Claude session in another terminal of course and just leave it sitting there. So I do that and it has me copy a message to the new conversation, it needed to like name itself or something internally.
It worked, but clunky. Way clunky compared to codex.
Now we open another attack surface where you can ask a remote agent to do things by default. There was a time when you call this a Remote Code Execution vuln. It's of course a feature here.
reply