How it works
An agentic workflow separates decisions that benefit from model judgment from controls that should remain deterministic. The harness defines the stages, admissible transitions, tool permissions, budgets, checkpoints, and terminal states. Within a stage, an agent may interpret context, choose among allowed actions, or produce an artifact for validation.
A typical execution follows a controlled sequence:
- The harness loads authoritative workflow state and assembles the context for the current stage.
- The agent receives a bounded objective, available tools, and an explicit completion contract.
- The agent selects or proposes actions within that boundary.
- Deterministic checks validate permissions, schemas, budgets, and required evidence before side effects occur.
- The harness records the outcome, advances the workflow, requests approval, retries safely, or stops.
The workflow owns progression. The model does not decide that a failed write succeeded, silently skip a required approval, or invent the next stage. This distinction matters because model output is probabilistic while workflow state must remain operationally legible. If execution is interrupted, the harness should be able to identify the last committed state and determine whether resuming, replaying, or compensating is safe. Agentic behavior lives inside the process. It does not replace the process.
Why it matters in an agent harness
An unconstrained agent can appear capable because it adapts freely, but that freedom makes failures difficult to classify. When the same model can choose the goal, select tools, mutate state, and declare success, the operator lacks a stable control boundary. A plausible transcript may conceal a skipped check, an unauthorized action, or an incomplete result.
An agentic workflow assigns those responsibilities deliberately. The agent supplies judgment where inputs are ambiguous. The harness supplies authority, state, and enforcement. That division improves several engineering properties.
Control becomes explicit because each stage has a defined objective and a limited set of transitions. Permissions can narrow as work moves from reading to writing or publishing. A research step might access broad retrieval tools, while a later mutation step receives only the credential and operation needed for one approved change.
Reversibility improves when side effects occur behind checkpoints and stable identifiers. Before retrying a timed-out operation, the harness can inspect whether the prior attempt committed. Idempotency keys, execution journals, and compensating actions prevent a retry from becoming an accidental duplicate.
Observability also becomes more useful. A raw conversation trace shows what the model said. Workflow events show which stage ran, which policy authorized an action, what state changed, and why execution stopped. That structure supports debugging and evaluation at the level operators actually care about: whether the process produced a valid outcome without exceeding its authority.
Failure containment is the final benefit. A malformed artifact should fail its stage contract rather than contaminate every downstream step. A provider outage should block the workflow visibly rather than be mistaken for weak evidence. The workflow gives each failure a place to surface and a bounded area in which to recover.
Agentic Workflow vs Agent Loop
The distinction changes where you place control. An agent loop repeatedly lets a model observe, decide, and act. An agentic workflow may contain one or more loops, but the workflow governs when they start, what they may do, and how their outputs affect durable state.
| Design question | Agentic workflow | Agent loop |
|---|---|---|
| Primary concern | End-to-end process control | Iterative model action |
| Progression | Defined stages and guarded transitions | Repeated observe-decide-act cycle |
| State authority | Harness or workflow store | Often local loop context unless externalized |
| Completion | Workflow contract and terminal state | Loop stop condition |
| Recovery | Resume from committed workflow state | Restart or reconstruct loop context |
Use a loop when the task requires exploration or iterative tool use. Wrap it in a workflow when its result triggers later stages, durable mutations, approvals, or obligations that must survive interruption. Treating the loop itself as the whole system often leaves permissions, recovery, and success semantics implicit.
The Rifty take
We optimize for bounded judgment inside an explicit execution path. We accept some orchestration overhead because durable state, narrow permissions, and visible failure modes are more valuable than maximum local autonomy. The boundary is firm: the model may recommend progression, but the harness authorizes and records it.
Implementation checks
- Define the authoritative state and allowed transitions for every stage.
- Give each agent invocation one bounded objective and a machine-checkable result contract.
- Separate read permissions from mutation permissions, and grant them only when needed.
- Put approvals before consequential side effects, not after an agent has already acted.
- Record tool calls, policy decisions, state changes, retries, and stop reasons.
- Make retries idempotent or pair side effects with explicit compensating actions.
- Treat provider, credential, and quota failures as operational blocks.
- Test interruption at each checkpoint and verify that resumption does not duplicate work.
- Evaluate workflow outcomes as well as individual model responses.
Frequently asked questions
When should I use an agentic workflow instead of a deterministic workflow?
Use an agentic workflow when at least one step requires interpretation, selection, or planning that cannot be expressed reliably as fixed rules. Keep deterministic code around that step for permissions, validation, state transitions, and side effects. If every valid decision is already enumerable, a conventional workflow is usually easier to operate.
How much autonomy should an agent have inside a workflow stage?
Grant only the autonomy needed to satisfy that stage's objective. Bound available tools, data, actions, iterations, and completion criteria independently. A research stage may explore several sources, while a publishing stage should permit only a validated mutation. Autonomy should follow the task's uncertainty, not the model's maximum capability.
Where should workflow state be stored?
Store authoritative workflow state outside the model's conversational context in a durable, inspectable system. The context may contain a projection of that state, but it should not become the sole record. Each committed transition should identify the stage, inputs, outputs, policy decision, and side effects needed for recovery.
How do I make an agentic workflow safe to retry?
Make every consequential step idempotent or detectable before repeating it. Assign stable operation identifiers, record commit outcomes, and distinguish failure from an unknown outcome such as a timeout after submission. Where idempotency is impossible, define a compensating action and require operator approval when recovery could amplify the original effect.
How should an agentic workflow be evaluated?
Evaluate both model behavior and end-to-end workflow outcomes. Check whether the run reached a valid terminal state, respected permissions and budgets, preserved required evidence, handled interruptions, and avoided duplicate side effects. A strong response inside one stage does not compensate for an invalid transition or an unrecorded mutation.