How Iterada works

Iterada sits between you and the coding agents. You say what the product should do; Iterada gives each request a safe place to happen, checks the result and carries it to production the way you decided.

Project#

One product, one repository. A project holds its sessions, its agents, its delivery settings and its memory. Switch between projects from the letters in the left rail.

Session#

A conversation about one piece of work. Each session has its own private copy of the repository and its own branch, so two sessions never edit the same files under each other. A session can last one message or many: keep asking for adjustments until the change is right. You can run sessions from your phone as well as a computer: the console works in a phone's browser, and the agent keeps working after you put the phone away.

Turn#

One message from you and everything the agent does to answer it: reading the code, editing files, running checks and replying. A turn keeps running on Iterada's servers when you close the tab, and resumes by itself after a rate limit or an outage.

Agents#

The coding agents you already use - Claude Code, Codex, Cursor, Pi and opencode. Claude Code and Codex run on your own subscription, Cursor on its API key, Pi and opencode on provider keys. A project lists them in order: the first takes every turn, and when it cannot carry on - its plan ran out, its sign-in stopped working or its provider is down - the next one picks the same work up on the same branch. See Agents.

Workflow#

The steps a request goes through, drawn in Agent factory under Workflow: the change, Iterada's checks, an optional review and a merge. The separate On merge workflow controls deployment. You decide which steps a project has, and with them how it merges and deploys. See Merge and review.

Checks#

Your repository's own tests, and the product tests Iterada runs against a real browser. The Iterada checks step in your workflow runs them on a change before it merges. See Set up delivery.

Merge#

How a finished change reaches your default branch: by itself once checks pass when your workflow has a Merge step, or when you press Merge when it does not. See Merge and review.

Deployment#

How the default branch reaches your users. You deploy from Production, or let the Regular branch of On merge in Agent factory deploy once no session is changing files. Its Hotfix branch deploys fixes from a failed deployment immediately. The version that is live keeps serving until the new one is healthy. See Production.

Memory#

What Iterada learns about your project from your conversations - decisions, preferences, constraints - so every agent starts from what was already agreed. When a new request contradicts something remembered, the agent asks you first which one stands. If what is remembered ends up with two versions of one fact, the session says so: press Show both versions and keep one, or reply “keep the new version” or “keep the previous version”.

Quiet hours#

The hours you do not use. If you switch it on, Iterada spends them on a run of tasks - testing the product through its real screens, improving the code, tidying how its agents work, and tasks of your own - fixes what it is sure of and leaves the rest for you under Artifacts. See Work in quiet hours.