Your feedback should survive the handoff

Most product feedback is written for a reader who left the room.

Loom was built for a human to watch. Jira was built for a human to triage. A Slack thread was built for a human to skim. Every one of them assumes the last mile is a person. But in an AI-in-the-loop workflow, the last reader isn't a person anymore. It's a coding agent in Claude Code or Cursor. And an agent can't watch your Loom.

That's the whole problem, and once you see it you can't unsee it: your feedback is written for the wrong reader.

What agent-readable means

The format itself has three properties, and the definition page lays them out with a worked example: markdown structure, screenshots at stable URLs, and a source URL on every finding. This page is about why those three exist, and about the two more things that turn a document with the right format into something an agent actually finishes.

Feedback is agent-readable when the thing that fixes your product can act on it directly, with no human translating in between. That takes:

1. Structured, not narrated. Findings an agent can parse, not six minutes of video it can't watch.
2. Sourced. Every finding carries the exact route or URL it happened on, so the agent jumps straight to the screen instead of guessing.
3. Visual evidence, embedded. The annotated screenshot lives in the document, so "this button" is unambiguous.
4. Actionable. Each finding is a unit of work the agent picks up, not a mood it has to interpret.
5. Addressable. It lives at a URL the next session can open, not in a chat that has already scrolled away.

Miss any of these and the feedback stalls at the handoff. Hit all five and the loop closes: you notice the problem, the agent reads it, the agent ships the fix.

A report describes the work. A work object is the work.

The genre we're replacing is the report: the document that says "here's what's wrong" and then waits for someone to cross the gap between finding and fixing. Reports are why feedback dies in scrollback.

The replacement is a work object: a shareable artifact the agent picks up and executes. Not a description of the work but the work itself, in the format the next step consumes. That's what CobaltCapture produces. You capture the screen, you talk through it, and out comes structured markdown with the screenshots embedded and every finding sourced, at a public URL you hand to your agent. It reads it. It fixes it.

The same is true when the agent does the finding. A study it runs on your site lands in the same shape: screenshots, findings, sources, one link. The work object is the unit either way.

Loom is for humans. Cobalt is for the thing that fixes it.

This isn't a knock on video. Video is great for a human who has six minutes and wants to feel what you felt. But that's not the job anymore. The job is to get a fix shipped, and the one who ships it reads text and images, opens the same link next session, and needs the exact route, not vocal tone.

So the question that scores every feedback tool is simple: who reads this last? If the answer is your coding agent, then the format has to be built for it. Anything else is a Loom alternative waiting to happen: feedback that looked done but died on arrival.

Give your agent something it can actually read. That's the standard. Everything else is a report.

Frequently asked questions

Why does it matter who reads the feedback last?

Because the format has to fit the reader. Loom, Jira, and Slack were built for a person to read last, and a person can fill in gaps: watch the video, ask a question, click through to the page. A coding agent can't. It reads text and images, and it fixes only what the document lets it locate. Feedback written for a human last-reader stalls the moment an agent is the one doing the fixing.

Why can't an AI coding agent use a Loom video?

A coding agent reads text and images, not screen recordings. It can't watch six minutes of narration, it can't see what your cursor was pointing at, and the transcript drops the visual context entirely. The feedback has to arrive as structure the agent can parse, not motion it can't.

Isn't a Jira ticket already structured?

A ticket is structured for tracking, not for fixing. It describes the work and then waits for a human to go do it. Agent-readable feedback removes that gap: every finding links to the exact place in the product, so the agent picks it up and executes instead of re-interpreting.

How is this different from just pasting a screenshot into the chat?

A pasted screenshot dies in scrollback. It reaches only whoever is in that chat, it's gone by the next session, and it isn't annotated or sourced. Agent-readable feedback is an artifact at a URL, a work object the next agent opens by link instead of by scrolling back through a conversation.