Klaus the n8n Octopus: Resurrecting a Dormant Agent Without Creating Frankenstein's Monster
A year-old AI agent design didn't ship. When the time came to revive it, the obvious move — finishing the original spec — was the failure mode. Here's how to resurrect dormant agents without stitching together Frankenstein.
A year ago I designed an LLM agent — call it Klaus — to coordinate the operations side of my SaaS: receive an event, decide which workflow needs to fire, dispatch the call, return a coherent response. The intended job was reducing the manual operational glue I spent hours on every week — show prep, reconciliation triggers, scheduled-task orchestration.
Klaus never got built that way. What got built was a single workflow plus a stub control plane that has been dormant for months. The original five workflows it was supposed to coordinate never got wired. The messaging input never shipped. The model still runs the original Mistral 7B instead of the mistral-nemo upgrade I specced for native tool calling.
Klaus is, in short, a coordinator without the workflows it was supposed to coordinate.
This week I had to decide whether to bring it back, and if so, how. Because the obvious move — pull the original work order off the shelf and just finish it — is exactly how you get Frankenstein’s monster.
Why this matters: shared state changes the coordinator’s job
The decision is forced by a substrate change. Earlier this quarter we landed three Postgres tables that any agent in our system can read and write: harness_runs (state machine — current phase, run status, phase results), workspace_files (per-run virtual filesystem so phases can produce intermediate artifacts), and agent_todos (durable, recoverable todo list per thread).
Concretely: if any agent dispatches a workflow and the process dies mid-run, the next cron tick reads the same harness_runs row, sees status='running' with a current_phase set, and resumes from that phase. The agent doesn’t have to remember anything between invocations. The substrate remembers for it.
That changes what a coordinator like Klaus needs to be. The agent doesn’t need to be smart enough to track its own state across crashes — the substrate handles it. The agent just needs to dispatch reliably and write its phase progress to the shared tables. Reviving Klaus before this substrate would have meant building yet another isolated agent. Reviving it now means it can fit into the system instead of standing apart from it.
Why now (operationally)
The real pressure: BDC is doing 4 WhatNot shows a month and 2-3 hours of post-show reconciliation per show. That reconciliation is currently me-manual. It’s also exactly the shape of work Klaus was designed for — receive sale events, dispatch the right reconciliation workflow, write results back. With Klaus working, that’s hours back per month. Without Klaus, it stays manual.
So the question isn’t “should we finish Klaus?” It’s “what does Klaus need to be in the system we have today, not the one we had a year ago?”
The Frankenstein failure mode
The original spec was written before the current operating model existed. It was written before our validation routines emerged as a distributed fleet across 18 scheduled tasks. It was written before the substrate landed.
Pulling that year-old spec off the shelf and executing it verbatim would mean:
- Bolting on the original five workflows regardless of whether they still match current operational priorities
- Adding the messaging input channel because it was on the spec, not because it’s the shortest path to a real outcome today
- Force-upgrading to mistral-nemo without checking whether qwen2.5-coder, llama 3.3, or deepseek-v3 — all shipped after the spec was written — would be a better fit
- Reanimating the dormant control plane on its old port without asking whether the current scheduled-task pattern already covers what it was supposed to do
That’s not resurrection. That’s stitching together a design from old parts that don’t speak the same architectural language. The result would be powerful, opaque, and would probably break production in ways nobody could trace.
The Lazarus path
The alternative: declare the agent dormant, then resurrect with current design intent.
The charter:
- Identity. Two coordinators sharing the same Postgres substrate, each owning a non-overlapping execution domain. The n8n-side coordinator handles operational dispatch — fast, deterministic, on-prem. The Claude-Code-side coordinator handles reasoning routines — multi-step, validation, complex review. They communicate through the shared tables, not through direct messages. Neither is subordinate; the shape is “two services with domain partitioning sharing a state store,” not “peer-to-peer” in the rigorous distributed-systems sense.
- Re-derive workflows from current needs. LOCG scrape coordination, FOC pricing dispatch, inventory-decrement listener post WhatNot sale, weekly pull-list recompute, statement-send orchestration. The year-old list assumed a world that doesn’t exist anymore.
- Substrate compliance from day one. No parallel state machine. No private bookkeeping. Every phase advance writes to the shared tables.
- Input channels by need, not by old spec. Whatever’s already working is the first input channel. Add others only if they’re the shortest path to a real outcome.
- Brain re-evaluation. The model choice from a year ago is probably stale. Verify against the current local-LLM landscape before assuming.
- One workflow at a time. Each ships, lives in production for seven days, then the next gets wired.
- What we don’t resurrect. The dormant control plane unless it serves a need n8n itself can’t. The original five-workflow list as canonical. The assumption that the agent needs to be smart enough to handle the whole system — the substrate is what makes the system smart.
The lesson that generalizes
If you have an old AI agent design that didn’t ship — or shipped half-finished and went dormant — you have two options when the time comes to revisit it.
Option one: pull the original spec off the shelf and finish it. This is how you get Frankenstein. The spec was written for a world that doesn’t exist anymore. The parts you bolt on won’t fit the architecture you have now.
Option two: declare it dormant, then resurrect with current design intent. Re-derive what the agent is for given what you have now. Throw out assumptions that no longer hold. Wire to the current substrate from day one.
Lazarus over Frankenstein. Old AI agent specs should be re-derived, not resumed blindly.
Dormant AI specs expire faster than normal software specs, because the substrate underneath them moves faster too. If the architecture changed, the old agent spec is probably wrong by default.
LiveSeller Pro is built on a multi-agent operating model with bounded authority for each agent and durable state in a shared substrate.
Strike Once. List Everything. | livesellerpro.app