How a run executes
What actually happens between an issue arriving and a pull request opening. This is the mechanical model behind every run · one level below the how-to, so you can reason about what an agent will do before you run it.
#A run is one issue through one pipeline
When an intake trigger fires, AgentSDE creates a run · a single pass of one issue through the pinned version of one agent’s phase design. The run is the unit everything hangs off: its phases, its artefacts, its cost, and its status all belong to that one pass. Start the same issue again and you get a second, independent run.
#Each phase is a fresh, bounded invocation
The design’s phases run in order (the flow graph can branch, loop, or start a phase from an event). Each phase is an independent invocation, not a continuation of the last one:
- the model named on the phase is called with that phase’s system prompt,
- the run’s context is supplied · the issue, the repository, the base branch,
- and only the tools the phase allows are available to it.
A phase does not inherit the previous phase’s conversation or reasoning. It starts fresh and reads what earlier phases produced. That boundary is deliberate · it keeps each step grounded in concrete inputs rather than a growing, drifting context.
#Every phase leaves an artefact
As a phase finishes it writes an artefact you can read on the run detail · a refined brief, a plan, a diff, a review, compounded notes. The next phase reads those artefacts, not the raw model output that produced them. This is why a run is reviewable at every step: each phase hands the next a concrete, human-readable result rather than a black box.
#The run advances on the phase’s outcome
A phase ends in one of three ways, and AgentSDE decides the next move from that outcome:
- Completed · advance to the next phase.
- Needs input · hold the run and hand control back to you; it resumes from here when you answer or approve.
- Failed · apply the phase’s on-failure rule · retry it, skip it, or halt the run. A retry re-runs the phase as a fresh attempt; the earlier attempt stays in the history so nothing is silently overwritten.
#The work happens on the agent’s own branch
Throughout, the agent works on its own branch, never directly on yours. It reads the code, makes its changes, and when the pipeline reaches a delivery phase it opens a pull request from that branch, requesting the reviewers your branch protection already requires. There is no path by which a run merges to a protected branch or relaxes a rule · that decision stays entirely with your reviewers and checks. An agent is a contributor, not an administrator.
#Cost accrues phase by phase
A run’s cost is the sum of its phases · each phase’s usage is priced as it completes, per the model that phase used. Two consequences worth internalising: a run that stalls in an expensive phase is the one to watch, and the safest way to try an ambitious design is inside an environment with a budget set (see phase designer → quotas and caps).
#A run is live until it reaches a terminal state
From creation a run is live · running, or paused, or waiting on you. It ends when it ships (the work is done), fails (a phase errored past its retries), or is stopped (you ended it deliberately). Every status and how to intervene are covered in run anatomy and controlling a run.