Alchemist Ticket Dependencies

A single ticket runs as its own workflow graph (see Alchemist Tickets). Separately, you can also declare that one ticket depends on other tickets, so a larger scope of work fans out into several coordinated tickets instead of one giant one. This guide covers that ticket-to-ticket dependency layer.

Declaring a dependency

A ticket can list depends_on, one or more other tickets it needs to wait on. You can set this when dispatching a ticket over MCP (dispatch_ticket accepts depends_on as an array of ticket UUIDs or #N references); see the Alchemist Cloud Tickets MCP guide for the full tool reference.

Blocked-until-parents-succeed

A ticket with unmet dependencies is created directly in a blocked state and is not dispatched yet. It shows up in a dedicated Blocked section on your project’s Tickets list, informational, not an alert, so you can see at a glance what it is waiting on.

A blocked ticket is promoted to queued once every ticket it depends on has succeeded. For a parent that produced a code change, “succeeded” alone is not quite enough: the platform also confirms that parent’s commit has actually landed on your project’s base branch before releasing the dependent, so a dependent never starts working against code that technically finished but has not actually merged yet.

Auto-cancel on parent failure

If a parent ticket ends in a terminal failure (failed, cancelled, or timed out), its blocked dependents are automatically cancelled rather than left waiting forever on something that is never going to finish. This is informational, not something you need to clean up by hand.

If that parent is later retried and succeeds, the platform reconciles this automatically: a dependent that was auto-cancelled because of that parent gets a recovery pass and can resume once its dependencies are actually satisfied, rather than staying stuck cancelled.

You can also cancel a parent ticket yourself while it still has live, unfinished dependents. Doing so does not silently orphan them: the platform immediately surfaces the affected dependents so it is clear they are now blocked on a decision (repoint them at something else, or cancel them too) instead of quietly waiting on a parent that will never finish.

Dependencies vs. one bigger ticket

Use depends_on to split a scope into multiple tickets when:

• The pieces are large enough that you want independent visibility into each one’s status, cost, and review, rather than one long-running ticket that hides the breakdown.
• A later piece genuinely needs an earlier piece’s output first, for example a schema-evolution ticket that a feature ticket must wait on, so the dependency reflects a real ordering constraint, not just a to-do list.
• You want to be able to approve, retry, or cancel pieces independently, for example rejecting one piece’s approach without touching the others.

Prefer one bigger ticket when the work is small enough, or tightly coupled enough, that splitting it just adds coordination overhead (multiple budgets, multiple approvals, multiple things to check) without giving you anything you would actually act on independently.

Seeing the dependency graph

Your project’s Tickets list groups blocked tickets together and shows what each one is waiting on. For a full dependency graph and progress rollup across a multi-ticket scope, including which tickets are done, running, blocked, or failed, use the get_scope_graph MCP tool covered in the Alchemist Cloud Tickets MCP guide.

Next steps

Once a dependent ticket’s work is in, head to Alchemist Work Review to inspect what landed, or back to Alchemist Budgets and Costs for how spend is tracked across a multi-ticket scope.