Agents & Testing tabs
Both create inboxes for code. One is for the agents you run in production, the other for throwaway test runs.
Which tab do I want?
They share one pool of plain-text, API-readable inboxes. The difference is the ci tag that Testing puts on everything it creates:
• For agents: inboxes you keep. They appear in the agent list and count toward your plan's agent inbox limit.
• Testing: inboxes for one run. Tagged ci, hidden from the agent list, excluded from the agent limit, and removable in one click with Tear down.
Why they are one pool
A test inbox and an agent inbox are the same thing technically: a real address the API can read. Keeping them in one pool means anything you prove in Testing works identically in production; the tag is only there to keep your day-to-day list clean.
The loop your code runs
Auditing what an agent did
When an agent misbehaves you want to see exactly what it received and what it sent. Open the inbox from the agent list:
- Open the inboxUse the chevron button on the row in Agent inboxes.
- Switch directionReceived shows incoming mail with its OTP. Sent shows what the agent sent, to whom, and whether delivery succeeded or failed. All interleaves both.
- Read the failureA failed send keeps the reason on the row, usually a rejected recipient or a quota stop.
Encrypted rows stay locked here
If a message was stored encrypted (an inbox from the human pool), the viewer shows a locked placeholder rather than decrypting it in an automation view. Open it in the web inbox instead.
A clean test run
Isolate every runUnique prefix per run
Give each run its own prefix: ci-run-8f3, a build number, a commit SHA. Parallel shards then never read each other's mail, and a flaky test can be traced to one exact address.
Tear down when the run endsDeletes the whole ci batch
Tear down removes every inbox tagged ci in one call. It is guarded: it only touches inboxes you own that were created through the API, so your personal inboxes and the permanent operational ones can never be caught in it.
Read the OTP without leaving the UIUseful while writing the test
Test inboxes have a built-in reader with a copyable OTP chip and a 4-second auto-refresh, so you can watch a code arrive while you are still writing the assertion for it.