A trending GitHub tool turns AI coding agents into a team. Here is the fun part, and the risky part.

Picture opening six terminal windows. In each one, an AI coding agent is working on part of your project. One is writing code, one is checking it, one is waiting for an answer you forgot to give. By lunchtime you cannot remember which window is doing what, and one of them has quietly been stuck since 10 AM.

That mess is exactly what a trending open-source project called OpenRig wants to fix, and its answer is delightfully practical: treat the agents like an actual team.

An org chart for robots

OpenRig is free, open source (Apache 2.0) and built by a developer going by mvschwarz. It showed up on GitHub’s trending list at the end of September and, at the time of writing, its repository shows about 4,200 stars. According to its own README, it turns AI coding agents “from a pile of terminal sessions into a persistent, organized team.”

Here is how it works. You describe your team in a plain YAML file: who is on it, what each one does, and who reports to whom. Then one command boots the whole crew. Each team member gets a “seat”, which is simply a tmux session (a terminal pane) you can attach to and watch. Claude Code and Codex agents can sit side by side in the same team.

The agents can talk to each other, too. There are commands to message one named seat, broadcast to everyone, or open a shared chatroom. Every message lands in a local database, so if you shut your laptop and come back tomorrow, the handoffs are still there.

Meet the starter teams

The project ships with ready-made team layouts. As described in the README and a deep-dive by PyShine, they include:

My favourite detail: you can “freeze” a team with a snapshot, switch your computer off, and bring the same team back later. The tool even tells you, seat by seat, whether each agent resumed where it left off, started fresh, or failed to come back.

Why a team beats one very busy robot

The idea behind all this is old and human: separate the person who does the work from the person who checks it. A single agent that writes code and then reviews its own code tends to grade itself kindly. Put the reviewer in a different seat, ideally running a different model, and you get something closer to a second opinion.

It also makes the whole thing less of a black box. Because every seat is a normal terminal session, you can look over an agent’s shoulder at any moment instead of reading a summary afterwards.

What can go wrong

A team of agents is a bigger target than one agent. The security community has noticed. The OWASP Top 10 for Agentic Applications, built with input from more than 100 researchers, lists several risks that get more serious when agents talk to each other:

• Insecure inter-agent communication. If agent messages are not authenticated or protected, one can be spoofed or have instructions slipped into it. In a team, one poisoned message can travel.

• Cascading failures. An error in one agent can spread across the whole workflow, because the next agent trusts what it was handed.

• Goal hijack. Malicious content (a web page, a ticket, a code comment) can quietly change what an agent thinks it is supposed to do.

• Tool misuse. Agents with too many permissions can use perfectly legitimate tools in ways nobody intended.

There is also a simple practical one: setup. OpenRig’s own README tells you to read what it changes on your machine and back up the relevant files before running it, because it writes provider hooks and workspace trust settings. That is honest of the authors, and worth taking seriously. It also says the risky “YOLO” permission mode is off by default.

How to try it without regrets

1. Read before you run. Follow the project’s own advice: see what setup changes, and back up those files first.

2. Start with the two-seat team. An owner and a checker is plenty to learn from. Add seats when you have a reason.

3. Use a throwaway project. Point it at a test repo, not the one that pays your wages, until you trust the behaviour.

4. Keep permissions tight. Leave the permissive modes off, and give each seat only the access its job needs.

5. Treat agent messages as untrusted input. Anything an agent read from the internet can end up in a message to another agent. Review what crosses seats, especially before anything gets merged or deployed.

6. Stay on the diff. A team of agents can produce a lot of code quickly. A human still needs to read the result.

The takeaway

Whether or not OpenRig becomes the tool everyone uses, it points at something real: the next step for AI coding is less about one super-agent and more about managing a small, watchable team with clear roles. The best part of this design is that nothing is hidden. Every seat is a window you can open.

If you only remember one thing: a team of agents multiplies what they can do and what can go wrong, so give each one a narrow job and keep a human on the final check.

Facts here come from the OpenRig GitHub repository and README, a PyShine technical deep-dive, an AIToolly report on its trending debut, and TechRepublic’s coverage of the OWASP Top 10 for Agentic Applications. It is a fast-moving project (recently at version 0.6.0), so details may change.