I didn’t build DidWork because agents couldn’t do the work. I built it because they kept telling me they had.
Everything on this page happened before there was a product. DidWork is the control I needed for my own software, extracted after the workarounds stopped holding.
Ryan Gonzales — founder, DidWork
The agent decides when it’s done, and then reports on itself
I’d been leaning on Claude, Cursor, and a growing pile of agentic workflows to build and operate real software — inventory, commerce, pricing, fulfillment, customer data. Not demos. Systems with consequences attached.
And I wasn’t being careless about it. I had done the homework everyone tells you to do.
What I already had in place
- Detailed Cursor rules
- CLAUDE.md files at every level
- Written project documentation
- Explicit, specific instructions
- Tests and established patterns
- Increasingly sophisticated agent workflows
What still happened
- Claimed something was complete when it wasn’t
- Verified its own interpretation of the task
- Satisfied the letter of an instruction, missed the intent
- Made a change without checking what it broke downstream
- Decided a test was “good enough”
- Stopped at detecting a problem instead of resolving it
The problem was never intelligence. It was accountability.
Then the stakes got higher
Pulltrader is software for trading-card businesses. Agents increasingly help operate the workflows inside it: inventory, pricing, listings, fulfillment, and the handling of assets that belong to somebody else.
Sometimes those assets are worth $5,000. Sometimes $50,000.
When an agent is helping care for someone’s $50,000 card, “I think I did it correctly” is not a control system. That’s the moment a developer-convenience problem turns into an operational one, and Pulltrader became the place DidWork had to work before it was allowed to be a product.
DidWork was extracted from a problem we had to solve internally.
We already had rules
The reasonable objection is that this is what tests, rules, observability, and evals are for. I had all four. Here is what each of them actually does.
Rules
Tell an agent what it should do.
Tests
Tell software whether certain conditions are true.
Observability
Tells you what happened, after it happened.
Evals
Tell you how a system performed, in aggregate.
None of them puts an independent gate between an agent saying it completed an action and the system accepting that claim.
The agent that performed the work shouldn’t also be the one deciding whether the work is acceptable — especially since agents are optimized to complete the task. That creates a quiet incentive problem, and it shows up in the stopping condition.
“I have enough evidence to believe I succeeded.”
“The required evidence says I succeeded.”
And when it doesn’t? The workflow doesn’t just report the failure. The agent gets the result and has to resolve it.
Eventually I realized I was writing increasingly elaborate instructions trying to solve the wrong problem. I was trying to make the worker more trustworthy.
What I actually needed was a system that made trust unnecessary.
did.verify()
Verification becomes part of execution instead of something you hope happens afterward.
- You define success externally. The condition doesn’t come from the agent doing the work.
- The agent performs the work. However it wants to.
- DidWork checks the required evidence. From the system of record, not from the transcript.
- The gate fails → the agent keeps working. It gets the specific reason back and repairs it.
- The gate passes → the workflow proceeds. Not before.
The whole idea, in one call
const v = await did.verify({
type: "stripe.refund",
expected: { payment: pi,
amount: 4999 }
});
if (!v.passed) {
// v.reason: AMOUNT_MISMATCH
// observed: 3999 — go fix it
}
I was the first customer
DidWork didn’t start as a market category I went hunting for. It started as infrastructure for my own workflows, because I needed:
- Agents that could do more without constant supervision
- A way to trust long-running work
- Machine-verifiable completion criteria
- Durable logs of what actually happened
- Something that works across Cursor, Claude, MCP, my own code, and eventually production agents
DidWork isn’t about supervising agents more closely. It exists so you can safely supervise them less.
This isn’t my first software cycle
I’ve spent more than twenty years in product, design, and startups — Fortune 100 work at companies like Disney and FedEx, several early-stage companies, and ventures of my own. I’ve watched software move through desktop, web, mobile, cloud, SaaS, and now this.
This transition is materially different, because for the first time we’re delegating not just computation but judgment and action. That’s exactly what makes verification the thing worth building.
- 20+years building digital products
- 5×founder, 2 exits
- Nowfounder of Pulltrader, creator of DidWork
Agents are becoming coworkers. Our systems haven’t caught up.
For decades, software assumed a human pushed the button. Now agents write code, change infrastructure, update customer records, make recommendations, trigger workflows, and help operate businesses. That assumption is gone, and the primitives built on top of it need replacing.
- Identity
- Permissions
- Context
- Verification
- Accountability
- Auditability
- Recovery
DidWork solves one specific piece of that stack, extremely well: before an agent gets credit for completing consequential work, prove that the work was actually done.