IV. Automation workflows

1. How to divide a workflow into steps

Separate a task step in two situations:

1.1 A stage needs independent control

Typical reasons include:

• You must obtain external facts or other results before deciding what to do next.
• The action must follow fixed rules or a program.
• The stage needs separate reuse, retries or permissions.
• You want to insert a check at that point.

For example, you want to review customer replies before they are sent:

Receive inquiry → AI drafts reply → Human approval → Send.

1.2 Separation may improve performance

Use these principles:

• Keep information needed together in the same step, rather than having every step read everything. Reduce irrelevant materials and tools without repeatedly reconstructing shared context after a split.
• Handle independent work separately. Each part can focus on its own problem and may run in parallel. Work requiring frequent mutual revision is better kept together. Anthropic: division of work and context
• Pass necessary information accurately with little paraphrasing. Avoid omissions and distortions introduced by rewriting.
• A separate check is more valuable when criteria are clear and feedback guides a correction. Identify specific problems so the next step knows what to change. Anthropic: evaluation and improvement

Compare quality, time, cost and manual rework on the same tasks before and after the split. Keep it if the improvement justifies the cost.

LangChain, for example, tested 100 retail support tasks with the same model. It progressively added unrelated tools and instructions from other domains and compared three arrangements:

As unrelated domains increased, the unsplit approach degraded noticeably. Direct specialist replies performed slightly better than supervisor paraphrasing while using fewer tokens. The team found that paraphrasing could change the meaning and added another generation, so it also gave the supervisor approach a way to forward replies directly.

The useful split reduced exposure to irrelevant tools and instructions while avoiding unnecessary paraphrasing. With only one unrelated domain added, however, the unsplit approach was slightly better. Choose from test results rather than assuming more separation is always better. LangChain's comparison

2. Assign work to models, programs and people

Not every stage needs an agent. Programs are more predictable for fixed operations, so assign agents only where their capabilities are needed. Multiple agents are not necessarily better than one.

• Use programs when rules are clear and execution can be automated reliably. Examples include querying data, calculating totals, checking required fields and selecting branches from fixed conditions.
• Use models to interpret meaning, handle varied wording or generate content. Examples include identifying intent, organizing fault descriptions and drafting replies. Anthropic: workflows and model decisions
• Use people for personal choices, approvals and cases existing rules cannot resolve. Specify escalation conditions and pause there until a decision arrives. n8n: human review

3. Design paths for different situations

4. Checks and feedback loops

List possible errors at this stage, then choose a check for each:

• Use a program when you can write a clear decision rule. Check required fields, valid dates or correct calculations.
• Use a model to help check meaning. Supply the requirements, original material and result, with explicit criteria.
• If evidence is missing, obtain it. If the user must decide, ask them.

One stage can combine several checks. Anthropic: choosing evaluation methods

4.1 Design a checking node

Suppose you need to check event information extracted from this email:

Training takes place on July 12, 2026, from 14:00 to 16:00 in Building A, Room 301. Registration closes on July 10.

The model incorrectly extracts July 10 as the event date. Design these checks:

You can ask a development agent to implement the program check. Be specific:

Accept the extracted result. Check that title, start, end and location exist and are nonempty. Both start and end must include a parseable date and time, with start earlier than end. Return pass/fail plus each problematic field and its reason.

For the semantic check, add an LLM node with this prompt:

Original email: {{original_email}}
Extracted result: {{extracted_result}}

Check the event name, start, end and location individually.
Distinguish event time from registration deadlines and other dates.
Cite the relevant original wording for each judgment.
Mark absent or ambiguous information as "insufficient information"; do not guess.

Output:
status: pass / fail / insufficient information
issues: field, current value, source evidence, required correction

In visual platforms such as Dify, use a code node for program checks and an LLM node for semantic checks. Configure structured outputs for later conditional branches. Dify: LLM nodes and structured outputs

4.2 Feed checks back into the process

Extract → Program check → Semantic check → Create the calendar event after passing.

The extraction step only needs a model call with three inputs: original email, previous result and check feedback. The last two are empty on the first run. After failure, the workflow fills them with the previous output and specific issues, then calls the same model step again:

Extract the event name, start, end and location from the original email.

Original email: {{original_email}}
Previous result: {{previous_result}}
Check feedback: {{check_feedback}}

If feedback is present, correct the previous result using the original email.
Output the complete extracted result.

For example: “start uses July 10, but ‘Training takes place on July 12, 2026, from 14:00 to 16:00’ establishes July 12 as the event date. Correct it.” The model extracts again with these inputs, then the result reenters checking. The workflow controls the loop. Extraction need not become an autonomous agent or have a separately developed self-improvement feature.

Ask the user when the source lacks information. Allow at most two corrections, for example; escalate to a person if the result still fails.

If the checked step is a fixed program, handle the cause:

• Missing or incorrect inputs: Return to the input-producing step or ask the user, then rerun the program.
• Program logic or configuration error: Stop that path and have a person or development agent fix it. Rerunning unchanged usually does not help.
• Temporary network or service failure: Retry a limited number of times, then notify someone if it still fails.

Test the paths with correct results, missing fields, invalid dates, a confused deadline and missing source information. Model checks can miss errors too. In particular, test valid formatting with the wrong meaning.

5. Workflow examples

These examples adapt official tutorials to show complete processing paths and key design choices.

5.1 Write an onboarding guide from company materials

Task: Write a guide from existing materials, confirming scope before drafting.

flowchart TD
    A[Company materials, readers and required coverage] --> B[Model drafts outline]
    B --> C{Human reviews outline}
    C -->|Revise| D[Identify missing or unnecessary content]
    D --> B
    C -->|Approve| E[Draft from sources and approved outline]
    C -->|Cancel| F[End]
    E --> G[Check facts, coverage and source gaps]
    G --> H[Deliver guide and outstanding questions]

The outline is separate because the user wants to control scope first. The approved outline guides writing and can reduce restructuring after the full draft.

If intermediate approval is unnecessary, compare with generating the whole draft at once to see whether separation improves results.

Source: Anthropic: prompt chaining and intermediate checks.

5.2 Create a calendar event from an email

Task: Read an event email, extract its name, time and location, check them and create the event.

flowchart TD
    A[Original email] --> B[Model extracts structured data]
    B --> C[Program checks fields and date formats]
    C -->|Pass| D[Model checks meaning against email]
    C -->|Fail| E[Collect specific errors]
    D -->|Incorrect| E
    D -->|Source incomplete| F[Ask user and reprocess with added information]
    D -->|Pass| G[Create event and verify returned result]
    E --> H{Corrections remaining?}
    H -->|Yes| I[Return email, last result and feedback to model]
    I --> B
    H -->|No| J[Escalate to a person]
    G --> K[Report creation result]

The program checks whether later steps can use the fields. The model helps check whether their meaning is correct. July 10 is a valid date, but may only be the registration deadline.

Use a fixed set of output fields and formats. Leave fields empty when the source lacks the information, then ask for it. Do not make the model guess to pass validation.

Sources: Dify: structured outputs, LangChain: regeneration with error feedback.

5.3 Route customer inquiries to different processes

Task: Receive inquiries through one entry point and handle product use, order lookup and fault reports separately.

flowchart TD
    A[Receive inquiry] --> B[Identify intent and necessary information]
    B --> C{Inquiry type}
    C -->|Product use| D[Retrieve product instructions and answer]
    C -->|Order lookup| E[Obtain order identifier and query]
    C -->|Fault report| F[Collect fault details and create ticket]
    C -->|Insufficient information| G[Ask for missing information]
    C -->|Unsupported| H[Explain scope or escalate]
    D --> I[Check evidence and processing result]
    E --> I
    F --> I
    I --> J[Reply to customer]

Each path uses its own materials, tools and rules. Order lookup does not need all troubleshooting instructions; fault reporting should not merely reuse a general question-answering prompt.

Define how to handle multiple intents too: process them separately, or clarify first when uncertain.

Source: LangGraph: routing.

5.4 Process event registrations automatically

Task: Read registration information, check explicit eligibility conditions and register eligible applicants.

flowchart TD
    A[Receive application] --> B[Model extracts registration fields]
    B --> C{Required information complete?}
    C -->|No| D[Collect missing information through form]
    D --> C
    C -->|Yes| E[Program checks deadline and eligibility]
    E -->|Ineligible| F[Explain unmet conditions and end]
    E -->|Eligible| G[Write registration record]
    G --> H[Verify registration result]
    H --> I[Return success or failure reason]

The model understands the materials; the program applies established conditions. Missing names or contact details lead to clarification. Ineligibility leads to an explanation. These are different paths.

This structure suits applications with clear rules. Add a human branch for exceptions requiring an authorized decision.

Source: Adapted from IBM: extraction, fixed rules and form completion.

5.5 Answer questions from course materials

Task: Find evidence in specified course materials, answer and cite sources.

flowchart TD
    A[Receive question] --> B[Retrieve course materials]
    B --> C{Enough evidence to answer?}
    C -->|Yes| D[Generate sourced answer]
    D --> E[Deliver answer]
    C -->|No| F{Search attempts remaining?}
    F -->|Yes| G[Identify gap and revise query]
    G --> B
    F -->|No| H[Report findings and unresolved questions]

Check whether retrieved material actually supports the answer. Finding a registration-process section does not mean finding a rule about late registration.

Further searches should target the gap. Repeating the same keywords usually does not address an initial retrieval miss.

Source: LangGraph: retrieval, relevance checks and renewed search.

5.6 Turn one source package into posts for several platforms

Task: Generate platform-specific copy from text, images and documents.

flowchart TD
    A[Materials, platforms, language and style] --> B[Extract and validate platform list]
    B -->|Invalid| C[Request correction and end]
    B -->|Valid| D[Convert documents to text and read images separately]
    D --> E[Prepare shared facts and essential context]
    E --> F[Process each platform, optionally in parallel]
    F --> G[Read platform-specific content rules]
    G --> H[Generate copy using shared facts]
    H --> I[Collect structured platform outputs]
    I --> J[Program formats and delivers results]

Prepare common facts once and handle platform differences separately. The event date stays consistent, while length, tone and structure may vary.

Fixed final formatting belongs in a template or program. Retain platform names on outputs for matching and checking.

Source: Dify's complete multiplatform content tutorial.

5.7 Count issues in a batch of user feedback

Task: Organize feedback, count issues in each category and write a summary.

flowchart TD
    A[Feedback list and fixed categories] --> B[Keep an ID for each item]
    B --> C[Extract and classify issues item by item]
    C --> D{Classification format valid?}
    D -->|No| E[Limited corrections, then record unresolved items]
    D -->|Yes| F[Save ID, category and source evidence]
    E --> G[Collect all processing statuses]
    F --> G
    G --> H[Program counts valid records and items per category]
    H --> I[Model summarizes verified statistics]
    I --> J[Deliver counts, summary and pending list]

Separate understanding, calculation and expression: the model interprets feedback, the program counts it and the model summarizes the established numbers.

IDs make classifications traceable. List failures separately and state how many items were actually counted, so partial results do not appear complete.

Source: Adapted from Dify: item processing, aggregation and failures.

5.8 Translate, check and revise

Task: Translate a short passage using a glossary, then fix omissions, mistranslations and terminology errors.

flowchart TD
    A[Original, glossary and translation requirements] --> B[Model translates]
    B --> C[Program checks terms, numbers and explicit rules]
    C --> D[Model compares meaning and omissions with original]
    D --> E{Required corrections?}
    E -->|No| F[Deliver translation]
    E -->|Yes| G{Correction attempts remaining?}
    G -->|Yes| H[Revise using original, translation and specific feedback]
    H --> C
    G -->|No| I[Deliver current translation and unresolved issues]

Feedback should identify a location and evidence, such as “Paragraph two omits the applicability condition,” so revision knows what to change.

Recheck after revision to confirm the issue is fixed and no new problem appeared. State style preferences in advance to avoid shifting standards across rounds.

Source: Adapted from Self-Refine: revising with original input, previous output and feedback.

5.9 Send a customer reply after approval

Task: Draft a reply to a customer message and send it after approval.

flowchart TD
    A[Receive customer message] --> B[Retrieve necessary information]
    B --> C[Draft reply]
    C --> D[Show recipient, subject and body for review]
    D --> E{Human decision}
    E -->|Approve| F[Send with the reviewed parameters]
    E -->|Reject| G[Cancel sending and keep draft]
    E -->|Timeout under preset rule| H[Keep pending and notify]
    F --> I[Verify send result]
    I --> J[Report success or pending verification]

Approval covers a specific sending action, so show the recipient and body. Execute the same content after approval; changes require renewed confirmation.

Tool execution controls enforce approval and rejection. Keeping an expired request pending is an additional rule in this example.

Source: n8n: human review before tool execution.

5.10 Research a defined question

Task: Investigate a clearly scoped question and deliver a sourced briefing.

flowchart TD
    A[Question, deliverables and search limit] --> B[List issues to investigate]
    B --> C[Choose current issue and search method]
    C --> D[Search and read original sources]
    D --> E[Record evidence, sources and open questions]
    E --> F{Enough evidence?}
    F -->|Yes| G[Synthesize sourced conclusions]
    F -->|No| H{Further searches allowed?}
    H -->|Yes| I[Choose next action from gaps or conflicts]
    I --> C
    H -->|No| J[Summarize findings and remaining gaps]
    G --> K[Deliver briefing]
    J --> K

The control process is fixed; actual findings determine what to search for. Conflicting figures, for example, may require checking reporting dates and definitions.

Choose the next action from evidence already read. At the search limit, state findings and gaps rather than inventing unsupported material to make the answer look complete.

Source: Anthropic: choosing subsequent actions from real feedback.