# Alchemist Tickets: Autonomous Development

How the Alchemist platform plans a ticket as a workflow graph, executes it node by node, and how to read status, cancel, and retry.

---

The Alchemist platform at build.chipp.ai is an autonomous development system. You describe what you want as a **ticket**; a team of AI agents plans the work, writes the code in an isolated sandbox against your project's real repository, reviews and security-checks it, verifies it against your acceptance criteria, merges it, and deploys it to your live app. You watch the whole thing happen live and stay in control of budget and approvals.

> **Note:** "Alchemist" names two related things. This guide covers the **Alchemist platform**: the ticket-driven autonomous development system. The **Alchemist copilot** is the chat assistant inside the Chipp app builder; see [The Alchemist Copilot](/docs/guides/alchemist).

## Dispatching a ticket

A ticket is a title plus a description of what you want: a feature, a fix, a refactor, or an investigation. The better the description states the goal and how you would judge it done, the better the result. You can dispatch one:

- **From the dashboard** at build.chipp.ai, on your project's Tickets page.
- **From a connected Chipp agent**: any Chipp app connected to your Alchemist workspace can dispatch tickets mid-conversation, so "file a ticket to fix that" works from chat.
- **Programmatically over MCP**: the platform exposes `dispatch_ticket`, `list_tickets`, `get_ticket`, and related tools to any MCP client authenticated with your tenant API key. See the [Alchemist Cloud Tickets MCP](/docs/guides/alchemist-mcp-server) guide for connection instructions.

Tickets get a reference like `PROJ-42` and show up immediately in the Tickets list.

## A ticket is a workflow graph, not a fixed pipeline

Every ticket runs as its own **graph of nodes**: a small, dispatch-time-planned DAG (directed acyclic graph), not a fixed sequence of stages that every ticket marches through identically. When you dispatch a ticket, a planning step reads the ticket and your codebase and proposes a graph shaped for that specific piece of work: a one-line copy fix might plan a short chain of research, implement, and review; a larger feature might plan multiple implementation nodes feeding independent review, security, and verification nodes before anything lands. The plan is checked for safety before it runs (for example, any node that writes to your repository always has an independent review path downstream, and a graph that changes code always ends in a landing node) and, on the rare case planning itself fails, the platform falls back to a safe default shape rather than leaving the ticket stuck.

This replaces an older, retired fixed-stage pipeline design. If older material described a different, rigid sequence of stages, it no longer reflects how tickets execute.

## Node kinds, in builder terms

The ticket detail page draws the graph as boxes and arrows; each box is a **node** with a **kind** that tells you what it is doing:

- **Plan / contract**: the planning step itself, and a step that pins down a concrete, testable definition of "done" before any code is written.
- **Research / investigation**: read-only exploration of your codebase, logs, or database. Nothing changes here; it is how agents ground the plan in how your app actually works today.
- **Implement**: writes code in an isolated sandbox on a dedicated git branch for the ticket, committing checkpoints as it goes.
- **Docs / integration**: variants of implementation work scoped to documentation changes or to wiring pieces together across a larger change.
- **Review / security / verification / QA authoring**: independent nodes that read the diff (not write it): a correctness review, an adversarial security check, and a check that the contract's testable assertions actually hold, including runtime checks against a running instance of your app where relevant.
- **Reconcile**: a node that resolves conflicting or partial results from earlier nodes before the graph proceeds.
- **Merge repair**: only appears if landing hits a conflict; it repairs the branch so the merge can complete instead of leaving the ticket stuck.
- **Land**: merges the finished branch into your project's base branch (`staging` on most projects). This step runs on the platform's own infrastructure, not inside an agent's sandbox.
- **Deploy verify**: a follow-up check the platform appends automatically after a land triggers a deploy, confirming the deploy actually succeeded before the ticket is marked done.

Not every ticket's graph uses every kind above. A read-only "investigate" ticket, for example, plans only research nodes and never touches your repository.

## Reading the graph

The ticket detail page shows the live graph, a session audit of every agent turn, per-node reports, and running cost against the ticket's budget. Each node carries a status as it executes:

- **queued**: waiting for its turn (either it has unmet dependencies, or a worker has not picked it up yet).
- **running**: actively executing.
- **awaiting input**: paused on a question for you. See [Answering Agent Questions](/docs/guides/alchemist-awaiting-input) for what these look like and how to reply.
- **succeeded** / **failed** / **skipped** / **cancelled**: terminal states; nothing more happens to that node.
- **blocked**: waiting on another node (or another ticket, if this ticket declared a dependency) that has not finished yet.

Click any node to open its detail drawer: the model it ran on, its duration, its cost, and its report.

### Stalled or failed nodes

A node that sits in **queued** far longer than its neighbors is usually just waiting for fleet capacity, not stuck; the page keeps polling and will move it to running on its own. A node in **failed** status has a report attached explaining what went wrong, visible in its detail drawer; it stops that branch of the graph, and any downstream node depending on it shows as blocked until you act. There is no per-node retry button: the fix is to retry the whole ticket (see below), which resumes from the last good checkpoint rather than restarting the entire graph from scratch.

## Landing and deploying

When a graph's work is verified, its land node merges the ticket's branch into your project's base branch. Base-branch changes (yours and every other in-flight ticket's) are serialized through a merge lease, so two tickets landing at once cannot race each other or silently drop one of them. Landing triggers a deploy through your project's normal pipeline exactly the way pushing to the branch yourself would; the deploy appears in your project's Deployments view, and a `deploy_verify` node confirms the outcome before the ticket is marked done.

If the deploy itself fails (a build error or a rollout crash, as opposed to the ticket's own work), that is a deploy problem, not a ticket problem: the platform automatically retries a deploy that looks transient up to a capped number of attempts, and the ticket page also offers a self-serve "Retry deployment" action on a failed deploy so you do not have to leave the ticket to re-trigger it.

## Cancel semantics

You can cancel a ticket from the ticket page, or over MCP (`cancel_ticket`), whenever it is queued, running, blocked, blocked on credits, awaiting input, or awaiting a deploy to finish. Cancelling stops further work: no new nodes start, and a running node is torn down. It does not undo anything: whatever has already landed is a normal git commit on your base branch, inspectable and revertable like any commit, and any deploy already in flight from a prior land proceeds independently under the platform's own rollout monitoring. A cancelled ticket can be retried later.

## Retry semantics

Retrying a ticket (from the ticket page, or the equivalent MCP action) defaults to **resuming in place**: the platform checks for durable checkpoint state (a pushed commit on the ticket's agent branch, a graph node that already succeeded, or general progress past planning) and, when it finds one, continues the same ticket from there instead of throwing away that work. This is why most retries are cheap and fast.

If the plan itself was the problem, "Start fresh" is an explicit, separate action: it discards any committed work on that ticket and creates a brand-new, re-planned ticket instead. Use it when the underlying approach needs to change, not just an individual step.

Deploy-level retries are a separate concept from ticket retries, see "Landing and deploying" above: they only re-run a failed build or rollout for a commit that already landed, and never re-open or re-plan the ticket that produced it.

## Budgets and approvals

Every ticket runs under a budget. If a plan cannot fit its budget, the ticket does not silently fail or silently overspend: it parks and asks you to approve the higher amount, and only proceeds once you do. Rejecting closes the ticket with the decision recorded. For how cost estimates are produced, how per-ticket and per-project spend is tracked, and how to query costs over MCP, see [Alchemist Budgets and Costs](/docs/guides/alchemist-budgets-and-costs).

Your project can also receive ticket proposals from other projects' agents via cross-project proposal links. Proposals land in the same Approvals lane and require the same explicit decision before any work starts. See [Cross-Project Proposals](/docs/guides/alchemist-cross-project-proposals) for how to file proposals to other projects (including the built-in Chipp platform support channel) and how decisions and outcomes are reported back to the proposing side.

Some tickets need to change something in your live database rather than your code. These are called **data operations**, and they always require an explicit approval on the exact SQL or script text before anything touches your database. For the full lifecycle (propose, approval card, dry-run vs execute mode, reading run output, retry/decline semantics), see [Data and Script Operations](/docs/guides/alchemist-data-operations).

## Reviewing the work

- **Work Review** collects completed tickets' diffs and reports for you to inspect. See [Alchemist Work Review](/docs/guides/alchemist-work-review) for what it shows and your options when a result is not what you wanted.
- Per-node reports and the full agent-turn audit trail are covered in [Alchemist Reports and Audit](/docs/guides/alchemist-reports-and-audit).
- Failed or blocked tickets say why, with the failing node's report attached, and can be retried (see "Retry semantics" above).

## When you'd rather do it by hand

Some changes are easier to just make yourself. Your project's repository is yours: clone it, edit in Claude Code or Cursor, and push. Pushes deploy through the same pipeline as agent merges and are coordinated with in-flight agent work. See [Alchemist: Clone Your App's Code and Develop Locally](/docs/guides/alchemist-local-development), which also covers debugging your deployed app (logs and read-only database queries) straight from your editor.

## FAQ

**Do agents and my own pushes conflict?** No. Base-branch changes are serialized through a merge lease, and deployments are deduplicated by commit, so the same change never ships twice and nothing races.

**Can a ticket depend on another ticket?** Yes. Tickets can declare dependencies and larger scopes fan out into multiple coordinated tickets; see [Alchemist Ticket Dependencies](/docs/guides/alchemist-ticket-dependencies) for how `depends_on` and blocking work.

**What does a ticket cost?** Cost is metered per ticket from actual model and sandbox usage and shown live on the ticket detail page, with the budget ceiling alongside it. See [Alchemist Budgets and Costs](/docs/guides/alchemist-budgets-and-costs) for the full picture.

**What if a ticket goes wrong?** Cancel it any time from the ticket page or over MCP (`cancel_ticket`); see "Cancel semantics" above for exactly what stops and what stays. Nothing lands on your app until the land step completes, and everything that does land is a git commit you can inspect or revert.

## Next steps

New to Alchemist? Start with [Getting Started](/docs/guides/alchemist-getting-started), then come back here. From this guide, the natural path is [Budgets and Costs](/docs/guides/alchemist-budgets-and-costs) → [Ticket Dependencies](/docs/guides/alchemist-ticket-dependencies) → [Work Review](/docs/guides/alchemist-work-review).