Lesson 7 of 9 · 9 min read
Workflows and automations
When the same task comes up every week, stop asking an agent from scratch. Turn it into an automation with fixed steps, a human checkpoint and a history you can check.
When a chat should become an automation
You ask an agent for the same thing every Monday: pull the overdue invoices, draft reminders, send them once you have looked. Each week you retype the request, each week the agent works out the steps again, and each week the result is slightly different. That is the signal. When a task is repeated, predictable and worth getting the same way every time, it belongs in an automation, not a fresh conversation.
A good candidate passes four tests:
- It recurs. Weekly, daily, or on every new record.
- The steps are known. You could write them on a card (the plan-first case from lesson 3).
- The inputs are clear. The same sources every time, or a small set of parameters.
- Success is checkable. You can tell whether a run worked.
An open question ("why did churn jump?") fails the second test and should stay in a chat. A one-off task fails the first. Do not automate for the sake of it.
Agent, workflow, or both?
The words get blurred, so be precise. An agent chooses its own steps. A workflow is a fixed sequence of steps someone designed. The useful combination is a workflow whose steps are carried out by agents: the order, the checkpoints and the failure handling are fixed and visible, while each step still gets an agent's flexibility inside it. You get predictability where it matters and intelligence where it helps.
Designing the steps
- Trigger. What starts it: a schedule, a button, or another system calling in.
- Steps with one goal each. "Find overdue invoices and draft reminders" is one step; "send the reminders" is another. Small steps are easier to check, retry and reuse. One to three steps is enough for most jobs.
- Dependencies. Which step needs which earlier result.
- A human checkpoint before the irreversible step. Not at the end, when it is too late, and not on every step, which causes the approval fatigue from lesson 5. Put it where the action becomes hard to undo.
- Failure handling. Retries for flaky systems, a time limit for each step, and a clear owner who hears about a failure.
- Output. Where the result goes and who sees it.
Recovering from failure without doing damage twice
Automations fail. A connector's sign-in expires, a system is down for maintenance, an input is malformed. The naive fix is to run the whole thing again. That is fine when every step only reads. It is a problem when some steps have already changed things: rerunning the whole automation can send the same reminder twice or create duplicate records.
The better fix is to retry from the failed step: keep the results of the steps that completed, fix the cause, and continue from where it broke. This is also why small steps help. The smaller the step that failed, the less work is repeated and the smaller the risk of doing something twice.
Worked example: Monday invoice reminders
An accounts team turns its weekly chat into an automation. (You will meet the same team again in lesson 9.)
- Trigger: every Monday at 9am, in the team's own timezone.
- Step 1 (agent: accounts assistant): "Find invoices more than 30 days overdue. For each, draft a polite reminder to the billing contact on file. Do not send anything." This step only reads and drafts.
- Step 2 (agent: accounts assistant), requires approval: "Send the reminders drafted in step 1." The run pauses here until someone on the team reviews the drafts and approves.
Week four: step 2 fails because the mail connector's sign-in expired. Step 1's drafts are fine. The owner reconnects the mail account and retries from the failed step. The drafts from step 1 are reused, not regenerated, so the reminders that go out are exactly the ones that were reviewed.
Every automation needs an owner
An automation that nobody owns keeps running long after anyone checks it. Give each one a named owner who reads its run history, hears about failures, and decides when it should change or stop. The owner also keeps its instructions current: when the process changes, the automation's steps should change on purpose, the same day, rather than drifting out of date. Review each automation on a regular rhythm, monthly for most. Ask whether it still runs, whether people still read its output, whether the approval step is still being read rather than clicked through, and whether a step now fails often enough to need attention. Retire automations that no longer earn their place. Fewer, well-kept automations beat a long list nobody trusts.
Automations in Renly
In Renly these live under Automations. A workflow is a list of steps; each step names the agent that carries it out and the instructions it receives, and can run after an earlier step. Any step can be marked Requires approval, and the run pauses there until a person approves or rejects, in the run history or on the Approvals tab. Steps can retry on failure. Every run keeps its steps and outputs, and a failed run can be restarted with Retry failed step, which reuses the steps that already completed, or Re-run same input, which starts over. Schedules run in the timezone you choose. Automations can also be started from other tools through Renly's MCP server.
Build a two-step automation with an approval
About 15 minutes. You need a workspace and an agent that can use Renly's to-do tasks (any agent will do).
- Open Automations in your workspace, choose New, then Workflow.
- Choose Add Step and name the step "Draft". Pick an Agent, and write its Instructions: "List the three most important things I should do this week and draft a one-line to-do task for each. Do not create anything."
- Choose Add Step again. Name it "Create", pick the same agent, set Run after to the first step, and write: "Create the to-do tasks drafted in the previous step." Tick Requires approval. Save.
- Choose Run. Open the Runs tab and watch step 1 finish and the run pause before step 2.
- Read what step 1 produced, then choose Approve. Check that the tasks were created.
- Run it once more and choose Reject this time. Notice step 2 does not run.
- If a run ever fails, open it in Runs, choose View error on the failed step to read what went wrong, fix the cause, and choose Retry failed step.
When you are happy with it, open the Schedules tab, choose Add schedule and pick a preset such as "Every Monday at 9am" with your timezone.
Key takeaways
- Automate tasks that recur, have known steps, clear inputs and a checkable result. Keep open questions in chat.
- The strong pattern is a fixed workflow whose steps are carried out by agents.
- Keep steps small, one goal each. Put the human checkpoint just before the step that is hard to undo.
- Retry from the failed step so completed work is reused and nothing is done twice.
- Every run should leave a history: steps, outputs and the decisions people made.