Skip to main content
Both modes run the same agents, produce the same traces, and call the same patches. They differ in one thing: who holds the credential and makes the request. You do not declare a mode. The form of the bearer token selects it — a JWT is direct, anything else is a relay API key. Both are ways to put the agent in your product. If what you want is your users reaching the agent’s tools from their own AI client, that is a third door with its own page: MCP export.

​
The comparison

​
Start with relay

Relay is the shorter path and the one the Quick start uses. Your backend already authenticates your users; it makes the call and tells us who it is acting for. Nothing to host to begin with — though the moment the agent calls your backend, you host a mint endpoint (see below). Choose relay when the channel is not a browser you control — a Slack bot, an inbound email handler, a nightly job — or when you want your backend in every path for logging, policy, or rate control.
Relay integration →

​
Move to direct for a product UI

Direct removes the hop: the browser talks to us with a token your backend signed and we verified. Your workspace key never leaves your servers, and the token expires in minutes. The cost is infrastructure. You generate a keypair, publish a JWKS document, and add an endpoint that mints tokens for signed-in users.
Direct integration →

​
What actually differs at runtime

Only the provenance of the subject. In relay we trust what your backend asserts; in direct we verify a signature. Everything downstream — thread scoping, memory, traces, gates — behaves identically.
The one asymmetry worth knowing: a relay API key can assert any subject in your workspace, so it must never reach a browser or a mobile client. A direct session token can only ever be the subject it was signed for. See Subjects.

​
You can run both

They are not exclusive. A product with a web chat and a Slack bot uses direct for the first and relay for the second, against the same agent. Threads stay separate because the subjects differ — user_9f2 and slack:T04AB:U0APP are different partitions.

​
When the agent calls your backend

This is where relay stops being “nothing to host.” When a wired patch calls an endpoint you run, the egress request carries two things: a Patchwork-Signature over your request secret — verified the same way in both modes — and a short-lived subject token, so your endpoint knows who it is acting for. Where that token comes from is the difference:
  • Relay — Patchwork holds no token, so it mints one by POSTing to your connection’s mint endpoint. That endpoint is the one thing a relay integration hosts.
  • Direct — Patchwork reuses the session token the browser already presented; no extra call.
So a relay integration hosts nothing until the agent needs your backend — and a mint endpoint from then on.

​
The third door: their own AI client

Relay and direct are both your product calling us. MCP export is the other direction: a published agent’s tools become available inside Cursor, Claude or ChatGPT, and your user’s own client makes the call. It is not a mode you choose between — you can run it alongside either of the above, on the same agent. The credential is neither a key nor a session token but an OAuth grant the user holds, and the one thing you host is a login bridge so they authenticate with you. The run, the trace and the signed egress call to your backend are identical to relay.