Reliable AI agents need operating rules, not just better prompts.

Retrospective · week of 31 August 2026

“Never create the same quote twice.” That sounds like a sensible instruction in an agent's prompt. But what happens if the quote is created and the connection drops before the agent receives confirmation? On restart, a written instruction cannot establish what actually happened.

In its guide published on 31 August 2026, n8n distinguishes the model from the logic that manages its execution over time. This distinction encourages a closer look at the mechanisms around the agent, not just the quality of its instructions. Source: n8n, Long-running agents beyond prompt engineering.

Separate understanding from execution

A model can interpret a request, suggest a category or prepare text. The workflow must then determine which operations are allowed, using which information and under what conditions. This separation makes important decisions inspectable without having to reread an entire conversation.

In a sales process, “prepare a quote” and “send the quote” are different steps. They should remain separate even when the conversation mentions them in a single sentence. An explicit approval status gives the team a control point that text alone cannot provide.

Two kinds of memory, two purposes

Conversation history helps establish what the requester wants. An operation record establishes what the system actually attempted and confirmed. Mixing them up is like treating meeting notes as proof that an action was completed.

For each important operation, plan to record a request reference, an action reference, a status and, where available, the identifier returned by the destination application. Distinguish “pending”, “confirmed” and “outcome uncertain”. That final state matters: missing confirmation does not always prove that an action failed.

Illustrative example: an interruption after creation

Imagine a demonstration workflow that creates a draft quote in a test application. The connection is interrupted immediately after creation. When the process resumes, it first checks whether the corresponding draft exists instead of immediately repeating the creation step.

If the application supports duplicate prevention using a unique reference, that safeguard can complement the check. Otherwise, an appropriate verification step and human intervention may be necessary. The same guarantee should not be promised for every application: the options depend on the destination system and the failure scenario.

Test failure, not just success

Useful acceptance testing includes controlled interruptions before an action, while awaiting confirmation and after confirmation has been recorded. Write down the expected result for each case. The right outcome might be automatic recovery, but it might also be a pause accompanied by a clear alert.

In particular, check that restarting does not produce a second document or send another notification when the first is already confirmed. Also test a handover to another person: can they understand the case status without knowing the development history?

Give the team a way to act

Supervision should expose blocked requests, uncertain outcomes and the next available action. A generic “technical error” alert is less useful than a specific instruction: creation unconfirmed, check the reference before retrying. Also plan how to suspend new operations during an investigation.

Ask for a documented failure scenario, including the test result and its limitations. It offers more concrete evidence of how the system works than a demonstration with no interruptions. SWM's automation service provides a way to include this thinking when defining the workflow. Let's examine how your workflows recover from errors without repeating completed actions.