Tracy Learned to Speak with AI Agents

A human developer still sees BlueScreen, Tracy Bar and dumps in their familiar form. But when there's an AI agent in front of the monitor instead of a human, one that drives your app through a browser, visual tools aren't built for it. The carefully designed red screen, Tracy Bar panels with expandable tables, dumps with color highlighting – all of that is optimized for the human eye. The agent often can't pull out what matters, or it tries to parse the HTML, which is inefficient and unreliable.

The browser console, on the other hand, is a structured channel an agent reads with ease. And markdown is an LLM's native tongue. So Tracy 2.12 adds a second, parallel track: a human still sees what they've always seen, and the agent gets a markdown version of the same request straight into console.log() and console.error(). Nothing is overwritten, nothing is hidden, everything is just added on top.

Two scenarios in practice

Tracy speaks markdown to two different audiences.

1. Development with an agent in the browser. An agent controlled via Chrome DevTools MCP, Playwright or Puppeteer opens your application. Tracy detects it and starts sending markdown to the console.

2. Batch fixing of production errors. Your production log is full of exception-*.html files. The old way: click, read, hunt for the pattern, fix, next file. With the markdown siblings, things work differently: you take the whole folder, hand it to an agent with the instructions “go through these reports and fix what you find”, and it works through them one by one.

1. Development with an agent in the browser

This is only active when a browser-driving agent is detected in debug mode. Here's what actually lands in the console:

BlueScreen. On an uncaught exception, Tracy sends a markdown version into the console alongside the standard red screen: the exception, stack trace, variable values, dump of $_GET / $_POST / $_COOKIE. It works for synchronous rendering and for AJAX errors.

Tracy Bar. The debug bar in the corner of the screen sends a markdown summary of selected panels into the console. The SQL panel with the number of queries and their times, the Errors panel with warnings, the Dumps panel with plain text dumps captured by bdump().

Dumps. When you call dump($var) in your code, a plain text variant gets sent to the console alongside the regular HTML output. Dumps no longer end up buried in the HTML page.

But watch out: an agent doesn't know on its own that it should be looking in the console. It will browse the rendered HTML, try to parse the colorful BlueScreen and guess what actually happened. That's what the tracy-debugging skill is for, a guide written directly for the agent. It tells the agent: after every request, call list_console_messages(), that's where you'll find Tracy Bar and BlueScreen in markdown, this is how the SQL panel looks, this is the stack trace, this is how to read dumps. The skill is part of the official Nette plugin for Claude Code.

2. Batch fixing of production errors

Whenever Tracy logs an exception into a log/exception-*.html file, it simultaneously writes a .md sibling next to it with the same content in markdown.

For a human peeking into the directory, nothing changes; the .md just sits next to the .html and you pick which one you want to open. It only starts making sense when you hand the directory's contents to an agent.

It's worth writing your own skill for this, telling the agent how to proceed: compare each exception with the current code (the bug may already be fixed), group related reports, and present a fix plan for approval before applying it. Instead of hundreds of HTML files to plow through by hand, you turn a folder of error reports into input for a single batch action.

For custom panel authors: getAgentInfo()

If you have your own IBarPanel, say a database panel or a profiler, and you want to send the agent a markdown version of its content, add a getAgentInfo(): ?string method to the panel class:

class MyDatabasePanel implements Tracy\IBarPanel
{
	public function getTab(): string { /* ... */ }
	public function getPanel(): string { /* ... */ }

	public function getAgentInfo(): ?string
	{
		return "## Database\n\n- Queries: {$this->count}\n- Total time: {$this->time} ms\n";
	}
}

Tracy puts the returned markdown into the Tracy Bar output for the agent. When the method is missing or returns null, the panel is skipped in the markdown output.

How the agent is detected

Let's peek under the hood. The key to detection is the JavaScript property navigator.webdriver. Both Chrome and Firefox set it to true whenever the browser runs under automation: WebDriver, Chrome DevTools Protocol, Playwright, Puppeteer. In practice this covers common browser MCP servers, such as Chrome DevTools MCP by Google, Playwright MCP by Microsoft, mcp-chrome, servers built on top of Puppeteer, or Browser Use. So just spin up any of them in Claude Code and Tracy 2.12 will recognize it on its own.

Mechanically it works like this: Tracy Bar's JavaScript reads navigator.webdriver and, if it's true, sets the cookie tracy-webdriver=1. PHP then checks this cookie before sending the markdown output. If you want to see the markdown output from a regular browser, say when debugging your own integration, just set the cookie manually in devtools.

Give it a try

Tracy learned a new dialect, and we'll keep pushing in this direction. The future of development belongs to agents that both write and fix applications, and we're looking for the best way to talk to them. Markdown in the console, .md siblings in the log, getAgentInfo() on panels: that's the first round. Time will tell what works, where it gets stuck, which way to head next.

Install Tracy 2.12 via composer require tracy/tracy:^2.12 and give it a spin, especially those of you running Claude Code with Chrome MCP, or Playwright/Puppeteer with agents. Feedback most welcome.