A temporary pull request status that signals the work is still in progress and not yet ready for approval. In agentic workflows, draft state acts as a control boundary that prevents unfinished machine-generated changes from being treated as release-ready.
What a draft state does
A draft state marks work as incomplete, so reviewers and automated systems can distinguish in-progress changes from content that is ready to approve, merge, or publish. It creates a clear control boundary around unfinished work.
Why draft state exists in review workflows
Draft state is most useful when changes pass through formal review, especially in repositories where a pull request may trigger checks, notifications, or deployment logic. By defaulting unfinished work to draft, teams reduce the chance that partial logic, broken tests, or unreviewed automation steps are treated as release-ready.
In agentic workflows, that distinction matters even more because generated changes may be large, fast, and operationally plausible before they are fully validated. Draft state gives the reviewer a visible signal that the artefact still needs human scrutiny before it can be considered part of the approved change set.
How draft state changes approval and merge behavior
A draft pull request usually remains outside the normal approval path until it is explicitly marked ready for review. That means the status affects reviewer expectations, merge eligibility, and in some systems the execution of downstream checks that depend on readiness. The practical effect is to separate collaboration from commitment.
Draft state is not the same as rejection or failure. It is a temporary status that preserves the work, allows iteration, and signals that the author has not yet asked for formal acceptance. This is why the state is useful for both individual contributors and automation-heavy teams: it preserves flexibility without removing control.
Where draft state fits in agentic change control
For machine-generated or agent-assisted changes, draft state functions as a lightweight governance boundary. It helps ensure that autonomous output stays in a pre-approval phase until a person confirms intent, scope, and correctness. In that sense, the state is less about the code itself and more about when the change is allowed to enter the trusted review path.
Used well, draft state supports safer delegation: the agent can prepare work, but the team still decides when the work becomes eligible for approval. That separation is especially valuable when generated changes touch sensitive logic, release pipelines, or other parts of the system where premature approval would create avoidable risk.
Risk and Threat Considerations
Draft state reduces the chance that incomplete or unvetted changes are mistaken for approved work, but it can fail if teams treat the status as a guarantee rather than a signal. The main exposure is process bypass, where automation, hurried reviewers, or unclear tooling let draft content move too quickly toward merge or release.
Failure mechanism: A draft item is converted to ready status, or otherwise acted on as if it were ready, before the content has been fully reviewed, tested, or scoped. In agentic settings, that can expose unfinished generated changes to approval paths, downstream automation, or deployment assumptions.
Impact: Incomplete logic, broken dependencies, or incorrect machine-generated modifications can reach production workflows, increasing the chance of defects, configuration drift, or unintended operational behavior.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Draft state limits when unfinished changes can gain approval authority or downstream effect. |
| CM-3 — Configuration Change Control | Draft state is a change-control status that separates in-progress updates from approved changes. | |
| SA-10 — Developer Configuration Management | Draft state supports controlled handling of incomplete work before release. | |
| Recommendation — Restrict promotion paths so draft changes cannot act with release-ready privilege. Require formal approval before moving draft changes into the controlled baseline. Use lifecycle controls to keep unreviewed changes in a non-release state until validated. | ||
| NIST CSF 2.0 | PR.IP-1 — Policies and Procedures | Draft state is governed by procedure for how work moves from preparation to approval. |
| PR.IR-01 — Identity Management | Promotion from draft to ready often changes who can approve or rely on the change. | |
| Recommendation — Define when a draft item may be promoted to ready status. Bind readiness transitions to accountable reviewers and approvers. | ||
Practitioner Guidance
What to watch for: Treat draft state as a workflow control, not a quality verdict. Review teams should look for ambiguous status changes, poorly defined readiness criteria, and automation that reacts to draft items as if they were final. The important governance question is whether the system makes it easy to keep unfinished work isolated until a person intentionally promotes it.
Practitioner takeaway: Draft state works best when it is tied to a deliberate readiness decision, not merely used as a courtesy label.