Harness cluster: Skills, hooks, orchestration · Lightweight harness · Knowledge Work Engine
n8n vs my Cursor and Obsidian system
n8n is workflow automation: triggers, webhooks, schedules, API nodes, deterministic pipelines. I used it for years. I have not touched n8n since last year.
Today, n8n-shaped work on petralian.com runs as AI-coded microservices: small services in Docker on the VPS, plus Cloudflare Workers at the edge for webhooks and light routing. My Cursor + Obsidian + hooks stack is still the judgment harness: files as SSOT, agent sessions for ad-hoc work, hooks for mechanical reminders, Bridge for handoff.
They overlap in the word "automation" and diverge in what should be deterministic versus what needs review.
Who it is for: Anyone deciding whether to add n8n, ship small microservices, extend Cursor hooks, or combine layers — especially when integrations are scheduled but deliverables still need human review.
What you will learn: how I replaced n8n, when microservices win, when Cursor wins, how the three layers hand off, and Path A without any of the full setup.
The confusion
Teams buy n8n to "automate AI." Teams wire Cursor hooks to "automate process." Both can call APIs. Both can move text.
The mistake is using one tool for the other's core job.
- Workflow tools and microservices excel when the path is known in advance and errors should retry the same step.
- Cursor excels when the path is negotiated in files and the output needs review before it ships.
When judgment is required every run, a workflow graph — or a pile of microservices with no SSOT — becomes an expensive chatbot with extra boxes.
Screenshot: n8n-io/n8n README — Petralian (2026)
What I replaced n8n with
On petralian.com, the jobs that used to live in n8n now look like this:
| Old n8n job | What runs now |
|---|---|
| Webhook receiver (publish, alerts) | Docker service on the VPS + nginx proxy; Workers at the edge where latency matters |
| Scheduled pulls / digests | Vercel cron, Workers, or container cron — small code the agent helped write and I can read |
| Moving structured records between systems | Typed scripts or services with env-based secrets, not visual node graphs |
| Threshold alerts | Same pattern: deterministic code, logs I own |
Example: the weekly digest on Brevo free and the publish webhook (docker-compose.webhook.yml in the repo) are microservice-shaped, not "ask Cursor every Monday."
I did not swap n8n for a bigger n8n. I swapped it for small services I can grep — mostly scaffolded with AI, then reviewed and deployed like any other code.
When workflow tools (n8n class) still win
| Job | Why a canvas tool helps |
|---|---|
| You want visual ops for non-coders | Graph is the UI |
| Dozens of SaaS connectors out of the box | Faster than coding each adapter |
| Team already runs n8n in prod | Sunk cost and runbooks exist |
| Prototype before you know the path | Drag nodes until the flow stabilizes |
If you are solo, comfortable directing AI to ship a 200-line webhook, and you have not opened n8n in a year, you may be past this layer. I was.
When AI-coded microservices win
| Job | Why microservices beat n8n for me |
|---|---|
| Fixed webhook or schedule | One repo file, one deploy, one log stream |
| Secrets and auth you must audit | Code review beats opaque node configs |
| Edge routing (Workers) | Cold start and geography without maintaining n8n |
| You already live in git + Docker | Same deploy muscle as the app |
| Agent wrote v1, you own v2 | Refactor in Cursor instead of rewiring twelve nodes |
When AI-coded microservices make sense: the integration is stable, repeatable, and small — and you would rather read code than click boxes. Cursor is how I author those services. It is not how I run them every hour.
When they do not make sense: the flow changes weekly, needs a visual ops map for a team, or spans twenty SaaS systems you do not want to maintain as code. That is still n8n or enterprise iPaaS territory.
Diagram: Agent architecture illustration — Petralian (2026)
When Cursor + Obsidian wins
| Job | Why Cursor stack |
|---|---|
| Drafts and edits with voice rules | Files + writing guide |
| Multi-file reasoning | Agent reads repo and vault |
| Ad-hoc analysis | Prompt changes per session |
| Governed publish gates | Folder = gate (draft vs ready) |
| Session continuity | Bridge, open loops, memory loop |
| Parallel independent deliverables | Subagents with human merge |
Cursor is knowledge work execution. Hooks are guardrails, not a replacement for Zapier.
Example implementation — how I run it
Microservice-shaped work (replaces n8n for me): scheduled pulls, webhook receivers, moving structured records between systems, alerting when a metric crosses a threshold. Built with agent help, deployed on petralian.com infrastructure, reviewed like app code.
Cursor-shaped work (daily): blogging pipeline, Vouch app changes, client briefs, harness tuning, anything in Customize modes.
Handoff pattern: microservices land structured captures in an inbox file, database row, or webhook payload. Cursor session consumes Bridge/inbox, produces reviewed markdown or code. The service does not get write access to publish folders.
Hooks (sessionStart, afterAgentResponse) enforce close-out on the Cursor side (cloud vs local hooks). Docker does not replace those; it feeds them.
This is the same spirit as a lightweight harness: small deterministic pieces at the edges, judgment in the middle — without a visual workflow canvas I stopped opening.
Comparison at a glance
| Dimension | Workflow tool (n8n class) | AI-coded microservices | Cursor + Obsidian + hooks |
|---|---|---|---|
| Trigger | Schedule, webhook, event | Same — code-defined | Human goal + Bridge |
| Logic | Fixed graph | Fixed code you review | Agent + rules |
| State | Nodes, DB, sheets | Env, logs, small DB | Markdown SSOT |
| Failure mode | Retry node | Redeploy / fix service | Context blurs; fix harness |
| Best output | Records, notifications | Records, notifications | Reviewed documents, code |
| Ops cost | Host n8n, maintain creds | Host containers/Workers | Vault habit + rules |
| My 2026 default | Retired | Yes for plumbing | Yes for judgment |
What not to automate in microservices or n8n
- Final publish to live site without human gate
- Client deliverable approval
- Model escalation policy (use SSOT + human picker)
- Anything requiring Grok-style synthesis across messy notes without review
Limitations
Workflow graphs rot when APIs change. Microservices rot when you skip tests and env docs. Cursor harness rots when Bridge close-out slips. Running two layers without a handoff contract duplicates state.
Microservices do not read your vault semantics. Cursor does not replace enterprise iPaaS for hundreds of connectors unless you enjoy maintaining them as hobbies.
Path A: no microservices yet
- Scheduled need: calendar reminder → manual export CSV → Bridge note.
- Webhook need: form → email yourself → process in Friday Cursor block.
Add a small service (or n8n) when the same integration runs more than twice a week and errors must retry without you.
Path A: no Cursor yet
Unlikely for this blog's reader — but if you only have automation: add one markdown Bridge per initiative. Never let workflows write final prose directly to stakeholders.
What to try this week
Draw one workflow you repeat (newsletter ingest, lead alert, report pull). Mark each step deterministic or judgment. If judgment steps exceed two, stop at the service feeding Bridge; finish in Cursor. If every step is deterministic and stable, ask the agent to scaffold a microservice v1 — then decide if you still need n8n.
Related reading
Get practical posts on enterprise AI and transformation. Only useful updates, sent as a weekly digest.
One practical digest each week. Unsubscribe anytime.
