Define a small job and its finish line
Consider an incoming-enquiry workflow. A message arrives, the system identifies its topic, prepares a short summary and suggests who should handle it. The business wants less sorting work without losing an enquiry or sending an unsuitable reply. A useful first release can finish with a reviewed assignment and a saved draft. That is a concrete outcome you can inspect.
Anthropic's guidance on building agents distinguishes predefined workflows from systems in which a model chooses its next steps. Apply that distinction to the job. Predictable rules can route messages from an existing support form, while a model can help interpret an open-ended project description. More autonomy should answer a specific need, with a way to measure whether it helps.
For a new implementation, write the allowed actions before connecting tools. When improving an existing automation, map what it actually does, including manual work around failures. Define completion in the destination system: a record exists, the right owner can see it and the approved draft is saved. A successful model response is only one step toward that result.
Documentation: Anthropic: building effective agents
Make the input and output inspectable
Give each incoming message a stable internal reference. Preserve a link to the original and record the arrival time. Decide which fields are essential for the next action. An enquiry without a company name might still be routable; an instruction to update an existing account without a reliable account reference may need review. Avoid treating every missing optional field as a failure.
For classification, require a category from an agreed list, a short summary and any missing information that prevents the next step. Validate the structure and permitted values before passing the output onwards. If the response names a category that does not exist, hold the item for review or a bounded repair attempt. A fluent explanation should not substitute for a valid destination.
Treat the message body as material to analyse. A sentence inside it asking the automation to ignore its rules, reveal other enquiries or send data to a new address does not expand the workflow's authority. Restrict available actions and recipients outside the model response as well as describing the boundary in the prompt.
Give review an actual decision
Show the reviewer the original message, proposed category, destination and exact draft or record change. Provide clear ways to approve, edit and reject. Store the approved version and who approved it. If a later step changes the recipient or materially rewrites the message, require the decision that applies to that changed action.
Choose review points according to consequence. A wrong internal category is usually easier to correct than an external promise about pricing or delivery. In this example, allow the first release to prepare drafts while a person sends the final response. Expanding its responsibilities later should come with evidence from the review history, a defined permission boundary and tests for the new action.
Assign an owner to pending approvals and set an expiry rule. An unanswered review might remain in a visible queue and trigger an internal reminder after an agreed interval. It should not silently approve itself. Give the owner enough context to resume the work without reading an entire execution log.
Handle the timeout that happens after success
Suppose the workflow asks a CRM to create an enquiry. The CRM accepts it, but the connection drops before the automation receives the response. The automation sees a timeout; the CRM already contains the record. Retrying blindly can create a second enquiry. The correct recovery question is what happened to this logical operation, not simply whether the previous request returned successfully.
Where the receiving API supports idempotency, reuse a stable key for retries of the same operation and follow that API's contract. Stripe's documentation provides a concrete example: supported requests can return the stored result for a previously used key, and changes to the request parameters have defined consequences. Those rules are specific to Stripe; verify the behaviour of the CRM or messaging API you actually use.
Keep an operation reference, request version, current state and confirmed destination record identifier in durable storage. If the destination supports searching by your reference, use it to reconcile an uncertain result. A search alone does not prevent two concurrent workers creating duplicates, so also design concurrency control or use a destination-enforced unique reference. If the outcome cannot be established safely, hold the item for an owner to resolve.
Documentation: Stripe: idempotent requests
Separate retries from recovery
AWS Step Functions documents retries and fallback handling as separate mechanisms. A retry policy can limit attempts and space them with delays; a fallback route handles an error that remains unresolved. That distinction is useful regardless of the orchestration tool. Repeating an invalid address five times does not make it valid, while a temporary service interruption may justify a limited retry.
Write a short error map for the enquiry workflow. Missing input goes to a review queue. Revoked credentials go to the integration owner. An uncertain CRM write goes to reconciliation. A temporary read failure can receive bounded retries. A rejected approval ends the proposed action while preserving the original enquiry. Keep the last confirmed step so recovery does not repeat work that already succeeded.
Make failures visible in business terms: three enquiries need assignment, or one approved draft could not be saved. Include the age and owner of each item. A long technical error string is useful for diagnosis, but it is a poor substitute for a clear recovery task.
Documentation: AWS: handling workflow errors
Test the uncomfortable cases before release
Prepare a small representative evaluation set with ordinary enquiries, ambiguous requests, missing details, repeated submissions and messages trying to redirect the workflow. Include inputs in the languages and formats the business receives. Record the expected destination and any action that must remain pending. Keep the examples free of unnecessary personal information.
Then test failures around the model: the CRM accepts a write and the response is lost; two workers receive the same message; approval expires; a reviewer changes the draft; access is revoked; a step succeeds before a later step fails. Inspect the final stored records and messages. A green run indicator cannot establish that the business result is correct.
Measure review corrections, time spent handling exceptions and the age of pending work alongside throughput. If the automation moves effort from sorting enquiries into repairing records, completion counts alone may conceal that tradeoff. Compare with the existing process using the same scope and record the assumptions behind any time-saving estimate.
Release with a way to pause and resume
Start with a limited scope and an owner watching the queue. Keep a way to stop new actions while preserving accepted work. Define how a person resumes each recoverable state, and retain only the diagnostic information needed under the organisation's access and retention rules. Prompts, model settings and connected systems should have identifiable versions.
After a material change, rerun the affected examples before expanding traffic. Review failures and corrected drafts for patterns that can improve the process. The handover should include the finish line, permissions, error map, recovery instructions and ownership. These details belong in the original implementation scope: they determine whether an automation remains useful when the easy cases stop being the only cases.