# How Iterada works

> The few ideas everything in Iterada builds on: projects, sessions, branches, agents, checks, merges, deployments and memory.

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](https://iterada.com/docs/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](https://iterada.com/docs/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](https://iterada.com/docs/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](https://iterada.com/docs/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](https://iterada.com/docs/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](https://iterada.com/docs/overnight).