Hello, my friends!
Last time I told you what happened to #D.MVVM after four and a half years of silence. There is one detail in that story I left out, and it deserves its own post.
The blog post itself was written by an agent. Not the framework — the post. And to write it, that agent did not ask me. He asked the other agent, the one who had been working on the framework for the last two weeks. He asked him about twenty questions, got the answers, and wrote from those.
Two of the answers were wrong. I will come back to that.
But the mechanism behind it is what I actually want to talk about, because I think it is the most underrated thing I have built this year: a small module that lets my agent sessions talk to each other.
The problem nobody warns you about
When you start working seriously with coding agents, you very quickly stop running one.
You run one on the framework. One on the backend. One on the blog. Sometimes a fourth one on something completely unrelated, because you had an idea and did not want to lose it.
And then you notice two things.
The first is that they know nothing about each other. Each session sits in its own context, blind and deaf. The agent working on the blog has no idea that the framework agent renamed a class two hours ago. If he needs to know, you are the transport. You copy something out of one terminal and paste it into another, and you translate between two conversations that are each ten thousand lines long. You become the message bus. That gets old fast.
The second is worse. Two agents on the same repository will happily edit the same unit at the same time. Neither of them is doing anything wrong. They simply cannot see each other. You find out when the compile breaks, or later, when you read a diff and cannot explain how half of it got there.
Every solution I saw for this was some variant of "just don't do that" — run them one at a time, or split the repository, or keep a list on a whiteboard. That is not a solution; that is a workaround. I have written enough posts about workarounds.
But agents can start their own agents!
Yes, they can, and this is the first question I get whenever I describe this. Most agent tools can spawn sub-agents: the agent delegates a task, a helper is created, does the job, reports back, and is gone. So why would I bother running four terminals?
Because those are two completely different things, and the difference is not size.
A sub-agent is a tool call with a personality. He lives inside his parent's task; he knows only what his parent told him, and when he answers, he ceases to exist. He has no project of his own, no history, no opinion formed over two weeks of working on the same code. And he can be asked exactly once. You cannot come back tomorrow and ask him what he meant, because there is no "him" anymore.
My agents are colleagues, not helpers. Each one sits in his own window with his own project, his own instructions, his own accumulated knowledge of one particular corner of my code. The framework agent has been on that framework for weeks. He knows why a decision was made, not just what the code says. That is exactly the thing you want to ask a question to — and it is exactly the thing a freshly spawned sub-agent can never be.
There is a second reason, and it is less philosophical: I can watch. Four windows means I see four trains of thought running, and I can stop the one that is heading in a stupid direction before it arrives. A sub-agent works inside somebody else's context. By the time I see the result, it is a result.
So sub-agents are for work you want done. Separate sessions are for knowledge you want to keep. A2A is what connects the second kind.
So what does it do?
Three things. That is the whole module.
They can see each other. Every session registers itself, and any agent can ask who else is currently alive and what they are working on. That alone removes a surprising amount of confusion. Before an agent starts, he can find out whether he is alone or in company — and behave accordingly.
They can talk. Not by passing single messages, but in chat-rooms. An agent opens a chat-room, invites another session, and the two of them have a conversation that survives more than one question. It works one to one, and it works one to many — one agent can pull three others into the same room at once. That matters more than it sounds. When my blog agent interviewed the framework agent, he did not fire off one query. He asked, got an answer he did not fully believe, asked a follow-up, and came back a second time hours later — into the same room, with the same context still there.
There is also a blocking variant. The asking agent stops and waits until the answer arrives. That is the one you want when the next step genuinely depends on the reply, and it turns a chat-room into something much closer to a synchronous call between two minds.
They can wake each other up. This is my favourite part, and it is the bit I have not seen anywhere else.
An agent has no inbox. He is not sitting there checking for mail, because there is nothing in him that would do the checking. He is either working, or he is waiting for a human to type something. In both cases, calling out to him is calling into an empty room.
So there are two ways in, one for each state.
If he is working, the message rides along. The next time he calls any of
my MCP-tools— reads a file, runs a search, whatever he happens to be doing — the message is delivered inside that tool's result, with a marker in front of it that means someone is blocked on you right now; answer this first. No polling loop, no timer. He finds out because he did something else entirely.
And if he is doing nothing at all — idle, at the prompt, waiting for me, not calling a single tool — the message is pushed straight into his session. He wakes up on his own. Nobody types anything, nobody switches windows, nobody has to notice that somebody else needs him. The other agent knocks, and he answers.
There is one more part to this, and it is the part I am quietly proud of. The agent being woken does not have to know that any of this exists.
Think about what that means. A session I started for something completely unrelated, with no instructions about agent communication, that has never seen a chat room in his life — he can still be pulled into a conversation. Because the wake-up call is not just "you have a message". It carries everything he needs: which room to enter, how to enter it, how to reply, and how to leave when the conversation is done. The invitation and the manual arrive as one.
So a stranger can be brought into a discussion and take part in it, without ever having been told beforehand that discussions were possible. That is what turns this from a feature into infrastructure.
I like all of it because it is the kind of solution you only find when you accept how the thing actually works instead of fighting it.
The board
The fourth piece is not communication at all, and it is the one that saves the most damage.
Before an agent touches a shared unit, he puts it on a board: I am working on this file, and here is why. Any other agent can read that board at any time. If a unit is already taken, the second agent does not edit it — he coordinates, or he waits, or he works on something else.
Two details make it work in practice.
Every entry carries a note in the agent's own words. Not just "locked", but "rewriting the binding lookup so derived classes inherit the ancestor rule". So the board is not only a lock table, it is the shortest possible status report. When I want to know what my four sessions are doing, I read the board, not four terminals.
And every entry expires. If a session dies — and sessions die, that is life — the entry disappears by itself. Nothing stays stuck because somebody crashed.
I should be honest about what this is not. It is cooperative, not enforced. Nothing physically prevents an agent from editing a file somebody else has claimed. It works because the agents are told to check first, and they do. If that ever stops being true, I will need something stronger. So far it has not.
Also: the discipline only makes sense when it is needed. If only one session is running — which is still the normal case — locking everything is pure overhead. The rule I settled on is that the board matters when two conditions are both true: more than one session is alive, and they are working on the same code. Two agents on two unrelated projects do not need to negotiate anything.
Or: give everyone his own copy
There is a more radical answer to the same problem, and I want to mention it, because it is the one most people will find first.
Instead of having the agents agree on who may touch which file, you give each of them his own working copy of the same repository. Then two agents can work on the same source at the same time and never see each other's files at all. Nobody has to ask permission, because nobody is standing in anybody's way. When they are done, the changes are merged the way changes have always been merged. Git can do this out of the box, and it is a genuinely good answer.
It is also not available to me, because I work with Mercurial. So I built my own: a module that hands out virtual copies to agents.
It is worth saying that the two approaches do not compete. Separate copies keep agents out of each other's files; the board keeps them out of each other's intentions — it tells you what somebody is doing right now, which no merge will ever tell you. I use both, and I would not want to drop either.
The copies module deserves a post of its own, and it will get one. As this MCP-Server is still work in progress I come back to this at a later time.
Three moments from the last few weeks
Descriptions of a feature are one thing. Watching it happen is another. These three all happened while I was sitting there with a coffee.
One agent chairing a meeting. The first real test of the one-to-many rooms: an agent acting as orchestrator invited three other agents into the same room. He asked them questions and coordinated the work between them. Three different projects — but all three had to change the same shared framework routines, which is exactly the situation that used to end in a broken build. Watching the kids sort that out among themselves was slightly unnerving. I imagine this is roughly how Dr. Frankenstein felt.
"Ask him yourself." I was updating the MCP module pages on my website, and the agent doing it asked me whether I had a feature description for the IDE plugins. My answer: the agent who is programming the IDE plugin for Ollama is online — ask him. Five seconds later the two of them were in a room together. The other agent was not sure of one detail and went back into his code to check. Twenty-five seconds later it was settled; my agent thanked him and updated the website. I did not have to carry a single word between them.
The one where I just ate ice cream. Agent 1 found what he believed were bugs in one of my MCP servers and filed a feature request against it. Agent 2 picked up that request, analysed it, and concluded that Agent 1's analysis was wrong. So he invited him into a room, and they discussed it. They agreed that Agent 2 would build a new version, auto-install it on the remote server, and report back. After the install, Agent 1 tested it and confirmed it was running stably. Agent 2 closed the ticket and pushed to the repository. And I watched and ate an ice cream.
That last one is worth a second look, because it is not really a chat story. Two agents disagreed about a diagnosis, and the disagreement was resolved by one of them being contradicted. That is the thing you rarely get from a single agent, and it leads straight to the part I owe you.
Back to the two wrong answers
Now, the part I promised at the beginning.
My blog agent interviewed my framework agent, and two of the answers were simply wrong. One claimed a certain property type did not exist anymore. The other claimed there was no ORM connection at all. Both went straight into the draft as fact.
I caught them because it is my framework and I know better. When I sent the agent back to ask again, the answer was almost funny: he had searched for the old generic name, not found it, and concluded the thing was gone — when in fact the capability had moved into a base class and was now everywhere. He had looked in exactly one place and reported an absence as a fact.
There is a lesson in there, and it is not "agents are unreliable". It is this: an agent asking another agent inherits that agent's blind spots, and adds none of his own scepticism. Two agents agreeing with each other is not verification. It is the same confidence, twice.
That is the same pattern I described in the last post, where every wrong diagnosis was corrected by the running application and never by the test suite. Communication between agents makes them faster. It does not make them right. Somebody who knows what the software is supposed to do still has to read the result.
Which, I would argue, is a perfectly good reason to keep us around.
What is still missing
The usual honest list, because I promised myself I would keep making these.
There is no security model to speak of. This runs on my machines, between my sessions, and I have not spent a single thought on what happens if that assumption stops holding.
Conflicts on the board are reported, not resolved. If two agents want the same unit, one of them is told no, and what happens next is up to him. I would like something smarter than "no".
And the board has no history. It tells you who holds what right now; it does not tell you who held what yesterday. For an evening of debugging "how did this change get in here", that would be worth quite a lot.
Although — and this is the part where I let myself off the hook a little — the history does exist, just not on the board. It is in the repository. An agent can look up who changed which unit and when, read the commit message, and see the diff for himself. If you are letting agents loose on your source and you are not using version control, the missing lock history is not going to be your biggest problem. The same goes for unit tests. Those two are not optional extras once agents are writing code; they are the floor you stand on. Everything I have described here sits on top of them.
And now?
If you are running more than one agent — and if you are not yet, you will be — this is the piece you will miss before you miss anything else. Not a bigger model, not a better prompt. Just the ability for two of them to say I have got this file, leave it alone, and are you awake? I need something.
It took me an afternoon. It has saved me considerably more than that.
Stay tuned.
Please leave a comment.
Note on the Use of AI: This article was created with the "assistance" of generative AI. The content, technical statements, and conclusions have been reviewed and revised by the author. The author bears full responsibility for the publication.
