Why orchestration matters more than any single model
Every autonomic pipeline this manifesto describes is made of the same three moves, repeated: decide what happens next, produce something, hand it to the next step. No single model does all three well. A language model is good at drafting. An image model is good at rendering. Neither one is good at waiting for the other, retrying when something fails, or knowing when a whole run should stop instead of publishing something broken. That coordination layer is its own problem, separate from any model sitting inside it -- and n8n is the tool I reach for to solve it.
What n8n actually buys you
n8n is a visual workflow tool: nodes on a canvas, wired together, each one doing one job -- call an API, run a script, branch on a condition, wait for a signal. Nothing about that is exotic. What makes it fit an autonomic pipeline specifically is that every node is just an HTTP call or a script step, which means a workflow can freely mix a local model, an image generator, a database, and this site's own content API in one run, without any of them knowing the others exist. The pipeline is the thing that knows. Each step stays replaceable -- swap the model, swap the image generator -- without touching the steps around it.
A standing process, not a script you babysit
The distinction that matters is the one this manifesto keeps returning to: automation you configure once versus autonomy you keep governing. A workflow like this doesn't run once and finish -- it sits there, triggered on a schedule or a signal, pulling in whatever's next, producing output, and publishing it through the same generic API this content model already exposes to every other source. Nobody has to remember to run it. Somebody does have to be able to see what it decided, and stop it if it decides badly -- which is exactly why it publishes through the ordinary API instead of writing to the database directly, leaving the same audit trail any other content source would.
What this post actually proves
This post is the test case, not just the description of one. It went from a short brief to published content through exactly the kind of pipeline described above -- text and images produced as separate steps and assembled into one article, the same shape a fully automated run will take once the remaining step, an unattended trigger, is wired in. What's published here is deliberately the shape of the mechanism, not its internals -- the specific prompts and node wiring stay unpublished, the way any working system's implementation details do.