Agentic Workflow in one minute
Think of a route with fixed checkpoints and room for a useful detour. A system reads products, investigates ambiguous cases and prepares changes for review. The workflow tracks conditions and progress; an agent may choose which investigation to try. Flexibility is most useful when it has clear boundaries and a way to stop.
Agentic Workflow combines predictable structure with flexibility
In a deterministic workflow, predefined rules select the next step. If a required field is empty, flag the record; otherwise continue. This describes the control flow, not a promise that every external service or model output is constant. A fixed process can call a probabilistic model while still following predefined branches.
An agent has more discretion over the next operation. It may inspect a source document, compare two records or request clarification based on what it finds. Anthropic's explanation of effective agents uses a similar distinction between code-defined workflows and model-directed tool use. Terminology varies across the industry, so explaining the actual control mechanism is more useful than relying only on the label.
| Aspect | Predefined workflow | Flexible agent step |
|---|---|---|
| Decision | An explicit rule or branch. | A model selects from permitted operations. |
| Example | Flag every missing product code. | Investigate conflicting measurements in two sources. |
| Strength | Predictable handling of known situations. | Adaptation when the evidence varies. |
| Required control | Valid inputs, permissions and checked outputs. | The same controls plus limits on discretion and attempts. |
These approaches can sit inside one process. A fixed validation can identify the exceptional records, an agent can investigate them and another fixed check can validate the proposed output. There is no need to use a model for an arithmetic comparison or a mandatory-field rule simply because the broader system uses AI.
An example with 400 product records
Start with a clear assignment: inspect 400 selected products for missing or contradictory information and prepare proposed corrections. Specify the required fields, authoritative sources and allowed actions. The first step checks that the selected records are complete, including pagination, and records their identifiers. The task should not silently expand to the entire catalogue.
- Select
Retrieve the agreed records and preserve their identifiers and versions.
- Validate
Apply fixed checks for required fields, formats and units.
- Investigate
Let the agent examine ambiguous cases using permitted sources.
- Review
Show proposed changes and evidence where human approval is required.
- Apply and verify
Execute authorised changes and check the resulting records.
Branching determines where each record goes. Complete records may need no action. Missing information may call for a source lookup. Contradictory information may require a specialist. If no reliable evidence is available, the correct outcome is an unresolved item with an explanation, not a plausible value invented to make the table look complete.
Tool Use supplies operations. Connectors provide routes to source systems, and MCP may standardise part of their interface. RAG can supply relevant passages for an answer or proposed correction. These components support the workflow but do not decide its success criteria or replace record-level validation.
Validation should address meaning as well as format. A generated JSON object can match its schema while containing the wrong product variant. Check source identifiers, units, dates and relationships. A value copied accurately from an obsolete catalogue can still be inappropriate for the current product. The checks need to reflect the actual business data.
Persist status clearly. 'Investigated', 'proposal ready', 'approved' and 'applied' are distinct stages. AI Memory or durable application state can preserve them between runs. When a task resumes, check whether its source records have changed. An approval based on an earlier version should not blindly overwrite a colleague's more recent edit.
Human-in-the-loop provides the decision point where needed. Show the old value, proposed value, source and consequence before execution. The process must also handle rejection or correction. A diagram with an approval box is incomplete if every response, including no response, eventually leads to the same write operation.
Retries, scheduling and logs make continuation manageable
Retries should target recoverable failures. A temporary connection problem may justify another attempt within a limit. A denied permission or missing source generally calls for a different response, not an endless loop. Bound the number of attempts, elapsed time or cost and define what information is returned when the task cannot continue.
Repeating an operation should not create an unintended duplicate. After a timeout, a write may already have succeeded. Use supported operation identifiers or inspect the target state before trying again. Sending a second message or adding a duplicate CRM note is not a harmless retry merely because the first response was lost.
Durable execution mechanisms can preserve progress and help resume work after interruptions. LangGraph's persistence documentation is one concrete implementation of checkpoints and saved state. Recovery behaviour varies by framework; a resumed step may execute code again. Design side effects so that replay does not accidentally repeat a consequential action.
Scheduling is another application capability, not a property of a persuasive chat response. Periodic checks need a real scheduler, time zone, task definition and delivery channel. Decide what happens when runs overlap, a source is unavailable or the same condition stays true for several days. A failed check must not be treated as evidence that the condition is false.
Logs should make the process understandable: task identifier, tool used, relevant source version, decision, status and verified outcome. They do not need to retain every prompt or full document indefinitely. Avoid unnecessary personal data and credentials, and make it possible to connect an unresolved exception to the operation that produced it.
- Define success and stopping conditions before execution.
- Separate routine rules from investigations requiring flexibility.
- Preserve meaningful state across pauses and failures.
- Validate important outputs before using them downstream.
- Check the final result against the original assignment.
Measure the workflow by usable outcomes and the exceptions it handles correctly, not by the number of agents or tool calls. AI Agents offer flexibility; the surrounding workflow gives that flexibility a purpose, a boundary and a traceable result. Sometimes the best outcome is a completed table, and sometimes it is a clearly documented question for the responsible person.