I connected Rocket.Chat and Webex with two AI agents, and a two-key rule keeps them honest

A vendor ships a bad config. A customer's orders API starts returning 500s. The fix is one line. It still takes all day, because the customer lives in self-hosted Rocket.Chat, the vendor lives in Webex, and the only bridge between them is a ticket portal.

I wanted to see if AI agents could close that gap without anyone handing an outside agent the keys to production. The result is TwoKey, built on Switch, an open-source platform that puts AI agents into the chat tools teams already use.

Here's what I built, how to set up something similar, and what surprised me.

What it does

Each company keeps its own chat app and its own agent:

1. A person at the customer tells their agent quotes are failing.
2. The agent reads the logs, finds the bad vendor file, and crosses into the vendor's room to brief their agent.
3. The vendor's agent writes a patch. An engineer approves it from a card in Webex. That's key one.
4. The request comes back, and a person at the customer approves it in Rocket.Chat. That's key two.
5. Only then does the patch apply.

Each key is a real Ed25519 signature over the patch's hash. If anyone edits the patch after signing, it's refused. One key changes nothing.

That's the whole product: change approval between companies. An outage is just the easiest way to show it. In the last three full runs, the agents went from the report to the vendor's approval card in 40 seconds, 60 seconds and just under 2 minutes, and the people involved pressed two buttons.

You can try the gate itself in about a minute, with no chat apps or accounts:

git clone https://github.com/NishaadG/twokey && cd twokey && ./scripts/try.sh

It runs the real signatures and board, then tries to cheat: it edits the signed patch, which is refused, and rewrites the ledger, which the audit catches.

The Switch ideas you need

If you're new to Switch, four ideas cover almost everything here:

• Rooms. A Switch room is bridged to one channel on one chat platform. People talk in their normal app, and agents join the room.
• Room links. A link is a labelled pointer from one room to another. It tells an agent the other room exists, but it doesn't grant access. The agent still has to be a member.
• Hops and targeted messages. connect_to_room moves an agent into another room, and send_targeted_message wakes a specific agent there.
• Approval cards. When an agent wants to run something that needs permission, Switch posts a card in chat, and records who answered it and from which platform.

Setting it up

Switch has a quickstart at docs.switchagents.ai. Here's what I'd tell a first-timer that isn't obvious from it.

On Windows, Console can't host agents itself. It needs a Linux machine over SSH. I used Ubuntu under WSL with an SSH server on a local port. Two things caught me: Console's ~ expansion relies on HOME, so use an absolute IdentityFile path, and it multiplexes many sessions over one connection, so raise MaxSessions in sshd.

The "CLI not installed" warning can be wrong. For an SSH host it showed even though the agent ran fine.

New agents start in Auto mode. Safe-looking commands run without asking. If you want approval cards, turn it off.

If you restart the server, restart the agent's watcher too. Mine never reconnected, and the agent just said it wasn't online in the room. It took me a while to work out that the bot was telling the truth.

What surprised me

Approvals stay in the room where the turn started. My first design used one agent that hopped between rooms and collected an approval in each. The hop worked, but the card came up in the original room, every time. So I gave each company its own agent. That turned out better in every way: it's what real companies would want, and it made the story simpler.

Too many cards ruin the story. My first run asked for approval on every read-only check. People would have stopped reading after the third one. I changed the workflow so agents only use plain read commands, and folded opening the change and signing it into one command. Now there are exactly two cards, and each one means something.

Live APIs don't match mocks. I wrote the Webex adapter with tests that mock the API, and they all passed. The first real run failed because Webex refuses a message that has both a card and a mention: Mentions not allowed to be used with attachments. Webex also limits how fast you can create webhooks, so a quick reconnect could leave a bridge with only some of them. Neither showed up until I tested against the real service.

An approval button isn't proof. A button press only matters if something enforces it. That's why the gate verifies signatures itself, and why the board reads who approved from Switch's record rather than trusting what an agent says.

What's honest about it

The two companies and the service are fictional. The chat apps, agents, approvals and signatures are real. In the demo both private keys sit on one machine, and in real use each company would hold its own. The signatures protect the patch, not the host, so the approval step is only as strong as the machine asking for it.

Try it

The code, setup steps and tests are at https://github.com/NishaadG/twokey. If you're building with Switch, start with one room and one agent, turn Auto mode off, and watch your first approval card arrive. It's a good feeling.