The process you already run manually — check a source, write something, format it, post it — is the best possible starting point for an automation, because it's already proven to work. The trap is treating automation as a chance to also redesign the process; do that and you're debugging two changes at once. Migrate first, improve after.
Step 1: write down what you actually do, not what you think you do
Before touching the automation canvas, write out your real current steps in order — including the ones that feel too obvious to mention. "I check if it's actually relevant" is a real step, even if you've never consciously thought of it as one; it needs to become an If node condition, and you can't wire a condition you haven't noticed you're applying.
Step 2: map each step to a node type
Most manual content processes decompose the same way:
- Checking a source → an HTTP Request node.
- Deciding if something's worth acting on → an If node.
- Writing something → a Custom Agent node, prompted to match how you'd actually write it (see the Custom Agent prompting guide).
- Formatting/designing → an Apply Template node, against a template built from your existing format.
- Publishing → a Post node.
Steps that don't map cleanly onto one of these are usually either a Code node's job (some manual reshaping or calculation) or a genuine judgment call worth keeping human — see when not to automate your content for telling the two apart.
Step 3: match the manual version before improving it
Build the workflow to produce output as close as possible to what you'd have made by hand — same structure, same rough tone, same decisions. Resist the urge to also fix things you've always wanted to change about the process; if the automated version behaves differently from the manual one in more than one way at once, and something looks off, you won't know whether it's the automation or the change that caused it.
Step 4: run it alongside the manual process first
For at least a few cycles, keep doing the manual version too, and compare — does the automated draft match what you'd have written? Where it doesn't, that's specific, concrete feedback for tightening a prompt or a binding, rather than a vague sense that "something's off." This overlap period costs you double the time briefly, and saves you from trusting an automation that's subtly wrong in a way you haven't caught yet.
Step 5: hand off gradually, not all at once
Once the automated version has matched the manual one closely across several real cycles, stop running the manual version — but keep the pre-launch checklist habits (varied test input, reading actual output, not just green nodes) rather than assuming a good comparison period means you can stop paying attention entirely.
Why this order matters more than it seems to
Migrating a proven process is fundamentally lower-risk than designing a new one from scratch, precisely because you already know what "correct" looks like — you're not guessing at whether the output is right, you're comparing it against a process you trust. That comparison is the whole safety net; skipping straight to "redesign and automate at once" throws it away for no real benefit.