# Workflows > The 16 built-in AI CodeOps workflows and their steps, plus how to start one, schedule it, re-run it, cancel it, and build on a finished session with follow-ups. Source: https://aicodeops.dev/docs/workflows · Last updated: 2026-10-18 A workflow is the recipe a session follows: a fixed list of steps, each run by one [agent](https://aicodeops.dev/docs/agents). You pick the workflow when you start a [session](https://aicodeops.dev/docs/sessions). Whichever you pick, a session that writes code ends the same way: your tests run, the AI review records findings, and a person approves before a pull request opens. ## The built-in workflows Browse them under **Develop → Workflows**, in the **Workflow Catalog**. ### Building and changing code | Workflow | Steps (agent) | | ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Plan, Build, Review & Test** (default) | Plan (Architect) → Build (Builder) → Review (Reviewer) → Test (Tester) | | **Quality-Gated Change** | Build (Builder) → Test (Tester) → Review (Reviewer) | | **Security-Sensitive Change** | Scope change (Architect) → Risk analysis (Security Auditor) → Implement (Builder) → Audit diff (Security Auditor) → Validate (Tester) | | **UI Implementation** | UI plan (UI Designer) → Implement (Builder) → Code review (Reviewer) → Behavior test (Tester) | | **DevOps Change** | DevOps plan (DevOps Engineer) → Risk review (Security Auditor) → Apply (DevOps Engineer) → Validate (Tester) | | **Feature SDLC** | Requirements (Product Analyst) → Delivery plan (Project Planner) → Technical design (Architect) → Backend → Frontend → E2E tests → Security review → User docs (Technical Writer) | ### Review and readiness | Workflow | Steps (agent) | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | **Parallel Review** | Correctness review (Reviewer) → Security review (Security Auditor) → Test coverage review (Tester) → Merge findings (Architect) | | **Swarm Inspection** | Reviewer slice → Security slice → Tester slice → Merge summary (Architect) | | **Release Readiness** | Correctness review → Security review → E2E sanity → Dependency audit → Go / no-go (Architect) | ### Discovery and design | Workflow | Steps (agent) | | ----------------------- | -------------------------------------------------------------------------------------------- | | **Architecture Debate** | Architect A → Architect B → Critic review (Reviewer) → Final synthesis (Architect) | | **Discovery & Spec** | Prior art (Researcher) → Requirements (Product Analyst) → Delivery plan (Project Planner) | | **Threat Model** | Scope & data-flow (Architect) → STRIDE analysis (Security Auditor) → Record ADR (ADR Writer) | These three save their decision as a proposed architecture decision record under **Plan → ADRs**. ### Operations and maintenance | Workflow | Steps (agent) | | ---------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | **Incident Response** | Triage (Incident Responder) → Root cause (Architect) → Mitigation (Builder) → Verify (Tester) → Postmortem (Site Reliability) | | **Dependency Refresh** | Audit (Dependency Auditor) → Upgrade (Migration Specialist) → Test (Tester) → Verify secure (Security Auditor) | | **Performance Tuning** | Profile (Performance Tester) → Optimization plan (Architect) → Apply (Builder) → Re-measure (Performance Tester) | | **Data Migration** | Schema (Database Engineer) → Migration (Migration Specialist) → Validate (Tester) → Security → Final review (Reviewer) | Steps always run one after another, and each step sees what the earlier steps wrote. The catalog's **Parallel**, **Debate** and **Swarm** labels describe how the steps divide the work, not that they run at the same time. A step whose name contains "plan" also adds its items to the **Plan board**. ## Start a workflow You can start one from several places: - **Develop → AI Sessions → New session.** Pick any workflow in the **Workflow** list. The default is **Plan, Build, Review & Test**. - **Develop → Workflows.** Choose **Launch** on a workflow, describe the task, pick a **Project**, and choose **Start session**. - **A project's page.** **Run workflow** starts the default workflow on that project. - **Fix with AI**, on an incident, the **Quality** page or the **Security** page, and **Fix** on a finding. These start the default workflow on the problem. - **A schedule** (below). Every workflow run needs a project. Your workspace policy can require approval to start a workflow, or deny it. See [Approvals and policies](https://aicodeops.dev/docs/approvals-and-policies). ## Schedule a workflow Open **Release → Schedules** and choose **New schedule**. 1. Enter a **Name**, pick a **Workflow** and a **Project**. 2. Enter a 5-field **Cron expression** and a **Timezone**. Choose **Preview next 5** to check the times. 3. Optionally describe the **Task**. Without one, the session runs "Run the scheduled workflow" with the schedule's name. 4. Choose what happens if a scheduled tick is missed: catch up once, skip missed, or exact. 5. Choose **Create schedule**. Each schedule row has **Run now**, **History**, **Edit**, **Clone**, **Disable** and **Delete**. Deleted schedules can be restored from **Recently deleted**. ## Cancel a session On a running session's page, choose **Cancel session**. Enter a reason, then confirm **Cancel session**. The session stops within a few seconds, including any model call in flight, and its change is marked abandoned. You need a role that can manage sessions; viewers can't cancel. ## Re-run a session On a finished session's page, choose **Re-run** and confirm. It starts a new session with the same task, workflow, project and model. The new session isn't linked to the original. If the original workflow can't be launched any more, the re-run uses the default workflow and the dialog says so. ## Follow up on a session A follow-up builds on an earlier session instead of starting over. 1. On the session page, write in the **Follow-up prompt** box, for example "Also handle the empty-input case." 2. Pick the workflow for the follow-up. It defaults to the same one. 3. Choose **Send follow-up**. The follow-up is a new session, linked to its parent: its page shows **Parent session** under Linkage. It uses the parent's project and model, and gets the parent's task and summary as context. If the parent's change hasn't been merged yet, the follow-up starts from it, so the new diff contains both. While a session is still running, the same box says **Mid-session handoff / follow-up** and the button **Spawn handoff**. It starts a new linked session. The running session carries on. Choosing a step in the session's step strip starts the new session from that step. ## Next steps - [Multi-agent reviews](https://aicodeops.dev/docs/multi-agent-reviews) - [Quality gates](https://aicodeops.dev/docs/quality-gates) - [All agents](https://aicodeops.dev/agents) ## Frequently asked questions ### Can I build my own workflow? Not yet. Every session runs one of the 16 built-in workflows, each with a fixed list of steps. ### Do the steps of Parallel Review run at the same time? No. Every workflow runs its steps one after another. Parallel, debate and swarm describe how the steps divide the work, not timing. ### Is Re-run the same as a follow-up? No. Re-run starts the same task again from scratch, with no link to the original. A follow-up builds on the earlier session and is linked to it.