Forem: Bruno Xavier

I built a relay so my AI agents stop talking through me

Bruno Xavier — Sat, 28 Mar 2026 20:34:27 +0000

My coworker and I were both using Claude Code on a shared infra project. He was building services, I was setting up Pulumi. Our workflow was:

Claude tells me something about the deploy structure
I copy it into Slack
My coworker pastes it into his Claude
His Claude responds
He screenshots it back to me

We were the middleware. Two humans acting as a message bus between two AIs.

So I built Handoff — an open-source relay that lets agents talk to each other directly.

The idea

Give agents a shared communication layer with the same primitives they'd need if they were humans on a team: channels, threads, mentions, read receipts, and shared status.

Your Claude:     "ArgoCD expects deploy/{service}/kustomization.yaml"
Their Claude:    "Structured deploy/ to match. checkout-api, inventory-service ready."

No human in the loop. No copy-paste. No screenshots.

How it works

1. Create a team (one curl)

curl -X POST https://handoff.xaviair.dev/api/signup \
  -H 'Content-Type: application/json' \
  -d '{"team_name":"my-team","sender_name":"my-name"}'

You get back an API key. Share additional keys with teammates via the create_key endpoint.

2. Everyone adds the MCP server (one command)

claude mcp add handoff \
  -e RELAY_API_URL=https://handoff.xaviair.dev \
  -e RELAY_API_KEY=your_key_here \
  -- npx -y handoff-sdk

That's it. Claude now has 17 tools for coordination — it discovers and uses them naturally as part of your workflow.

3. Agents coordinate directly

Claude gets tools like post_message, read_unread, set_status, ack. When you tell it "check the build channel for updates" or "let the deployer know we're ready", it knows what to do.

What's in the box

Channels & threads

Agents communicate through named channels (build, deploy, review). Messages support threading — reply to a specific message to keep conversations organized.

Mentions

When posting a message, agents can set a mention field to direct it at a specific agent. The receiving agent filters on their name to find messages meant for them.

Read receipts (acks)

After reading messages, agents call ack with the last message ID. Other agents can check get_acks to see who's caught up. There's also read_unread which returns only messages after your last ack — the recommended way to poll for new work.

Shared status

Key-value status entries on channels represent shared state: stage = building, lock = agent-1, progress = 4/5. Every write is logged, so you can query the full status change history.

Real-time streaming

SSE endpoint for real-time push. Agents don't have to poll — they can subscribe to a channel and get messages as they arrive.

E2EE

Optional AES-256-GCM client-side encryption. Set an encryptionKey in the SDK and the server never sees plaintext message content.

Channel-scoped permissions

This is the feature I'm most proud of. Each API key gets a permissions map that controls exactly which channels it can access and at what level:

{
  "build": "write",
  "deploy": "read",
  "monitoring": "read"
}

Three levels:

read — view messages and status
write — read + post messages, ack, set status
admin — write + delete channels and messages

Use "*" as a wildcard for full access across all channels.

I tested this with a 7-agent deployment simulation:

Agent	Permissions
orchestrator	`*: admin`
builder	`build: write`, `deploy: read`
reviewer	`review: write`, `build: read`
deployer	`deploy: write`, `build: read`
monitor	`monitoring: write`, `build+deploy: read`
qa	`review: write`, `build+deploy: read`
notifier	all channels: `read`

The simulation ran a full deploy pipeline — orchestrator kicks off, builder compiles and posts results, reviewer approves, QA signs off, deployer rolls out, monitor checks health. Every unauthorized write was blocked. The notifier could read everything but write to nothing.

This means you can give a junior dev's agent read-only access to production-deploys while letting senior agents write to it. Or give a monitoring bot read access everywhere without the ability to post.

TypeScript SDK

If you're building custom agents outside of Claude Code:

npm install handoff-sdk

import { Handoff } from "handoff-sdk";

const hf = new Handoff({
  apiUrl: "https://handoff.xaviair.dev",
  apiKey: "relay_..."
});

await hf.post("infra", "EKS cluster ready", { mention: "jordan" });
await hf.reply("infra", msgId, "What node instance type?");
await hf.setStatus("infra", "eks", "ready");

const unread = await hf.read("infra");
const unsub = hf.on("infra", (msg) => console.log(msg)); // SSE

Architecture

The server is Go with Redis. Messages use Redis streams for ordered IDs, cursor-based pagination, and blocking reads for SSE. All keys are team-namespaced (t:{teamID}:) for multi-tenant isolation.

server/           Go (net/http + go-redis)
├── store/        Redis data layer (34 tests)
├── handler/      HTTP handlers, middleware, SSE (48 tests)

src/              TypeScript
├── sdk.ts        SDK with E2EE support
├── mcp.ts        MCP server (17 tools)

82 tests, self-hostable with docker compose up -d. The Go binary is ~15MB.

What's next

Message schemas/contracts so agents can agree on content format
TTL/expiry for channels and messages
Per-key rate limiting
Dashboard for observing agent conversations in real-time

Try it

The hosted relay is free at handoff.xaviair.dev. Self-host with Docker if you prefer.

GitHub: github.com/bfxavier/handoff
npm: npm install handoff-sdk
MCP setup: one command, shown above

If you're running multi-agent workflows and tired of being the message bus, give it a shot. Stars appreciated.

Every company I've worked at had the same broken interview process

Bruno Xavier — Fri, 13 Mar 2026 19:06:43 +0000

There's a dirty secret in tech hiring: the people actually doing the interviews have zero tooling.

HR has their ATS. Recruiters have their pipelines. And the tech lead who just spent 45 minutes evaluating a senior engineer candidate? They have a Slack message and a fading memory.

I've been on the interviewer side of this at several companies — as a tech lead, staff engineer, head of development. I've done hundreds of technical interviews across these roles. And every single company had the same problem.

The "system"

Here's what interview feedback looks like at most engineering teams I've been part of:

Someone writes a few lines in Slack right after the interview
Someone else waits until the debrief meeting and goes from memory
A third person opens a Google Doc, writes half a page, then never shares the link
Everyone shows up to the hiring debrief with completely different formats and criteria

You end up in a meeting where one person says "she was really strong technically" and another says "I didn't love the communication" and there's no way to actually compare because everyone evaluated different things in different ways.

The candidate who interviewed on Monday gets a different process than the one who interviewed on Friday. It's not fair to them and it leads to bad decisions.

Why nobody builds for this

There's a whole industry of hiring tools, but almost all of them are built for HR and recruiters. They're ATS platforms — Greenhouse, Lever, Ashby — with scorecards bolted on as a feature.

The problem is that the tech lead never logs into the ATS. They get a calendar invite, do the interview, and need to put their feedback somewhere fast. They're not going to learn a new platform for this. They're not going to ask their manager for a Greenhouse license.

So the feedback goes into Slack. Or Obsidian. Or nowhere.

What I built

I got tired of this and built techscore.dev — a simple scoring app for technical interviews. No backend, no signup, no data leaves your browser. Just open it during or after an interview and score.

It evaluates candidates across 6 categories:

Smart — problem decomposition, adaptability, structured reasoning, learning agility
Get Things Done — delivery track record, live coding execution, pragmatism, ownership
Drive — initiative, self-motivation, ambition, persistence
Culture Fit — collaboration, communication, humility, values alignment
Technical Experience — architecture, testing, frameworks, code quality
Domain Experience — domain knowledge, data & analytics, tooling, industry awareness

Each sub-competency gets a 1-4 score. You can add notes per item. The sidebar shows a running total. When you're done, you export a markdown scorecard and drop it wherever your team communicates — Slack, Notion, a PR comment, whatever.

That markdown file is the whole point. It's structured, it's consistent, and when three interviewers all export one, you can actually compare them side by side in the debrief.

The categories are opinionated

I know. Six categories with four items each is a specific framework, not a universal truth. It's based on what I've found useful over years of interviewing engineers — loosely inspired by the "Smart and Gets Things Done" philosophy but extended to cover the things I kept wishing I had tracked.

You might disagree with some of them. That's fine. I'd rather give you an opinionated starting point than a blank template where you have to invent your own rubric every time.

What happened when I shared it

I originally built this just for myself. Then I shared it with the other engineers doing interviews at my company and something unusual happened — they actually used it. Repeatedly. Without me nagging them.

That almost never happens with internal tools. It only works when the tool is faster than whatever someone was already doing. In this case, the bar was "write a Slack message," so the tool had to be really low friction to beat that.

Try it

techscore.dev — open it, score a candidate, export the scorecard. Takes about 2 minutes.

If you do technical interviews and have opinions about the scoring categories, I'd love to hear them. The framework is the part I'm least sure about and most interested in iterating on.

Quick Raspberry Pi rTorrent and RuTorrent Install

Bruno Xavier — Tue, 16 Mar 2021 18:30:56 +0000

Do you want to transform your Raspberry Pi into a lightweight, always on, seedbox? For this project, we are going to do just that using rTorrent and RuTorrent, using a fresh Ubuntu 20.04 install.

What is rTorrent and RuTorrent?

rTorrent is a text-based BitTorrent client, based on ncurses, that relies on the libTorrent libraries for Unix.

RuTorrent is a web UI interface for a torrent application, rTorrent. It helps you to connect, manage, remove torrents to your slot, monitor rTorrent settings, and do a lot of other things through its plugins.It is a highly powerful torrent application and has rich features.

Getting started

Make sure your machine is up-to-date by running

sudo apt update
sudo apt upgrade

Make sure to also write down your LAN ip

hostname -I

Installing rtinst

We'll be using rtinst, a bash script setup, that will take care of most of the installation.

Just run the following command to install it

sudo bash -c "$(wget --no-check-certificate -qO - https://raw.githubusercontent.com/arakasi72/rtinst/master/rtsetup)"

Installing rTorrent and RuTorrent

Now that we have rtinst installed, we just need to run it and watch the magic happen

sudo rtinst -l -d -t

We are passing the following parameters

-l enables log output to ~/rtinst.log
-d enables http downloads
-t keeps the default ssh port

Now a few prompts will show, asking you which IP Address to use, which you should point to the one found above and asking you to confirm it. It will also ask you to enter a password for the WebUI.

You'll see the following in your prompt

Set Password for RuTorrent web client
Enter a password (6+ chars)
or leave blank to generate a random one
Please enter the new password:
Enter the new password again:
No additional users to add

No more user input required, you can complete unattended
It will take approx 10 minutes for the script to complete

Now go grab a cup of coffee and wait for the installation to finish.

If everything goes well, you should see all the info necessary to access your fresh RuTorrent Web UI

Summary of Installation (Important Information, please read

SSH Configured
   SSH port set to 22
   root login directly from SSH disabled
   login with ubuntu and switch to root using: sudo su

FTP Server
   vsftpd 3.0.3-12 installed
   ftp port set to 46628
   ftp client should be set to explicit ftp over tls using port 46628

rtorrent torrent client
   rtorrent 0.9.8 installed
   crontab entries made. rtorrent and irssi will start on boot for ubuntu

RuTorrent Web GUI
   RuTorrent 3.10 installed
   rutorrent can be accessed at https://10.10.10.1/rutorrent
   rutorrent password as set by user
   to change rutorrent password enter: rtpass

   If enabled, access https downloads at https://10.10.10.1/download/ubuntu

IMPORTANT: SSH Port set to 22
IMPORTANT: SSH Port set to 22
IMPORTANT: SSH Port set to 22
Please ensure you can login BEFORE closing this session

The above information is stored in rtinst.info in your home directory.
To see contents enter: cat /home/ubuntu/rtinst.info

To install webmin enter: sudo rtwebmin

SCROLL UP IF NEEDED TO READ ALL THE SUMMARY INFO
PLEASE REBOOT YOUR SYSTEM ONCE YOU HAVE NOTED THE ABOVE INFORMATION

Thank You for choosing rtinst

If you follow the URL you should be greeted with the RuTorrent WebUI!

Conclusion

Thanks to rtinst, installing rTorrent with ruTorrent is a breeze.

Hope you all enjoyed it!