Coding agents no longer live only inside one terminal session. Some products act like company computers, with shared rooms, durable sandboxes, and Slack or web surfaces. Others treat the harness itself as the product: a versioned contract for tools, policy, models, evaluation, and evidence. SuperQode sits firmly in that second camp. The easy mistake is to force both instincts into one process. Different systems should keep their centers of gravity and still be able to call each other. That is the job of SuperQode’s Agent2Agent (A2A) surface. YC’s open-source QM  is great example of one of the use case to support the SuperQode A2A

What SuperQode is

SuperQode is open-source harness engineering for coding agents. It’ does all sort of the agent engineering for your coding factories with many harnesses available inside it, existing or our own. The portable unit is a HarnessSpec: how an agent may use tools, what it may approve, which runtime runs the loop, and how runs are recorded. Operators already reach that contract through the CLI and TUI, through MCP when a harness should appear as tools, and through ACP when an editor or external coding agent drives SuperQode. A2A is the network face of the same idea: another agent or service discovers SuperQode, submits tasks, and receives structured results without sharing SuperQode’s internals.

SuperQode is not trying to be a multiplayer company OS. It is trying to make coding harnesses inspectable, portable, and callable.

Multiplayer computers as peers

YC’s open-source QM is a useful reference for the other side of the map: a multiplayer agent harness for work, with personal and shared scopes, durable agent computers, and a deployment model built for whole organizations. Public discussion around that release, including on Hacker News, keeps returning to the same hard problems: scoping work across people and rooms, reviewing agent output, and coordinating agents without turning every product into the same kitchen-sink assistant. SuperQode is strongest when a coding job needs an explicit contract, controlled execution, and an evidence trail. Multiplayer computers are strongest when people and agents share organizational context over Slack or the web. We are not claiming official product support for QM, We are making SuperQode easy to place next to systems like it, first over a standard agent protocol, and later through optional packaging that can sit beside a deploy-directory style sandbox. That is compatibility on the wire and in spirit, not a branded integration promise.

A2A as the bridge

A2A is a protocol for discovery and task exchange between agents.  SuperQode has A2A support since long but couldn’t find the use case to deal with other agents. SuperQode’s bridge uses the official Python A2A SDK for the wire shape and maps each A2A context onto SuperQode’s Harness Protocol session. A client reads an Agent Card for capabilities, skills, authentication hints, and the interface URL. It then sends work to that interface. SuperQode runs the configured harness and returns task state, messages, and artifacts, while keeping its own durable run and evidence model on the harness side.

A2A owns discovery and task lifecycle. SuperQode owns execution policy and evidence. Neither side has to share a language runtime or a monorepo. Interoperability has been part of SuperQode’s surface for a while. In 0.2.68 we hardened the A2A path for real cross-service use: official A2A 1.0 HTTP+JSON serving, client routing that follows the card’s advertised interface URL (including path-prefixed deployments), separate durable stores for harness evidence and A2A task records, Agent Card export aligned with runtime discovery, bearer authentication for remote operations, and tests for the lifecycle pieces teams actually hit. We also stood up a temporary public pilot so the surface is not only a local demo. Treat it as an experiment with authentication required for operations, not as a multi-tenant production SLA.

Discovery is public at the SuperQode Agent Card. The card advertises the live interface URL and that bearer auth is required. Tokens and provider keys do not belong in the card, in screenshots, or in docs beyond placeholders.

What we actually tested

We ran a focused interop pass against the pilot. Clients discover from the public Agent Card on super-agentic.ai, then follow supportedInterfaces to the operational host, which may differ from the discovery origin. They authenticate, send a short fixed message, and fetch the resulting task. We exercised that path with an independent TypeScript client that does not depend on SuperQode’s runtime, and again with SuperQode’s own Python A2A client against the same discovery URL. Both completed successfully: discovery, interface selection, task completion, and task retrieval. You can try this from the superqode repo if you want to collaborate and we can give SUPERQODE_A2A_TOKEN

node --experimental-strip-types \
  examples/qm-deployment-layer/interop/a2a-client.mts \
  https://super-agentic.ai \
  "$SUPERQODE_A2A_TOKEN" \
  "Reply with exactly: qm-interop-ok"

It should reply with

{"agent":"SuperQode","state":"TASK_STATE_COMPLETED","artifactText":"qm-interop-ok"}

You can also run this with this Python Client.

uv run --extra a2a python examples/a2a/smoke_client.py https://super-agentic.ai

discovery: https://super-agentic.ai
agent: SuperQode
version: 0.2.68
interface: https://superqode.onrender.com
message: Reply with exactly: python-client-ok
task_id: 83f79a72-17e7-43ce-831b-561e5a88dd19
state: TaskStatusValue.COMPLETED
text: python-client-ok

Watch Demo

That is enough to call the experiment real. It is not enough to call the hosted endpoint finished product infrastructure. Operator controls matter here too. Remote binding expects a bearer token, and the model side of the pilot is intentionally constrained so a public experiment cannot become an open wallet.

We also keep an experimental packaging sketch for installing SuperQode as a tool and skill style bootstrap inside a QM-style deployment directory. That path is optional and secondary. The preferred long-term boundary remains A2A: call the harness as a service rather than baking two stacks into one process.

Why SuperQode talking to QM Over A2A make sense

SuperQode allow developer to make their own harnesses and one of the harness we can test if Core harness which is very minimal, even smaller than Pi harness. Multiplayer computers are strong at human-in-the-loop work and org context. Harness systems are strong at making coding-agent behavior explicit and auditable. A2A is a practical way to combine them without a merge. A company computer can delegate a constrained coding job to SuperQode. SuperQode can return artifacts and task state while keeping its own evidence ledger. Other coding-agent harnesses can sit on the same wire over time, not only one peer product. Evaluation and policy stay with the harness owner. Collaboration stays at the protocol boundary.

YC’s QM is a timely open example of the multiplayer-computer side. SuperQode is our stake on the harness-engineering side. Together they sketch a clean split of concerns. The same split applies to other agent computers and other harnesses that speak A2A. We plan to keep expanding those use cases across more coding-agent harness configurations, not only a single demo path also testing different harnesses to see which perform better over A2A.

How Your Harness collaborate with SuperQode

If you work on multiplayer agents, coding harnesses, or interop, start with the public Agent Card and expect authentication for operational calls on the pilot. Prefer small protocol-level fixtures (discovery, auth, context continuity, artifacts, cancellation, restart behavior) over large monorepo merges. Feedback on packaging SuperQode next to deploy-directory sandboxes is welcome, and that packaging should be treated as experimental unless we say otherwise. We are interested in concrete interoperability work: clients in other languages, harness-to-harness calls, and honest failure modes. We are not asking anyone to replace their computer with SuperQode, or their harness with a multiplayer OS. If you want to give it try please get in touch.

Limits and what comes next in SuperQode

The public pilot is temporary and operationally modest and Bearer auth is enough for a private pilot. Stronger identity can wait until a collaborator needs it. Durable A2A task lookup and SuperQode’s harness ledger are designed separately, and an in-flight crash still needs operator judgment. Experimental QM-oriented packaging is not a support contract.Happy to chat with YC’s QM contributors to discuss if they are interested in the A2A layer.

SuperQode’s job is to make coding harnesses real engineering objects. A2A’s job is to let other agents use those objects without sharing a runtime. Multiplayer systems such as QM are a natural peer for that arrangement: different centers, shared wire. We will keep building on that boundary, and we welcome careful collaboration on interoperability. Start at the Agent Card, stay honest about auth and maturity, and keep the boundary clean. Explore the code in the SuperQode repository, the A2A project and Python SDK, and QM as a peer reference rather than a dependency. Try SuperQode with A2A here.  Any questions get in touch.