How do you coordinate local and remote coding agents using different model vendors?

[smilejsu82]

We have two coding agents working asynchronously across separate machines and repositories:

• a client/game agent running locally (Claude-family model)
• a server agent running on a Linux VM (Codex/GPT-family model)
• neither agent is a permanent daemon; a human starts sessions as needed
• each agent has authority only over its own repository/environment

Release coordination includes requests such as “promote Android build 294 now, keep iOS at 293 until review passes.” The receiver must verify live state, perform only the authorized mutation, and report evidence back. The different models have separate context windows and cannot share native session state.

We currently use a dedicated GitHub issue as an append-only shared room. A small CLI provides pull, peek, and send, adds [server → client] / [client → server] prefixes, and stores the last-seen comment ID locally. Implementation/bug work remains in separate issues and PRs. This is auditable and works across NAT without exposing the VM, but it is still a deliberately small message relay rather than full agent orchestration.

For teams running a similar local-agent ↔ remote-VM-agent setup—especially with different model vendors—what has worked reliably in practice?

1. Do you use GitHub Issues/Discussions, a queue (Redis/NATS/SQS), webhooks, MCP tools, A2A, or structured handoff artifacts?
2. What minimum message schema do you use beyond free text: task ID, requested action, scope, expected state, observed state, approval requirement, acknowledgement, result/evidence, and correlation ID?
3. How do you prevent duplicate execution, stale requests, or one model interpreting another model’s prose too broadly?
4. Do you exchange full conversation context, or only durable facts plus links to commits/issues/artifacts?
5. Where do you place the human approval boundary for deployments and other external mutations?
6. At what scale did a simple GitHub-backed inbox stop being enough and justify A2A or a real message bus?

I am especially interested in operational lessons from systems people use day to day, including failure modes. Architecture diagrams, small schemas, or links to open-source implementations would be very helpful.

[bobleer]

GitHub as the inbox is honestly fine until “read request” and “claim mutation” need to be one atomic operation. I’d keep the wire payload small: job_id, operation_id, expected_state, scope, approval_policy, and immutable commit/artifact refs. Persist before ack, make submit idempotent, and let status advance by cursor. A lost submit response should become submission_unknown, never a reason to mint a second job.

I’m building BitFun, and this is roughly where our detached-dispatch design landed: the target owns the job, worktree, event log, and permission mailbox; the controller can disappear and later resume as an observer. Sync is Git-based and fast-forward-only rather than shared filesystem state. The design is here: https://github.com/GCWing/BitFun/blob/main/docs/architecture/detached-task-dispatch.md

I’d add those identity/state fields to your Issue relay before replacing the transport. NATS or A2A won’t fix ambiguous authority; they’ll just deliver it faster.

[sylvesterkaczmarek]

I'd keep GitHub as the transport for now. Give every request an operation ID, expected state, scope, approval requirement, and immutable commit/artifact refs. I'd only move to NATS/SQS once you actually need atomic claiming or much higher throughput.