mint_url included — before the Playground can tell you anything. What it saves you is writing a client to find that out.
Use it for two different jobs: iterating on the agent itself, and proving your backend works before you build a client against it.
Running as someone
An agent run needs a subject, so the Playground gives you personas — a named subject bound to a connection.
Personas are unique per connection and subject, so the same string is one persona per host. Switching personas switches thread history and memory with it, because both partition on the subject — which makes personas the fastest way to see what a returning user experiences versus a first-time one.
Use a subject your backend knows
A persona’s subject is not a placeholder. It becomes the run’ssubject_ref and travels the egress chain unchanged — Patchwork posts it to your mint_url as { "subject": "…" }, you mint a token whose sub is that string, and your endpoint reads it.
So if your tools resolve a subject, the persona has to name one your system can actually find. A persona of test-persona-1 arrives at your backend as a user id that does not exist, and your endpoint rejects it — or resolves it to nothing and appears to succeed.
The Label field exists so personas can have friendly names. Put “New customer” there, and a real identifier — ideally a seeded test account, in the exact shape production will use — in the subject.
If your tools do not care who is asking, none of this applies and any string will do.
What you get on every run
Everything the API gives you, in the panel beside the conversation:- The trace — every model call, every tool call, arguments, results, timings, cost. Same trace the API returns.
- Memory — facts and episodes the agent has accumulated for that persona, with the ability to delete one or forget the subject entirely.
- Threads — saved conversations per persona, so you can return to one.
Playground memory is separate
Playground threads are recorded with a sandbox origin, and subject memory keeps live and sandbox partitions apart. Experimenting will not teach your production agent anything, and production conversations will not leak into your testing. That isolation covers the Playground only. Traffic you send through the API islive even when you think of it as a test — prefix those subjects if you want them separately erasable. See Memory.
Testing your backend before you integrate
This is the part worth planning around. The Playground exercises the same egress path as production: if your agent wires a patch that calls your host, the Playground really calls it, signed, with a real subject. So you can have your connection, your patches, and your tool endpoints working — verified end to end — before writing a single line of integration code.A sensible order
1
Publish an agent with no patches
Every agent can already ask questions and hand off. Get the system prompt right against a persona before anything touches your backend. See Your first agent.
2
Create a connection and press Test
You want
verified, not merely reachable — see Connections. This proves your request secret matches before any agent depends on it.3
Wire one read-only patch
Run it in the Playground and read the trace. The
request on the tool call shows exactly what reached your host.4
Wire a write, set to Always ask
Approve and reject it in the Playground and watch both paths in the trace. See Confirmations.
5
Only then integrate
By this point the agent, connection, patches, signing, and minting are all proven. What is left is client code.
What the Playground cannot show you
It is relay-shaped by construction, so a few things only appear once you integrate:
A connection whose egress only works by reusing a browser JWT cannot be driven here at all — there is no browser and no JWT. That is not a Playground limitation to route around; it is the same reason relay exists.