> ## Documentation Index > Fetch the complete documentation index at: https://jam.dev/docs/llms.txt > Use this file to discover all available pages before exploring further. # Jam for AI agents > Give your agent a Jam and it works from the recording. Guides for fixing from a Jam, proving a fix, filing tickets, and writing tests. Your agent sees what you saw, and shows you what it did. A Jam carries the video, what the person said, every click, the console, and the network. Connect Jam to your agent once and paste the link. The agent gets all of it, like a colleague who watched the recording. With the Jam CLI, it can also record a Jam of its own, so you see a fix working instead of reading that the tests pass. ## Guides > **[Hand a Jam to your agent](https://jam.dev/docs/hand-a-jam-to-your-agent.md)** > > Paste a link and get an explanation, a reply, a fix, or a feature. > **[Prove a fix](https://jam.dev/docs/prove-a-fix.md)** > > Your agent records the fix working and posts the Jam on the pull request. > **[Turn Jams into tickets](https://jam.dev/docs/turn-jams-into-tickets.md)** > > Turn many Jams, or one feedback session, into tickets. > **[Turn a Jam into a test](https://jam.dev/docs/turn-a-jam-into-a-test.md)** > > Get a test in your own runner, written from what the Jam shows. ## Agents prove their work Coding agents now write a growing share of the code. Writing a fix got cheap. Knowing whether the fix is what you asked for, and whether it works, did not. The diff shows what changed in the code. It does not show what the app does now. "Tests pass" is the agent's word for it, and the agent's tests can pass while the screen the person reported is still broken. Pulling every branch to check stops working once agents open pull requests faster than you can pull them. The more work you hand to agents, the less of it you have seen. The scarce resource is your attention: the minutes you spend deciding whether an agent's change is right. Proof should cut those minutes without letting more bugs reach your users. If more bugs get through, the time you saved in review goes into fixing them. A person can watch a short Jam in seconds, and another agent can read it. The person who reports a bug, the agent that fixes it, and the reviewer who checks the fix all work from the same recording. ## From report to test Jams come in from your team, your customers, and your agents. Each step in the loop uses a tool you choose: the tracker, the coding agent, the reviewer, the QA agent, the test runner. Swap any of them. The Jam is what passes between them, and each Jam links the next: its ticket, its pull request, and the Jams that fix or prove it. Open any Jam in the chain and you can follow the bug from the report to the test. 1. **Someone shows what is wrong.** Your team records it with the [Chrome extension](https://jam.dev/docs/creating-a-jam.md), [Jam for Mac](https://jam.dev/docs/mac.md), or [Jam for iOS](https://jam.dev/docs/ios.md). Customers record it from a [Recording Link](https://jam.dev/docs/recording-links.md), with nothing to install and no account. Agents record it with the [Jam CLI](https://jam.dev/docs/cli.md) while they [drive the app](https://jam.dev/docs/cli-record-browser.md). 2. **The Jam goes on a ticket.** Tickets are the agents' work queue. A folder of reports can become one ticket per cause. See [Turn Jams into tickets](https://jam.dev/docs/turn-jams-into-tickets.md). 3. **An agent reads the Jam and fixes the code.** It reads the transcript, the errors, the failed requests, and the frames around the failure, instead of guessing from a one-line description. See [Hand a Jam to your agent](https://jam.dev/docs/hand-a-jam-to-your-agent.md). 4. **The agent records the fix running.** It drives the app in a headless browser, records the fix, and posts the Jam on the pull request. On the bug Jam, the recording shows as fixed by. See [Prove a fix](https://jam.dev/docs/prove-a-fix.md). 5. **The reviewer checks the recording.** A person or a review agent checks the fix in the Jam instead of taking the agent's word. 6. **A QA agent checks the change before release.** After merge, the QA agent drives a browser, tests the ticket on a staging or preview build, and records a Jam per check. A pass goes on the ticket. A failure is a new bug report and starts the loop again. See [Record an agent's browser](https://jam.dev/docs/cli-record-browser.md). 7. **The proof becomes a test.** The Jam of the fix turns into a test that protects the flow, so the bug stays fixed. See [Turn a Jam into a test](https://jam.dev/docs/turn-a-jam-into-a-test.md). ## Where you stay in the loop Agents write the fix, test it, record the proof, and check each other's recordings. A person still makes three calls: * **What is worth fixing.** You decide which reports become tickets, and which tickets go to an agent. * **Whether the proof holds.** You watch the Jam, or the runs a review agent flags, and decide whether it shows what the pull request claims. * **When to merge.** The agent posts proof where you ask. The merge is yours. If your agents already open pull requests, tell us which checks you still do by hand and what we got wrong. With Jam MCP or the Jam CLI connected, ask your agent: ```text wrap theme={"theme":"css-variables"} Send feedback to Jam: our agents open pull requests, we still check by hand, and . ``` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.