Comparison

polybot vs n8n: why trading needs a domain agent

n8n is a great workflow automation platform. It is the wrong shape for autonomous trading. Here's the precise technical reason, with examples.

Published Apr 17, 2026

This one comes up a lot: “Can I build what polybot does on n8n?” You can get close to demos. You can’t get close to production. This guide explains why, without strawmanning either tool.

What n8n is excellent at

n8n is a node-based workflow automation platform. It shines on:

• Connecting SaaS products — Stripe → Slack, Shopify → Airtable, webhooks → DBs.
• One-shot transformations — take a CSV, enrich it, upload.
• Scheduled jobs with human-readable branching.
• Non-engineers shipping automation without asking a developer.

For that class of problem, n8n is the right tool. If that’s what you’re doing, stop reading this and go use n8n.

Where the n8n shape breaks

Trading is not a workflow. It has four properties that make the node-chain abstraction fight you:

1. State is fundamental, not incidental

A workflow node has inputs and outputs. A trade has a lifecycle — submitted, working, partially filled, cancelled, filled, settled. Positions accumulate. P&L is computed against a fluctuating mark. You can shoehorn this into n8n with a database node + several branches per state, but you’re now maintaining a state machine by hand in YAML. That’s a category mistake: state is the domain, not plumbing around the domain.

2. Risk is a global invariant

“Don’t exceed 2% daily drawdown across all strategies and venues” is not a node. It’s a predicate that must hold regardless of which workflow is running. In polybot, the risk service is a single process every strategy signals through. In n8n, you’d need each workflow to import shared logic — and you have no way to enforce at the platform level that a contributor hasn’t bypassed it.

3. Execution is async, partial, and retried

An order can ack immediately, fill in pieces over seconds, get partially cancelled by the venue, get replaced. A naïve retry on a “place_order” HTTP node creates duplicate orders. A correct retry requires idempotency keys, reconciliation, and cancel-on-timeout — none of which are primitives in n8n, but all of which are primitives in polybot’s executor.

4. Venues have deep semantics

Polymarket is on-chain: EIP-712 signed orders, gas-paying cancels, oracle resolution with dispute windows. Kalshi is centralised: HMAC-signed REST, CFTC regulation, per-event resolution. You can put these behind HTTP nodes in n8n, but the result is a pile of per-venue workflows with no shared invariants. In polybot, they’re behind a BaseVenue protocol with explicit leak points (cancel_cost, latency_class) — the abstraction acknowledges what it can’t hide.

The agent dimension

The best n8n vs polybot argument is this: n8n now has LLM nodes. Claude node, OpenAI node, tool-calling. Doesn’t that cover the “agent” use case?

No, and here’s why.

In an n8n workflow with an LLM node, the LLM is a step — it runs, produces output, the next node consumes it. The workflow is in control. To let the LLM actually act on the domain (query markets, place trades), you wire its tool calls into HTTP nodes. You’ve now built a bespoke agent harness per workflow.

polybot’s MCP server inverts this. The agent is the principal. It connects to polybot over MCP, discovers 25+ typed tools, calls them in whatever order its reasoning produces, gets gated by the platform’s invariants (shadow mode, approval, caps). You don’t wire up a harness; you point Claude Desktop at polybot and it works. Because MCP is a protocol, any compliant client connects the same way. Because tools are typed, the agent can’t pass nonsense.

The difference is structural: n8n makes the LLM a step in the operator’s workflow; polybot makes the platform a tool for the agent’s workflow. Both are valid, but only one is what “agent core” means in practice.

Where polybot is the wrong tool

To be honest: polybot is specialised software for prediction-market trading. It is the wrong tool if you want:

• Generic business process automation.
• SaaS integration flows.
• Non-technical users building workflows visually.
• Trading something other than prediction markets (you’d need to write venue connectors).

If you’re doing those, use n8n or similar. If you’re building an agent system for a specific domain and want to understand the shape of what that looks like, polybot is the open-source example to read.

A concrete example

Take “buy YES on a market when my Perplexity agent says the probability is > 0.7 and the market price is < 0.6, with size scaled by confidence, but never more than 3% of my daily risk budget, with an approval gate.”

In n8n

You build: a trigger, a scheduled Perplexity call per market, a condition node, a database lookup for current positions, a size-calculation node, a risk-check node (that you have to maintain across every such workflow), a place-order HTTP node, an approval-prompt node, a retry-on-failure node, a fill-reconciliation workflow running in parallel, and a P&L-update workflow on a schedule.

Every workflow you write has to implement risk correctly. The 47th one forgets. You lose money.

In polybot

You enable the ai_model strategy with --plugin perplexity, configure --min-edge 0.1 --min-confidence 0.7 --kelly-fraction 0.25, and run in shadow for a month. Risk is enforced by the platform. P&L reconciliation is automatic. Approval gates for live trades are built into the MCP path.

That’s the difference: n8n is a workflow engine, polybot is a domain.

The summary

• n8n: right tool for workflow automation; wrong shape for stateful, risk-constrained, real-time execution.
• polybot: right tool for prediction-market trading with AI agents; wrong tool for generic integrations.

Pick the shape that matches your problem. For trading on Polymarket, Kalshi, and similar — polybot is the shape.