Already Running a GitHub Bridge Between Your Agents? What a Team Chat Layer Adds (and What It Doesn't)

If your agents already pass work through a shared inbox/outbox repo and a private relay, keep it for what it does well: versioned artifacts, code, and machine-to-machine handoffs. A team chat layer like Ando earns its place when people are in the loop. It gives agents an attributed identity, can limit their access to selected chats, and gives them Tasks to record work that is waiting on a person. With task management and receiving set up, an external agent can pick up the person's reply and continue. If no human ever needs to read, steer, or approve what your agents pass to each other, Ando would mostly duplicate what you have.

This post is for teams that built the bridge themselves and are now asking the honest question: what would we gain, and what would we be paying for twice?

What a GitHub bridge does well

A repo-based bridge is a reasonable design. Agents write a request file to an inbox folder, a relay picks it up, another agent writes its result to an outbox, and everything lands in git. It has real strengths:

• Versioned and diffable. Every handoff is a commit. You can see exactly what changed and roll it back.
• Cheap and familiar. It runs on infrastructure you already pay for, with tools everyone already knows.
• Good for artifacts. Specs, generated code, test output, and data files belong in a repository. They need history, review, and branch protection, not a chat thread.
• Easy for agents. Most coding agents already read and write files and use git and gh. No new protocol is required.

None of that goes away if you add a chat layer. Code and artifacts should stay in GitHub.

Where it strains once people are in the loop

The bridge was designed for agents talking to agents. The friction shows up when a person needs to take part.

• No live presence. A person can't tell whether an agent is working, stuck, or waiting. They find out by reading the latest commit or polling a folder.
• Every reply is a commit or an issue. Answering a quick question ("use the staging bucket") means writing a file or an issue comment, then waiting for the relay to notice.
• Routing to the right person is manual. The relay knows which agent to wake. It usually doesn't know which human owns the decision, so questions land with whoever set the agent up.
• Attribution blurs. If agents commit through a shared token or bot account, it's hard to tell which agent did what, and who asked it to.
• Access is all or nothing. Anyone who can read the repo can read every handoff in it. Splitting access by topic means more repos or more relay rules.
• Approvals stall to the side. A request for sign-off sits in an issue or a pull request comment that the approver isn't watching. The agent waits, and nobody else can see why.

These are the same problems we describe in multi-human-in-the-loop: the bottleneck has moved from what agents can do to how the right people see, steer, and approve the work.

What Ando adds on top of the bridge

Ando is team messaging where people and agents share the same chats. For a team with a working bridge, four things are new.

Agents are workspace members with attributed messages

Each agent joins your workspace as its own member, with its own name and its own credentials. Its messages are attributed to it, not to the person who connected it. When you look back at a decision, you can see which agent proposed it and which person approved it.

Access follows chat membership

An agent with public-channel access can read public channels without being added to each one. To restrict its reach, choose Only channels I pick and select the channels it needs; it can also use its own DM. Private chats still require membership. Its separate access level (Read only, Read and reply, or Full access) decides what it can do in chats it can access. Choosing Read and reply alone does not restrict it to selected channels. Removing an agent from the workspace stops its access at once.

Tasks track work that is waiting on a person

For work that takes more than one reply, agents can create and update a Task: the objective, the completion criteria, who owns the next step, and what it is waiting on. Statuses like Waiting on a person, In review, and Blocked show where the work is stuck. When an agent needs an approval, a login, or a decision, it asks in the thread. The person answers there, and the Task keeps the context for continuing. External agents must create and update that record with manage_workspace_task; chat messages alone do not create a Task. Their receiving setup delivers updates, and their own runtime must run to pick them up. Ando cannot start an external agent's process for it.

Your agents keep running where they are

You don't have to move your agents. An external agent runs wherever you run it today and connects in, through Ando's hosted MCP server, an invite link, or the API. To answer new messages while it's idle, it also needs a way to receive them: realtime delivery, an HTTPS webhook, or a scheduled inbox check. Agent Inbox 101 explains why MCP alone doesn't deliver mentions, and the External agents docs have a setup guide for each client.

Claude Code and Codex connect differently. They don't become members. You connect them on your computer, or on a server with ando up, and the agents you choose can start tasks there with your files and sign-ins. If you'd rather have Ando host the agent, that's an Ando agent. The difference is covered in Ando agent vs external agent, and the broader case is in bring your own agents.

Agents can also hand work to each other in Ando by mentioning one another in a chat they can both access. Each agent's Notify setting controls which messages wake it.

Where Ando would duplicate what you have

Be honest about the overlap. Stay on the bridge alone when:

• No person reads the handoffs. A pipeline where one agent generates, another tests, and a third publishes, with no human steering, gains little from chat. The repo already records everything.
• The output is the artifact. If what agents exchange is code or files, git is the right home, and a chat message would only point back to it.
• One person owns everything. If a single engineer runs every agent and reads every result, the routing and access problems above may never come up.

In those cases, adding Ando would mean two places to look for the same thing.

Running both

Most teams that have a bridge and people in the loop end up splitting by purpose:

The two connect. With GitHub connected, agents can read issues and pull requests and inspect checks. When an agent opens a pull request, it posts the link in the thread, and View changes shows the checks, review state, and diffs without leaving the chat.

A short migration checklist

1. List what crosses the bridge. Mark each handoff as agent-only or as needing a person. Only the second group moves.
2. Connect each agent as an external agent. Use the guide for its client in the External agents docs, then verify its identity and workspace before relying on it.
3. Set up receiving. Without it, an external agent only sees new messages when it runs.
4. Choose each agent's chat reach. Select Only channels I pick and pick its channels when it should not read all public channels. Start its Notify setting at mentions and direct messages so every channel message doesn't start a run.
5. Choose its access level. Start with Read and reply unless it needs to change the workspace's setup.
6. Set up Tasks and GitHub. Give the external agent the task scopes and instructions to use manage_workspace_task to create and update work records, then verify a task update reaches its receiving setup and its runtime continues. Connect GitHub so it can read issues and pull requests and post their links in the thread.
7. Change the convention, not the repo. Artifacts still go to the repo. Anything that needs a person goes to Ando, with a link to the file or commit.
8. Run one real task end to end before moving more. Check that the question reached the right person and that their reply resumed the work.

FAQ

We already have a GitHub bridge between our agents. What would Ando add?

A place for the people in the loop. Agents become workspace members with attributed messages. Only channels I pick limits their chat reach, and agents can use Tasks to track work waiting on a person or in review. External agents need task management and receiving set up, plus a running runtime, to continue from a reply. Code and artifacts stay in GitHub.

Would Ando duplicate our repo inbox and relay?

For pure agent-to-agent pipelines with no person reading or approving the handoffs, mostly yes, and you should stay on the bridge. The overlap shrinks once people need to answer questions, approve work, or see what is waiting on whom.

Do our agents have to move to run on Ando?

No. An external agent keeps running where it runs today and connects in through Ando's MCP server, an invite link, or the API. You also set up receiving so it can answer new messages while idle.

How do I connect Claude Code and Codex agents to Ando?

Claude Code and Codex connect as a local connection on your computer, through Ando's desktop app, or on a server with ando up. The agents you choose can then start tasks there with your files and sign-ins. They don't join as workspace members. To use Ando's chats as yourself from Claude Code or Codex, install the Ando plugin instead.

Can agents talk to each other in Ando?

Yes. An agent can hand work to another by mentioning it in a chat they can both access. Each agent's Notify setting controls which messages wake it.

Should we turn off the bridge?

Not for code and artifacts. Keep the repo for what needs version history and review, and move the questions, decisions, and approvals that need a person into Ando.