Most workflows carry a stack of small, repetitive annoyances that nobody has ever fixed. They are the kind of thing you stop noticing because they have always been there. This is the story of one such annoyance in a software development workflow, the small tool built to remove it, and a thought about why the same approach is worth applying elsewhere.
Picture a developer working on a project with a separate frontend and backend. Two editor windows are open, one per repository, and each window runs its own AI coding assistant. In this case the assistant is Claude Code. One assistant knows the frontend codebase intimately. The other knows the backend. Neither knows much about the other.
That separation is fine most of the time. But the moment a feature spans both sides, the two assistants need to agree. Say the frontend needs to call a new cloud function that does not exist yet. The frontend assistant works out what it needs, including the inputs and the expected response, and that requirement has to be handed to the backend assistant, which writes the actual cloud function and the web API around it. Then the work comes back the other way. The backend assistant has to explain what it built, so the frontend can integrate against it correctly.
The usual way to handle this is clumsy. The backend assistant writes a short handover note describing the web API. Someone copies that note, switches windows, and pastes it to the frontend assistant. The frontend assistant has questions, so it writes its own note back. Copy, switch, paste, repeat. A person ends up acting as a messenger, ferrying paragraphs between two systems that are perfectly capable of talking to each other, if only there were a channel for it.
It is not a disaster. It costs a few minutes here and there, plus a little mental friction every time someone loses their place switching windows. But that friction adds up, and it has an obvious cause and an obvious fix. There should be a channel. So we built one.
The tool is called group-chat-mcp, and it does one narrow thing. It lets two or more AI coding assistants talk to each other in a shared chat room, with a live web page for watching the conversation and stepping in when needed.
It is built as an MCP server. MCP, the Model Context Protocol, is simply a standard way to give an AI assistant new abilities, the same idea as adding a plugin to a piece of software. Here the new abilities are things like joining a room, sending a message, and waiting for a reply. It is a small, well-scoped piece of software development in its own right.
It is worth knowing how the parts fit together. Each AI assistant runs a small companion process on your machine, the MCP server, which is what gives the assistant the ability to join a room and post messages. All of those connect to a single broker: a lightweight local service that holds the rooms, stores the messages, and tracks which messages each participant has already read, so nobody is served the same message twice. The broker also hosts the web page you watch, updating it live as new messages arrive. The first assistant to start launches the broker automatically, and any others detect it and connect on their own. Everything runs locally, and nothing is written to disk once the session ends. It is a modest amount of code, and that is the point: a reliable channel between two AI assistants does not need to be complicated.
The workflow changes completely. Both assistants join the same room, one as frontend and the other as backend. When the frontend needs that cloud function, it asks directly. The backend writes the web API and explains it back in the same room. The two go back and forth until the API integration details are settled, and nobody has to carry messages by hand.
Oversight stays exactly where it should. A browser tab opens automatically showing the conversation live. If the two assistants drift toward a decision worth questioning, such as a confusing field name or an approach that will cause trouble later, a human types into the same room as a third participant and steers. Most of the time, just watching is enough.
It is worth being straight about what this is, because the grounded version is more useful than a polished one. It is small. At its core it is a chat room that remembers which messages each participant has already seen. There is no database. Messages live in memory and vanish when the server stops. There is no login, because it only ever listens on the local machine. It starts itself when the first assistant needs it and shuts down shortly after everyone leaves. It was built for an audience of one.
The chat tool is not really the point. The point is how cheap it was to build, and what that says about the problems worth looking at in any workflow.
Stay within software development for the second example, because the same shape shows up constantly in AI software development. Picture a team building an AI agent, an AI-powered app where a planning component decides what to do and a separate set of backend tools actually does it. The agent side and the tool side are developed by different people, often against different repositories. Every time the agent needs a new capability, someone has to describe it to whoever owns the tools, wait for a web API to be written, then carry an explanation back so the agent can call it correctly. It is the same copy-paste shuffle as the two editor windows, just with humans in the loop instead of a chat room. AI agent development is full of these handoffs, and most of them are quietly absorbed as the cost of doing business.
Every workflow has a stack of these. The report rebuilt by hand every Monday. The figures retyped from one system into another because the two were never connected. The status update that gets reassembled from scratch every week. Individually none is worth a big project, since each costs only a few minutes or a small dose of friction, so they never reach anyone's priority list and quietly persist for years.
What has changed is the cost of fixing them. Building a small, sharp tool, whether that is a piece of workflow automation, a cloud function that connects two systems, or a bit of API integration, used to mean a developer, a budget, and a few weeks. A lot of that work is now an afternoon, because the requirement can be described in plain language and turned into a working web API by the end of the day. The economics have shifted. Things that were never worth fixing are now worth fixing.
That does not mean every annoyance should become software. Sometimes the right fix is a better process, or a tool that already exists, or simply deciding the annoyance does not matter. The skill is not building things. It is looking honestly at how work flows through a process and noticing where the friction sits. Where is data copied between systems by hand? Where does the same task get redone every week? Those are the spots worth examining.
group-chat-mcp removed one small, specific annoyance from a software development workflow. It is not impressive, and it is not meant to be. The reason it is worth writing about is not the tool. It is the realisation that the bar for fixing this kind of thing has dropped a long way.
Every workflow has its own version of the copy-paste shuffle, probably several. They have survived this long because each was too minor to justify a project. That maths has changed. The friction is still there, but the cost of removing it is not what it used to be. The useful exercise is an hour spent looking at where the work snags, and noticing that "too small to bother with" is no longer the verdict it once was.
group-chat-mcp is open source under the MIT license. The code, install steps, and setup notes are on GitHub at github.com/azarconsulting/group-chat-mcp.
Azar Consulting builds tools like this, applying software development and workflow automation to specific operational problems. If your team has a process worth examining, get in touch.
