Positioning

Why polybot, not n8n — or a bespoke bot.

In 2026, letting an LLM agent trade prediction markets is the obvious move — and handing it an API key with a prompt is the dangerous one. If you squint, any system that chains an LLM call to an API looks like an "agent". The distinctions that actually matter in production are whether the platform understands your domain and whether it's safe by default. polybot is both. n8n and a hand-rolled per-venue bot are neither — and that's not a knock on them; it's a feature of what each one is for.

What n8n is good at

n8n is a fantastic no-code workflow platform. It excels at connecting SaaS products — pull a Stripe event, transform the payload, drop it in Slack, update Airtable. Building those integrations as code is tedious; n8n makes them visual and shareable. For that class of problem, reach for n8n.

Where the abstraction breaks for trading

Autonomous trading is not a workflow. It's a control loop with hard domain constraints:

• State is fundamental, not incidental. Positions, orders, P&L, and risk exposure are the objects you reason about — not side effects of a workflow run.
• Risk is a global invariant. No single workflow node enforces "don't exceed 2% daily drawdown across all venues". That has to be the platform's job.
• Execution is async and partial. Orders get filled, partially filled, replaced, cancelled. A node-chain model of the world collapses here.
• Venues have real semantics. Polymarket is an on-chain CLOB with USDC collateral and EIP-712 orders. Kalshi is CFTC-regulated with per-event markets. You can't paper over that with HTTP nodes.

What polybot is, precisely

polybot is a Python-native agent runtime with four things n8n doesn't have and can't easily bolt on:

1. A domain model. Pydantic types for Market, Order, Position, Signal, PriceUpdate. Strategies return signals; the executor translates them to venue-specific orders.
2. An MCP server. 25+ typed tools so any MCP-compatible client (Claude Desktop, custom agents, other polybots) can query markets, analyze strategies, suggest improvements, and place approval-gated orders.
3. A plugin system for AI models. AIModelPlugin is a base class — Claude, GPT, Perplexity, and your custom model all fit behind the same interface, so strategies treat them as probability oracles, not vendors.
4. Risk and state as first-class infrastructure. Position caps, daily loss limits, exposure limits, shadow mode, approval workflow, full audit log — all enforced in the platform, not in each strategy.

Feature by feature

"But I could build this on n8n" — could you?

Probably, yes. You can also build a web framework on cron and a text editor on ed. The question is whether you want the six months of domain hardening — risk invariants, venue reconciliation, order lifecycle, analytics schemas, MCP tool definitions, approval gates — or whether you want to re-derive them from first principles.

"Or just a bespoke bot per venue?" — the honest alternative

For most teams the real alternative isn't n8n at all — it's writing a small script per venue: a Polymarket bot, a Kalshi bot, a fragile LLM prompt, and risk checks copy-pasted into each. That's a legitimate choice, and if you only ever trade one venue and never involve an agent, it may well be the simpler one — fewer dependencies, nothing to learn.

It stops scaling the moment you add a second venue, an agent, or a shared risk rule. Now you're maintaining N drifting scripts, re-deriving markets/orders/positions in each, and bolting risk onto every one. polybot earns its weight exactly there: multiple venues behind one BaseVenue, one risk model enforced platform-wide, and agents as first-class principals via MCP — not per-bot prompt glue. When a single-venue script is enough, use one. When it isn't, this is what you'd have had to build.

Who polybot is for

• Quants and traders who want a battle-tested multi-venue runtime without building exchange plumbing.
• Agent developers who want an MCP-native target for Claude, GPT, and custom agents.
• Engineering teams who need autonomous trading to be auditable, type-safe, and on-prem deployable.

FAQ

Should I just build a bespoke bot per venue?

If you only ever trade one venue and never involve an agent, a single-venue script can be simpler and lower-dependency — a legitimate choice. polybot earns its weight when you want multiple venues, agent access via MCP, or a shared risk model enforced once rather than copy-pasted into every bot. Past one venue, bespoke bots become N drifting scripts.

Can I build a trading bot on n8n?

You can orchestrate API calls, but you are responsible for every domain concept — markets, orders, positions, risk, venues, reconciliation. polybot ships those as first-class types with months of production hardening.

Is polybot just a wrapper around Polymarket?

No. polybot supports Polymarket, Kalshi (CFTC-regulated), Opinion, and Binance under a single risk and position model. The venue abstraction (BaseVenue) lets you add more without touching strategies.

Why is an MCP server a big deal?

MCP (Model Context Protocol) lets any compliant AI client — Claude Desktop, custom agents, IDE extensions — call typed tools on polybot. You get market analysis, strategy assessment, and gated execution as an agent capability, not a prompt-engineering project.

Is polybot production-ready?

It is beta (0.1.x), MIT-licensed, with a full test suite, type-checked strictly with mypy, and deployed in Docker. Risk controls — position caps, daily loss limits, shadow-first defaults — are built in rather than bolted on.