[madikz]

Founder building document-automation tools for tax firms here — the hardest part is definitely the verification step. For us it's not whether the agent can navigate a UI, but whether the output it produced (a reconciliation report, a tax form) is actually correct when every screen says "success."

We ended up building a secondary rule-based checker that runs independently over the agent's output — it catches things like missing schedules, transposed account numbers, and date mismatches with prior-year filings. The agents handle the execution path, the rules handle the truth.

Curious how you're thinking about this for workflows where a wrong but "successful" action has real downstream cost — do you rely on human review, or do you have a layered verification approach built-in?

[nkov47]

That’s exactly the failure mode we’re most worried about. A UI saying “success” is weak evidence that the underlying work is correct.

We’re using a layered approach rather than relying on the computer-use model alone. The execution agent handles navigation, but workflows can also define independent checks against source data and expected invariants,for example, matching patient IDs, totals, dates, procedure codes, or confirming that a record actually changed in the destination system. For higher-risk actions, we can pause before submission or route the completed output to human review.

We’re also trying to keep verification logically separate from execution where possible, so the same agent isn’t simply grading its own work. In some workflows that means deterministic rules; in others it may mean rereading the destination, comparing against the original document, or using a separate model/checker.

Your point about the rules handling truth is a useful way to frame it. I’d be curious how much of your checker is reusable across tax firms versus custom to each firm’s process.