Positioning

Why polybot, not n8n.

If you squint, any system that chains an LLM call to an API looks like an "agent". The distinction that actually matters in production is whether the platform understands your domain. polybot does. n8n does not — and that's not a knock on n8n; 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.

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

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.