AI agents move fast. Your software should keep up.

Test your SaaS for the AI agents your customers use, and find problems before they affect real customers.

An agent explores different paths through an application, following one of four routes at a time.

Your customers can put AI agents to work in your product.

An agent uses an application's existing interface to select two items, change a setting and complete an action.

Customers can delegate tasks in your product to AI agents through MCP, APIs, browser use or computer use, letting the agent decide how to carry them out.

An agent can act within its permissions and still get the task wrong. If your product accepts a mistaken action, it can lead to unintended changes to customer data.

Test how your product handles agent mistakes.

We’re building Lirris to find and reproduce failures caused by agent mistakes, so your team can fix them before they affect customers.

An illustrative test: an agent refunds the wrong customer. The application accepts the action, then Lirris identifies and highlights the unintended change.

Test your product across agents and scenarios.

Lirris generates scenarios and runs them with different agents and starting data, checking how your product responds. When it finds a failure, it saves the scenario so your team can investigate and check a fix.

Illustrative runs of the same application with different starting data. Agents take different actions, an unintended change is identified, and the saved scenario is run again.

Varied scenarios

Generated scenarios and autonomous exploration vary the tasks and starting data to find the conditions that cause problems.

Different agents

Lirris repeats tasks across agents to check how consistently your product handles their actions.

Saved failures

Saved scenarios and starting states give your team a way to investigate a failure and test a fix under the same conditions.

Run Lirris in your own environment.

We’re building the private beta around an open-source runner that runs locally. Your team controls where it runs and what it can access.

A local runner connects to an application and a data source within one environment. An access-control lock marks the boundary, illustrating your team’s control over which resources are available to a run.
Staging or sandbox
Testing starts in an environment your team chooses, using the accounts and data you make available.
Local credentials
The runner is designed to use credentials locally to connect to the systems being tested.
Access you control
Your team chooses which workflows and interfaces are available to each run.
Actions you can review
Recorded steps and resulting changes let your team see what happened during a run.

Get early access to Lirris.

We’re inviting SaaS teams to try Lirris in private beta. Leave your details and we’ll be in touch about access.

“People are handing more and more work to their agents. That’s why I’m building Lirris, to help prepare the internet for that future.”

JacquesFounder of Lirris