Design your development workflow

An agent finishes a change. Before someone can merge it, the team still needs to know which requirements it met, what was checked, and whether the reviewer approved the code that is now on the branch.

Make those questions part of your development process. Give each stage an input, an output, a condition for advancing, and someone responsible for the decision. Then decide which conditions software can check and which need engineering judgment.

This guide is for engineers building a workflow around their own coding agents, repository instructions, and CI. You can apply the model with your existing tools. The implementation walkthrough shows how Radial's pipeline configuration and build records fit into it.

Define a stage contract

Take one recent change through your process. Write down what someone needed before starting each stage and what the next person needed when it ended. Include the path back when a check or review fails.

Here is an example lifecycle. Adapt it to your team; a documentation correction and a database migration may need different checks.

1. OwnerSpecifyScope approved
2. Engineer + agentImplementCandidate commit
3. RunnerVerifyCurrent evidence
4. ReviewerReviewCandidate approved
5. Release ownerReleaseRunning revision checked

For each condition, name who evaluates it. A test runner can check a return value. A reviewer decides whether the behavior meets the intent of the request. A release owner authorizes a production change. Record those decisions where the next participant can read them.

Separate instructions from checks

Keep design context, tradeoffs, and working procedures in readable instructions. Put conditions with precise answers into code: whether a dependency is complete, whether the required tests ran, or whether an approval names the current candidate.

JSON gives that code a shared input. Define the meaning of each field before adding it. A required property only affects behavior if something reads it and refuses the operation when the requirement is unmet.

The agent can choose an implementation and request the next step. The component authorizing that step evaluates its prerequisites. If merging requires passing CI, enforce that at the merge boundary. An instruction in one agent's context cannot enforce the same rule for every other client.

Specify what this process layer evaluates, which operations it controls, and what evidence it retains.

Bind evidence to the work it checks

A test result needs enough context to determine whether it still applies. Record the candidate commit, check command or definition, process version, result, and relevant environment. Deployment checks also need the identity of the running revision.

Suppose unit tests pass on commit A. The agent then changes code and creates commit B. Keep A's result in the history, but require evidence for B before advancing. Apply the same rule to review: an approval should identify the candidate the person reviewed.

1. Commit AAttempt 1Blank input is accepted. Unit check fails.
2. Commit BFixReject blank input and commit the change.
3. Commit BAttempt 2Run the check again. Preserve both results.

Decide which sources count for each condition. An agent's report of a manual check, a local command's execution record, and an authenticated CI result give you different evidence. A process can accept all of them while requiring a particular source for a particular decision.

Make failure and interruption ordinary paths

When verification fails, retain the failed attempt and return the change to implementation. A later pass should add evidence without erasing the failure. When an agent stops, the next session should be able to read the current state and identify unfinished work.

Specify these behaviors before adding more stages:

• A retry creates a new attempt. Re-sending the same event should not duplicate it.
• A changed candidate makes affected results and approvals stale.
• A blocked dependency names the work or decision that will unblock it.
• Concurrent workers claim work through an operation that prevents conflicting ownership.
• A waiver names its author, reason, scope, and expiry, while preserving the failed or missing check.

Keep execution status separate from acceptance. A finished run may have failed. Moving an issue to another status should not create test evidence or imply that someone approved the change.

Version the process

Review process changes in Git alongside the code they govern. Keep the definition used by an execution with its record, so a later policy edit does not change the meaning of an earlier result.

Define how active work adopts a new process version. That might mean finishing under the original definition or explicitly starting a new execution. Avoid silently combining checks from one version with approval rules from another.

If your team varies checks by risk, make the selection rule inspectable. Record which checks were excluded and why. A missing result gives the reviewer no way to distinguish a deliberate exclusion from work that never ran.

Apply the model in Radial

Radial provides a JSON pipeline definition, CLI commands for recording and executing checks, and a build record attached to the issue. Your agents and automation drive those interfaces.

Each session header identifies its client, time range, and recorded usage. Stage markers show where the work happened; tool calls fold together so you can follow the conversation. Read the session analytics guide to interpret the figures and their limits.

The pipeline does not automatically schedule stages, select checks by risk, invalidate stale evidence, or enforce approval rules. Finishing a build closes its execution record; required gates can still be missing or failed.

Start with Implement a workflow with Radial to configure a pipeline, record a failed check, and keep both attempts when it passes.