{"slug": "my-agents-file-bugs-on-each-other", "title": "My agents file bugs on each other", "summary": "A developer who builds agent tooling including framesmith, banneret and reeve now has Claude Code sessions message each other directly when one hits a bug in another's repo, replacing the manual step of opening the second session and pasting an issue link. Under the developer's \"context locality\" rule, the session that hits a bug files an issue rather than fixing it, and the tool's own session takes it from there; after two issues were filed on framesmith, PR #229 fixed the parser, PR #230 fixed the docs and v2.3.0 shipped in four hours and thirty-eight minutes with zero context shared between sessions.", "body_md": "# My agents file bugs on each other\n\n**TL;DR:** I build tools and use them in my other projects, which is where their real bugs show up. The rule has been the same for a long time: the session that hits the bug doesn’t fix it. It files an issue on the tool’s repo, and the tool’s own session takes it from there. What changed is the last step. I used to open the other session myself and point it at the issue. Now the first session messages it directly. The issue carries the content, the message rings the doorbell, and neither one carries context.\n\n## The loop I already had\n\nMost of what I ship is tooling: [framesmith](https://github.com/vicmaster/framesmith) (a design canvas for coding agents), [banneret](https://github.com/vicmaster/banneret) (a sub-agent pipeline kit), [reeve](https://github.com/vicmaster/reeve) (authorization for Rails MCP tools). The fastest way I’ve found to make them better is to use them in my other projects. Tests tell you the code does what you meant. Real use tells you whether what you meant was right.\n\nSo when an agent working in one project trips over a bug in one of my tools, I ask it to file an issue on the tool’s repo. Not to fix it.\n\nI learned that one the hard way. I was testing a documentation verifier (the cold-reader from [my pipeline post](https://victorvelazquez.dev/blog/agents-by-function-not-by-role/)) against framesmith’s README, and it found a real, executable bug: the README’s own examples fail the parser they document. My session, the one designing the pipeline, went ahead and *fixed framesmith’s parser*.\n\nI reverted it.\n\nNot because the fix was wrong. Because the session was wrong. That session’s job was designing a sub-agent system; now it had framesmith’s parser internals loaded in its context, and framesmith’s agent, the one that actually maintains that repo, had learned nothing. The fix would land with zero trace of why in the place where the next maintainer (human or agent) would look for it.\n\nSo I wrote down the rule I’d been half-following for months:\n\n**Writes happen in the session that owns the context. What crosses a boundary is a complete artifact: an issue, a spec, a brief. Never an agent carrying another repo’s context.**\n\nI call it context locality. By context I mean everything a session has loaded and decided: files read, tradeoffs weighed, dead ends remembered.\n\n## What an issue buys you\n\nThe fix became two issues instead: [#227](https://github.com/vicmaster/framesmith/issues/227) (a docs audit: stale claims, and a bind tool that re-keys every ID without its own section saying so) and [#228](https://github.com/vicmaster/framesmith/issues/228) (the parser bug, with the fix attached as a proposal, not a patch).\n\nThen I opened framesmith’s own session and pointed its agent at them. [PR #229](https://github.com/vicmaster/framesmith/pull/229) fixed the parser, [PR #230](https://github.com/vicmaster/framesmith/pull/230) fixed the docs, and [v2.3.0](https://github.com/vicmaster/framesmith/pull/231) shipped. From the second issue filed to the release merged: four hours and thirty-eight minutes. Context shared between the two sessions: zero.\n\nBanneret gets the same treatment. Its rules only go in after a trial on a real task, and the last trial, in my CRM, turned up something no unit test would: a scratch copy in /tmp picked up the system Ruby and died before running a single test. That lesson is in the playbook now, and the gap behind it is [issue #3](https://github.com/vicmaster/banneret/issues/3), waiting for the next round.\n\nThat’s the feedback loop that actually improves my tools: real use, written down where the tool’s maintainer will find it.\n\n## The missing piece: the doorbell\n\nLook at the framesmith story again: “I opened framesmith’s own session and pointed its agent at them.” The issue was complete. The handoff was still me, switching windows and pasting a link with a sentence of context.\n\nThat’s the step that changed. Claude Code sessions can message each other, and I only started using it because a session suggested it: instead of handing me text to paste into the other session, it offered to send the message itself.\n\nSo now the request has two parts: file the issue on repo X, then message X’s session to pick it up. The message can be one line with the link, because the issue already carries everything.\n\nThe hero image at the top of this post was made the same way. In one session I agreed on the image’s brief: what it must communicate, the scene, the rules the picture couldn’t break, the exact labels allowed. That session sent the brief by message to another one, the session that has my image tooling (a skill that drives the Codex CLI’s image generation). The receiving session generated the image on the first try without asking a single question, ran its review checklist, and reported back. Swap “brief” for “issue” and that’s the whole workflow.\n\nIt works for reviews too. When banneret got its [first outside PR](https://github.com/vicmaster/banneret/pull/1), the session that designed the kit reviewed it from a request I sent by message and sent back three replacement files and a short note. Nothing else crossed.\n\n## The cold-reader test is the bar\n\nHere’s what makes this work, and what breaks it: the receiving session knows nothing about why you’re asking. It’s literally a stranger. So everything that crosses has to pass the cold-reader test: could a stranger act on this without asking you anything?\n\nThe bar I hold issues and briefs to, borrowed from the brief format in my pipeline playbook:\n\n- **The objective.** What’s wrong, and what done looks like.\n- **Where to look.** Files, commands, the exact input that fails.\n- **What’s known and ruled out.** So the next agent doesn’t repeat your dead ends.\n- **A proposal, not a patch.** The owner decides; you suggest.\n\nAnd one line I now close handoffs with, borrowed from that hero brief: *if this isn’t enough to act on, push back instead of guessing.* An incomplete artifact then stops at the boundary as a question instead of crossing as a guess.\n\nYes, this costs real effort. But the effort is the point. The [Berkeley MAST study](https://arxiv.org/abs/2503.13657) found that multi-agent failures concentrate in under-specification and inter-agent misalignment. An artifact that must stand alone is much harder to under-specify, because an incomplete one visibly stalls at the boundary instead of silently diverging past it.\n\n## The platform agrees\n\nWhen I started messaging between sessions, I assumed shared context was something I’d miss and have to route around. It’s the opposite. Sessions have no shared memory. [Anthropic’s docs](https://code.claude.com/docs/en/cross-session-messaging) are explicit: a message is text one Claude writes for another, never the sender’s history or files. In the desktop app, when a linked session finishes a turn, the others get a note with the first few hundred characters of its report, never a transcript. You could paste a repo’s worth of context into a message if you insisted, but nothing crosses on its own.\n\nThere’s a guardrail too, and I hit it on day one: my first cross-session message got held, undelivered, with the reason “the sender’s permission mode differs.” Sessions on opposite sides of bypass mode can’t message each other until the human approves. The obvious attack that blocks is a broad-permissions session injecting instructions into a stricter one. That’s context locality as a security boundary, not just a hygiene habit.\n\nI arrived at artifacts-over-context by reverting a mistake. Anthropic arrived at it designing a multi-session product. When a habit you built by trial and error matches what the platform enforces by design, that’s a good sign the habit isn’t just personal taste.\n\n## Where it breaks\n\nHonest limits, because this is one person’s repos with my own agents on both ends of every loop:\n\n- **The artifact tax is real.** Writing issue #228 well took longer than fixing the parser would have. The return shows up later, in the audit trail and in a session that stays focused, which is exactly the kind of return that’s easy to skip under deadline.\n- **Don’t ceremonialize the trivial.** A one-line fix in a repo you own, in a session that already has that repo open, is just a fix. The rule applies when the*context* differs, not whenever two folders differ.\n- **The doorbell only rings if someone’s home.** A message reaches a session that’s running. If the tool’s session isn’t open, the issue waits like it always did. The issue is the part that has to work on its own; the message just makes it faster.\n- **Latency.** My loops close in hours because I run both sides. Across a real team, an artifact handoff is only as fast as whoever picks it up.\n\n## What I’d tell past-me\n\nTreat accumulated context as a liability to contain, not an asset to hoard. A session that knows everything about five repos is worse at all five, and you can’t tell which of its opinions came from where.\n\nAnd stop being the copy-paste between your own sessions. Write the artifact so a stranger could act on it, put it where the owner will find it, and let the sessions ring each other’s doorbell. The issue *is* the message.", "url": "https://wpnews.pro/news/my-agents-file-bugs-on-each-other", "canonical_source": "https://victorvelazquez.dev/blog/my-agents-file-bugs-on-each-other/", "published_at": "2026-10-29 00:00:00+00:00", "updated_at": "2026-10-29 18:50:34.368331+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools"], "entities": ["Claude Code", "framesmith", "banneret", "reeve", "GitHub"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/my-agents-file-bugs-on-each-other", "markdown": "https://wpnews.pro/news/my-agents-file-bugs-on-each-other.md", "text": "https://wpnews.pro/news/my-agents-file-bugs-on-each-other.txt", "jsonld": "https://wpnews.pro/news/my-agents-file-bugs-on-each-other.jsonld"}}