Iris

Tests start as sentences, not scripts. You type the scenario, name the page and Iris parses the instructions into an executable flow. A preview step shows how the agent read your words before anything runs, so you catch a misread early. For teams without a trained automation engineer, this is the feature that decides whether tests get written at all.

Each agent sees the page and reads its text at the same time, the way a person does. That mix is why Iris claims it handles dynamically loaded content, UI states, network responses and live updates without special scripting. When a site changes, recursive learning lets the agent adjust instead of failing outright, which is the core of the self-healing promise.

Work lives in projects, and each project holds a set of tests you can run one at a time or all at once. A test bundles its instructions, validation rules, success criteria and its own agent configuration. Every execution is stored as a test run with steps, timing, screenshots and a recording, so a failure comes with evidence rather than a stack trace alone.

You can seed cookies, localStorage and sessionStorage from project settings, which lets the agent reach screens that sit behind a login. That matters because most of a real app hides behind authentication, and tests that only touch public pages miss the flows that actually break in production.

Iris connects to GitHub for pull request triggers, issue creation and check results, and to Slack and Discord for real-time notifications and failure alerts. It also lists GitHub Actions, CircleCI, Jenkins and GitLab CI among the pipelines it plugs into. The intent is that a test runs on every change and lands in the tool where the team already works.

The platform exposes a tRPC API with token authentication, covering tests, agents, projects and organizations, and it supports batching and filtered queries. Iris documents how its control plane and distributed agent network fit together, and the code sits in a public GitHub organization. There is no TypeScript SDK yet, and the team says one is coming.

A finished run produces a report with the steps taken, the point of failure, a video recording and the context needed to reproduce the issue. Reports can be shared by email and compared against earlier runs. For a team triaging a bug, the recording usually answers the question faster than a written log.