Company
Agents need a release check for what they do, not just what they say.
RigorRun is building pre-deployment verification for tool-using AI agents. Start with permission and customer-scope failures, read the system afterwards, and keep the agent’s claims separate from the evidence.
Founder-led by Erbol Tahirov. The published MIT runner is rigorrun@0.6.1. Current concrete examples are the multi-tenant Helpdesk twin and Stripe refunds; custom-system permission packs are not built yet.
The investment thesis
When an agent gets tools and credentials, a plausible reply is no longer enough to check the work. Prompt, model and integration changes need regression tests for customer boundaries, allowed actions and actual side effects.
The initial customer hypothesis is a CTO or AI/platform lead at a B2B SaaS team moving tool-using agents into customer workflows. The buying moment is a release, a security review or an incident that must not recur.
This is a product thesis, not a measured market-size or competitive-superiority claim. RigorRun complements runtime authorisation and monitoring; it does not replace them.
Open source for adoption. Workflow verification for revenue.
The runner stays MIT-licensed. The initial commercial offer is a paid, scoped pilot: make one real workflow testable, agree which defects it must catch, and hand off reproducible evidence and a release check.
A shared team workspace is planned as the recurring product: workflow management, run history and approvals. It is not built yet. Willingness to pay, repeat usage and pricing remain validation questions.
Next milestones, not traction claims
Validate one real workflow
Find a design partner with a known failure, readable system state and a safe test environment. Custom integrations are scoped work, not assumed compatibility.
Show repeated release use
Check whether the team reruns the suite after model, prompt and credential changes, and whether the evidence helps a real shipping decision.
Validate the recurring product
Only then test demand for managed workflows, shared history and approvals. These are planned milestones, not current revenue or customer results.
The technical starting point is public: the recorded Helpdesk run, the Stripe recording and the evidence with its limits. Historical release evidence does not qualify an altered engine build.
See the demo. Challenge the thesis.
For a hackathon, start with the recorded failure and its system evidence. For an engineering team or investor conversation, bring a workflow, a failure mode or a hard question.