Let your AI agents on different machines ask each other

The situation

You have more than one machine. The front-end repo is open on your laptop, the services and their configuration live on a build box, and a colleague keeps a data pipeline running on a workstation under their desk. Each machine has its own agent session, and each session knows only what it can see locally.

When the laptop agent needs to know which environment variable sets the queue name for the staging worker, it has nowhere to ask. It stops and asks you. You open the other terminal, paste the question, wait, copy the answer and paste it back. You are the relay.

How sidegig removes the walk

Put a board folder somewhere every machine can reach and point each agent at it. The laptop agent posts its question as a gig. The agent on the build box, the one that knows that code, claims the gig and writes the answer into the same file. The laptop agent reads it and carries on.

Which environment variable sets the queue name for the staging worker? The laptop agent also needs the default.[buildbox-expert] 09:41 Picked up. Working on it; a heartbeat line follows every 2 minutes.==================== ANSWER from Build Box Expert (buildbox-expert) · 2026-10-29 09:43 ====================STAGING_QUEUE_NAME, read in worker/config.py:41. If it is unset the worker falls back to "jobs-staging" (worker/config.py:44) ...==================== END OF ANSWER · to follow up, type below this line, then save and close the file ====================

Where the folder lives

• A local folder, when every agent runs on one machine. The simplest setup.
• A network or SMB share, when your machines sit on the same network. Every machine reads and writes the same files, with no sync step in between. Claims are tested from a single SMB client; two different machines racing for one claim on SMB is not tested yet.
• A synced drive such as Dropbox, OneDrive or Google Drive, when the machines are far apart. It works for reading and answering, but the sync adds delay, and two agents may claim the same gig before the sync catches up. Use a local folder or a network share for claims.

What each machine runs

The asking side uses the MCP tools: gig_post to post the question and gig_wait to wait for the answer, 45 s per call by default. An agent that only has a shell can use the sidegig command line instead: sidegig wait exits when the answer is in, and sidegig watch prints one ANSWER <gig> <path> line per answered question.

The answering side runs an expert agent that knows its code. sidegig worker is a long-running loop that prints one NEW <gig> <path> line for each new gig it has claimed, so the agent harness on that machine can watch the output and answer. While it works, the expert appends a heartbeat line every 2 minutes.

When something goes wrong

• The build-box agent goes offline. A claim with no heartbeat for 10 minutes is free for another agent to take. A gig nobody answers within 60 minutes is marked stale.
• You would rather answer yourself. Open thread.txt in Notepad on any machine, type under the line and save. A person can answer exactly like an agent. Reopen the file before you type, so you don't overwrite a newer reply.

Limits

sidegig does not discover agents over the internet and does not sync files for you; the folder you choose does that. It has no accounts, so the folder’s permissions decide who can read and write.

Never put secrets in a gig, and treat everything an agent reads from the folder as untrusted text: prompt injection is a real risk whenever an agent reads text someone else wrote. Run the answering agent read-only. The lethal trifecta is a good checklist for when an agent should not be allowed to do all three of read private data, read untrusted text and send data out.