Launching today
Notate
Annotate anything for humans and their agents
68 followers
Annotate anything for humans and their agents
68 followers
Notate is for anything where pointing beats describing: design and motion review, product walkthroughs, code review, and handoffs. Unlike screenshot tools, it freezes open menus, hover and focus states before they disappear, or records a flow so you can pin the exact frame where an animation breaks. Gesture-based annotation keeps the flow fast; smart crop and reopenable sessions preserve the image, comments, and context so feedback stays useful when it reaches a teammate or an agent.
Notate
The capture half is solved here in a way I haven't seen elsewhere, so my question is about the other end of the loop. I annotate the frame where the easing breaks, the agent changes the code — and now I have to get back to that exact state to see whether it's fixed. Same hover, same interruption point in the animation, same window size. That reproduction step is manual, and it's the reason I stopped filing my own visual bugs properly: the before was cheap, the after was a chore, so I'd eyeball it and move on.
Does a .notate session carry enough to make the re-capture repeatable — app, window geometry, frame timestamp — so a second capture is comparable to the first frame by frame? A diffable before/after pair is what would turn this from a feedback tool into a regression check, and the typed manifest you described to Anand sounds like it's already most of the way there.
Notate
@narek_keshishyan You've reframed the product and I spent the afternoon designing against it, so here's the honest version. Today's archive carries part of what you'd need: canvas size, every frame's timestamp, duplicate markers, normalized annotations — so two same-rate recordings are already alignable in time. What it doesn't yet pin is the environment (app, window geometry, display scale, capture rate). Those are cheap, additive fields, and they're now first on the roadmap this question produced.
Where I landed after sitting with it: there are three primitives. The trace — each session becomes one truthful timeline: environment plus stimulus (cursor path, clicks, scroll — recorded as data alongside the frames, never keystroke contents), which agents can query ("where was the cursor at this frame?") and humans can watch as a cursor overlay in playback. The diff — two traces aligned on motion start rather than record-press (nobody triggers an animation at the same instant twice; the first changed frame is the honest zero), compared with the same perceptual-signature math the dedupe engine already runs. And a CLI, so the agent that made the fix can record and diff its own verification pass instead of only reading exports.
One limit I'm keeping on purpose: no replay guarantees. Your fix invalidates the recording by design — replaying old clicks against a moved button clicks the wrong thing — so Notate will never pretend to reproduce app state. It records what happened, verifies the second capture matches the first's geometry and rate, and tells you exactly which frames diverge. Getting the app back to the moment stays with you or your agent — but with the trace in hand, that's following instructions rather than remembering. And your bar is the one I'm building to: not CI-grade, just decisively cheaper than eyeballing.
Freezing transient UI states is the part that has always been missing. Regular screenshots lose hover states and animation frames at exactly the moment you need to point at them. The agent-readiness angle is the interesting differentiator here. How does Notate structure annotation metadata for agents? Is there a typed schema alongside the visual, or does the agent infer context from comments and pin positions?
Notate
@anand_thakkar1 Both, roughly — with the typed half about to get more visible. Today the export is a markdown manifest (frontmatter with the app and window, numbered comments, per-frame comments and timestamps for recordings) paired with the images, where the pins and arrows are drawn in with their numbers — so a multimodal agent grounds each comment by reading the number off the pixels rather than inferring position.
Underneath, every session is also a .notate archive with a fully typed manifest: shape kinds and normalized coordinates for every annotation. Surfacing that schema in the agent-facing export (coordinates alongside each numbered comment) is next on my list — it makes the export just as useful to agents without vision, and lets multimodal ones verify instead of guess.
Notate
@anand_thakkar1 Update: shipped in v0.1.10. There's now an Output Detail setting on the export — Standard adds a typed block to the frontmatter with each annotation's kind and normalized coordinates (a pin's point, an arrow's tip), and Detailed adds endpoints and bounding boxes. Coordinates are normalized to the exported image, so they stay correct even when the smart crop trims to a window, and recording manifests tag every entry with its frame.
"For humans and their agents" is the phrase doing the most work here. A human annotation is fundamentally positional — this thing, right here — and an agent has no pixels to point at, so the same note has to arrive as something structural instead.
What does the agent actually receive? Just the note text, or the note plus enough surrounding context to know what it was attached to? I'd guess "make this button smaller" is close to useless without the second part, and that's the piece that seems genuinely hard to get right.
Notate
@ark_y_k Today the note arrives with three layers. The images carry the pointer itself — pins and arrows drawn in and numbered, so a multimodal agent grounds "make this button smaller" the way a human does: by looking at what pin 2 sits on. As of v0.1.10, an Output Detail setting adds a typed layer to the frontmatter — each note's kind and normalized coordinates, arrow tips, bounding boxes — alongside the app and window it already names, with the export cropped to the focal window.
The layer you're describing — resolving the note to a UI element as structured data — is deliberately not Notate's job. Whatever consumes the export already holds better context than Notate could bake in: a coding agent has the source and finds the component itself, an automation agent has the live accessibility tree at action time, a human has the picture. Notate's job is to say where and what you meant, faithfully — your agent already knows, or can find, everything else. That's also what keeps the format small and stable: it has no opinions about what the pixels mean.
Freezing hover states and pinning feedback to the exact frame solves a real gap in UI review. Can a teammate reopen a shared session and add or resolve annotations without needing the original capture environment?
Notate
@adityaharish2002 Yes! Just share the .notate file — it carries every frame and comment, and double-clicking it opens the full editor on their Mac. Nothing is needed from the original capture environment, not even the Screen Recording permission (that's only for capturing). Your teammate can add, edit, or delete annotations and send the file back — full sessions survive the round trip. There's no resolve workflow yet (today you resolve by editing or deleting a pin) — proper collaboration features are what I'm building next.
Shared annotations for humans and agents could provide valuable execution context. How does Notate keep annotations attached when the underlying webpage, design, or code changes substantially?
the 'no replay guarantees, I will never pretend to reproduce app state' line further up is a rare kind of honesty for a launch post, most tools would just quietly overclaim there. practical question on the recording side - a long capture with per-frame data plus the pixel history for the perceptual diff sounds like it could get heavy fast. is there a size ceiling or compression pass on longer sessions, or does a 10 minute recording just produce a genuinely large .notate file you're expected to live with