Get started

What did your agent actually do?

DidWork verifies agent work before you trust it, build on it, or let the next step begin.

Get started View docs
Coding agents Multi-agent workflows Retries and repair Deployment Agent-powered products
CODING AGENTS

Stop manually checking every “done”

Claude Code, Cursor, and other coding agents accomplish a surprising amount of work. They can also confidently stop one step short. Run DidWork after an agent finishes a task to verify the requested outcome actually exists.

  • Every requested file was changed
  • Tests actually pass and the build succeeds
  • The bug can no longer be reproduced
  • The implementation matches the requirement
  • Related functionality still works

You ask

Add password reset, and make sure the user is returned to login afterward.

The agent writes the code and says it’s finished. DidWork checks whether:

  • The reset route exists and the token works
  • Invalid tokens fail correctly
  • The password actually changes
  • The session behaves correctly
  • The user reaches the expected screen
  • Relevant tests pass

The question isn’t whether code was written. Did password reset actually work?

MULTI-AGENT WORKFLOWS

Don’t let agents blindly trust other agents

Agentic systems increasingly divide work among specialists. One writes code. Another tests it. Another deploys it. Another reports the result. Without a verification layer, every handoff depends on the previous agent correctly evaluating itself.

The next agent begins because the previous outcome was verified — not because another model said it was ready.

Implementation agent did.verify() Testing agent did.verify() Deployment agent
AUTOMATED RETRIES AND REPAIR

Tell the agent what’s actually missing

A failed agent task shouldn’t always mean restarting everything. DidWork identifies which success conditions went unmet and passes that back into the workflow.

Tighter feedback loops, and agents that converge on completion instead of re-attempting the whole task.

Agent attempts task DidWork verifies Requirement failed Agent repairs missing work DidWork verifies again
DEPLOYMENT VERIFICATION

“Deployed” doesn’t mean “working”

CI finished. The container started. The hosting provider returned success. None of those prove the application behaves correctly. Verify production state before the workflow declares the deployment complete.

  • The endpoint responds correctly
  • The expected version is live
  • Environment configuration is correct
  • The database migration completed
  • A critical user flow still succeeds

After the deploy reports success

const live = await did.verify({
  type: "github.commit_in_branch",
  expected: { sha, branch: "main" }
});

const serving = await did.verify({
  type: "http.ok",
  expected: { url, status: 200 }
});

// neither VERIFIED? the deploy isn't done
AGENT-POWERED PRODUCTS

Give your users more reliable automation

If you’re building agents into your own product, your users inherit the same trust problem you have with coding agents. They need to know whether the agent actually accomplished the task.

Verify before you charge a customer, send a message, publish content, change production data, trigger another agent, or report success to the user.

Your agent can act. DidWork decides whether the workflow should trust the result.

In your own workflow

const result = await agent.run(task);

const verification = await did.verify({
  task,
  result,
  requires: successCriteria
});

if (verification.passed) {
  continueWorkflow();
}

More places verification pays off

The same claim → evidence → verdict loop, pointed at the rest of the stack.

Pull request verification

Code review tells you what changed; DidWork tells you whether the change accomplished the task. Run it against agent-generated PRs before they reach a developer, CI, or production.

  • Missing requirements and incomplete refactors
  • Broken integrations and unhandled edge cases
  • Assumptions the agent never validated

Browser and UI verification

An agent can change frontend code successfully and still produce the wrong experience. Verify what the user actually sees.

  • The required element appears and renders expected content
  • Buttons, forms, and redirects do the right thing
  • Error and authenticated states behave

API and integration verification

A configuration update can execute successfully while the integration stays broken. Verify across the boundary, not up to it.

  • The webhook arrived and the record was created
  • The external system reflects the update
  • The downstream action actually occurred

Data and migration workflows

Database changes are exactly where agent confidence shouldn’t decide whether a workflow moves forward. Put a gate between the operation and the next consequential action.

  • The migration completed and the schema exists
  • Row counts and constraints hold
  • Rollback conditions remain available

Agent evaluation

Once tasks have explicit success conditions, you can measure completed work instead of confident answers — completion rate, verification failures, retries, and where models tend to fail.

Which agent actually got the job done?

Human-in-the-loop systems

Human review is valuable. Human review of every routine agent action isn’t. Clear verifiable work automatically and escalate only when it matters.

  • Evidence is inconclusive
  • Verification fails repeatedly
  • The task needs subjective judgment
  • A high-risk threshold is crossed