Launch HN: Coasty (YC S26) – An API for computer-use agents

The checkpoint and invariant model is a strong fit for these workflows. Having approval gates plus a replayable event log makes the agent's decisions much easier to audit than a simple end-to-end task API.

What do you think that makes your solution "SOTA"? That's quite the interesting claim, which is obviously false.

we run screen-driven agents against web forms in production and the failure mode that took us longest to find wasn't navigation, it was commits that don't commit. a react controlled select can render the right value after a click while the framework's internal state never updated, so every pixel says done and the submitted payload says null. vision-only verification passes because the screen genuinely looks correct.

curious how you handle that class without DOM access. screenshot-after-action catches missing UI feedback, but when the UI itself is lying about form state the only reliable tells we found were downstream: the confirmation page, an outbound request, an email arriving. do your verification events ever consume anything besides pixels, or do you lean on the human approval gates for the risky commits?

Great observation on the "commits that don't commit" failure mode. We ran into the exact same class of bug building document extraction for regulated financial workflows — turns out vision-only verification has a blind spot that shows up whether you're parsing a screen or a PDF.

In tax preparation, documents have a lot of "the screen lies" equivalents: a PDF renderer can display perfectly aligned columns while the underlying text layer has misaligned fields. We learned this the hard way when an OCR pipeline extracted "123 Main St" beautifully from a W-2 image, but the XML metadata had a completely different address. The screen looked right, the data was wrong.

Our approach was a second verification layer structurally independent from extraction: deterministic rules that reconcile AI output against the source document's known structure. For a W-2, that means cross-walking every box number against the IRS's published schema and flagging deviations — same principle as your "downstream tells" but formalized into a rules engine.

The key insight: in regulated domains, the verification layer must consume something structurally different from what extraction consumed. If both use the same pixel-based representation, they share the same failure modes. Using DOM state, API call logs, or document metadata schemas as the verification source catches the cases where "pixel says done, payload says null."

Defining explicit "verification invariants" (similar to Coasty's approach) has been the most practical defense — things like "total across all line items must equal reported total" or "taxpayer name must match across all documents in the return." Simple arithmetic checks that don't need AI but catch the expensive failure modes that vision alone misses.

Curious how Coasty handles multi-source reconciliation — e.g., when the data on screen needs to be verified against a separate document (like a PDF guidance doc) rather than just against itself?