Key takeaways
- To decide how to build agentic workflows, first define what state survives a failure and where execution resumes.
- Record side effects before a retry can repeat them.
- Require approval when an action is irreversible, costly, regulated, or has a high blast radius.
What is an agentic development workflow?
An agentic development workflow puts AI inside a predefined process. An autonomous agent has wider control: it plans, executes, and iterates toward a goal. That distinction matters because it tells you which decisions belong to the process and which ones you are delegating to the model. Agents can reason through ambiguity, act across tools, and carry out multi-step workflows, but the model is only one part of the working system.
The rest is the harness. An agent harness connects agents to reasoning, action, and an environment model. It also supplies planning, memory, tool use, feedback-driven control, optimization, coordination, review, and verification. This is where a promising loop becomes an engineering system with boundaries you can inspect.
For a development workflow, the predefined process might own the sequence of specification, planning, implementation, tests, and review. The agent can still make choices inside a stage, use tools, and respond to results. In a more autonomous design, the agent may also decide how to plan and iterate toward the goal. Neither label settles the operational questions. You still need to define which state persists, which actions change the outside world, how progress is checked, and what happens when execution stops halfway through.
That is why we treat the agent loop as part of a larger control system. A loop can select and call a tool. A production workflow also needs a durable account of what happened before that call, what the call changed, and whether another attempt may safely run.
Decide what the model controls
If you are developing your own agentic AI, draw the boundary before choosing an orchestration pattern. Does the predefined process choose the next stage, or may the agent revise the plan? Does the model select a tool and parameters, or does it also perform the external action? Which component reviews the result and decides whether work continues?
These questions separate agency from infrastructure. Reasoning and planning can belong to the agent while memory, permissions, execution, feedback, and verification remain enforceable parts of the harness.
A predefined workflow and an autonomous agent can use the same model and tools. The difference is where planning and iteration live. Define that ownership in ordinary system terms: the process controls this transition, the model chooses this action, deterministic code performs this change, and the harness checks the result. That description is more useful than calling the whole system autonomous.
How to build agentic workflows from a recovery contract
Start with a recovery contract, not a happy-path diagram. Pair a capable model with well-defined tools and clear, structured instructions, then record the boundaries the implementation must carry. The matrix below covers the choices that determine whether an interrupted run can continue without losing its identity or blindly repeating work.
| Contract field | Decision to record | Concrete pattern or implementation example |
|---|---|---|
| Tools and instructions | Which tools the model may select, what each tool accepts, and which structured instructions govern the choice | Define tools and instructions as part of the agent foundation. Keep behavior-changing prompt, policy, tool-schema, and model-setting versions with the run record. Name the tool authority and accepted parameters so the execution component receives a bounded request. |
| Conversation and filesystem state | Which conversation state persists, which filesystem state has its own checkpoint, and the significant boundaries where execution state is serialized | Persisted conversation state does not preserve filesystem changes. Use separate filesystem checkpointing. Durable execution serializes complete state at significant boundaries so the run can resume at the failure point instead of restarting. |
| Decision and execution phases | Where the model chooses a tool and parameters, and where external action begins | Keep the nondeterministic decision phase separate from the deterministic component that performs the action. Give the execution component the chosen tool and parameters without asking it to repeat the model's decision. |
| Side-effect records and idempotency | What proves whether a partially completed mutation already ran before a retry | A retry can duplicate an unrecorded side effect. Deduplicate write operations at storage with a key composed from run_id, step_index, and action_type. Combine checkpoints with event-history replay and idempotent tool design for resumable execution after infrastructure failure. |
| Verification and readiness | What must be checked before implementation starts | Create the test plan before the implementation plan so tests inform implementation priorities. Use a readiness gate to check the specification, test plan, and implementation plan against the original ticket. |
| Stop and pause handling | Which response states mean use, continue, retry, or fallback, and what continuity an approval pause retains | Let the response's stop reason determine the harness action. Model approval as a paused run so history, turn count, and the continuation identifier remain consistent. |
| Action inventory and approval | Which tool calls, API requests, external messages, and state mutations need approval, including what each changes in the world | Require approval when the action is irreversible, costly, regulated, or has a high blast radius. Build that boundary from an inventory of every external action and the change it makes in the world. |
| Deployment, observability, and cost | Which artifact and settings produced the run, what traces are retained, and what budget limits execution | Use a reproducible, immutable artifact with external configuration and secrets. Record prompts, policies, tool schemas, model settings, retrieval settings, and migrations per run. GitHub Agentic Workflows can inspect time, token, and AI Credit consumption with gh aw logs and gh aw audit, set max-ai-credits, and export trace and token data through OpenTelemetry. |
Plans become durable runtime assets
A plan should survive the conversation that produced it. Store it as a versioned project asset with a deliberate lifecycle, then let the workflow refer to that asset as it works. This gives the plan two jobs: it directs execution, and it preserves the history needed to inspect the run later.
A small disk-based layout makes the lifecycle concrete:
plans/
staged/
feature-184.md
active/
feature-184.md
completed/
feature-184.md
handoffs/
feature-184.mdKeep work under preparation in staged, move the selected file to active for execution, and retain the finished copy in completed. The completed file remains an audit trail and an architectural reference. A fixed-format handoff records review results, deviations from the plan, and unresolved concerns.
Review results:
- ...
Deviations from plan:
- ...
Unresolved concerns:
- ...For extended autonomous execution, the active plan does not have to remain frozen. It can be a mutable runtime artifact that adapts while work continues. That flexibility has a hard boundary: the workflow must preserve invariants against cycles, orphaned dependencies, and lost state. A plan update cannot quietly sever a dependency or erase the record needed to continue.
This is a more useful model than treating the plan as chat residue. The staged copy captures intent before work begins. The active copy reflects the current execution path. The completed copy and handoff retain the outcome, review, deviations, and open concerns. The history remains available even when the runtime plan changes.
The plan is not the same thing as a checkpoint. A plan records intended work and its evolving structure. A checkpoint serializes execution state at a significant boundary. Keeping both as durable assets lets the workflow adapt its route without losing its place or rewriting its history.
Preserve the reason for a change
A mutable plan is useful when extended execution encounters work that the initial plan did not settle. The active artifact can adapt, while the staged and completed states preserve the lifecycle around it. The invariants are what keep adaptation from turning into drift: dependencies must not become orphaned, cycles must not enter the work graph, and saved state must not disappear.
The handoff closes the gap between what was intended and what was built. Review results capture the final check. Deviations record where execution departed from the plan. Unresolved concerns remain visible instead of being hidden by a completed status. Together, the completed plan and handoff preserve both the intended structure and the known differences at the end of the run.
This also changes how you inspect a resumed workflow. The active plan tells you what the workflow currently intends to do. The checkpoint identifies the stored execution boundary. The completed assets show earlier outcomes without asking the current conversation to carry the full project history. Durable execution is easier to reason about when those records have separate jobs.
What does an agentic coding workflow look like on GitHub?
A GitHub Agentic Workflow is repository automation defined in Markdown and run through GitHub Actions. A coding agent interprets repository context and acts from natural-language instructions. This is a useful concrete example because the authored workflow, compiled execution file, commit, trigger, and run all have visible places in the repository process.
The complete sequence is:
- Write the source workflow as a Markdown file that can live with the repository.
- Put configuration in YAML frontmatter and describe the work in natural-language instructions.
- Compile that source into the
.lock.ymlfile used by the GitHub Actions execution path. - Commit the source workflow and its compiled file so the repository contains both forms.
- Start a run from a GitHub Actions trigger or through the GitHub command-line interface.
The Markdown source carries the instructions a person can review. The compiled .lock.yml becomes the file used for execution. Committing both places the workflow definition inside the repository's versioned history. The run then starts from an Actions event or a command-line invocation. GitHub's creation documentation describes this source-to-compiled-file sequence.
That is the happy path, but the trust boundary starts before compilation. An imported GitHub Agentic Workflow should come from a trusted source and be reviewed before it enters the repository. Natural-language instructions can lead a coding agent to act on repository context, so importing a workflow is also importing an action surface.
Review happens while the workflow is still readable as source. The Markdown, YAML frontmatter, and natural-language instructions show what will be compiled. Only after that review does the source move through compilation, commit, and execution. This keeps the imported workflow inside the same repository change process as the code it may act upon.
This example does not replace the recovery contract. It gives the contract concrete attachment points: the source and compiled artifact establish deployment identity, the commit preserves a version, the trigger creates a run boundary, and the platform exposes run records. Our agentic AI example explores the coding pattern without turning the architecture into a framework contest.
Start with one agent and earn each layer of complexity
Develop your own agentic AI by beginning with one agent and a bounded workflow. Add more agents only when the workflow actually needs the extra orchestration complexity. A single-agent system already gives you the right place to settle tools, instructions, state, verification, approval, stop behavior, and recovery.
Use a controlled rollout:
- Begin with one agent and a defined set of tools and instructions. Keep the initial orchestration narrow enough that one execution path carries the work.
- Deploy the workflow on a small scale. The first deployment does not need every capability planned for the mature system.
- Validate the agent's behavior with real users. Treat that observed behavior as the basis for deciding whether the bounded workflow is ready to expand.
- Expand capabilities over time. Each addition enters a system that already has input, tool-use, and human-intervention guardrails.
- Add multiple agents only when the workflow requires the extra orchestration complexity. More agents are an architectural choice, not a default maturity level.
Production guardrails should cover input filtering, tool use, and human intervention. These surfaces are part of the workflow design, not a wrapper added once the agent starts taking broader action. The approval inventory from the recovery contract gives human intervention a concrete basis: tool calls, API requests, external messages, and state mutations are classified by what they change.
The small rollout also gives failures a contained place to appear. A minor failure can redirect later execution onto a different and unpredictable trajectory. That means a completed run is not the only object worth inspecting. The path, stop reason, tool decisions, side-effect records, checks, and recovery behavior all belong in the operating view.
Guard the path, not just the final output
Input filtering, tool-use controls, and human intervention cover different parts of production behavior. Input guardrails sit before the model works. Tool guardrails constrain the actions available during the run. Human intervention creates a boundary where the workflow cannot continue on its own. Define all three while the workflow is still small.
Then inspect the execution path when you validate behavior. A minor failure can alter what comes later, so the final completion state cannot describe the whole run. Stop behavior, tool use, and the later trajectory show whether a seemingly small problem redirected execution. This is especially important before adding another agent and another coordination path.
The practical test is a failure run. Interrupt execution after a side effect, resume from a checkpoint, and inspect whether the external action repeats. Pause at a consequential action and confirm that the existing run retains its history and continuation identity. Then read how the harness decides what survives production.