How the NickAI Prediction Market AI Agent Works (2026)

The architecture in one diagram

Five layers, in series, each with a defined responsibility. The order matters — skipping any layer either weakens decisions or removes safety bounds.

Layer 1 — Inputs

The agent ingests three real-time feeds, each with a different cadence and a different role.

• Elo ratings. Refreshed weekly. Used as the base probability for any sports outcome. For the 2026 World Cup, current Elos place France highest among contenders, with Spain and Brazil close behind.
• News. Filtered to the markets the user has configured. Squad injuries, starting-XI changes, tactical announcements, manager pressure. An LLM filter classifies relevance and severity before the news reaches the decision layer.
• Polymarket order book. Polled every 30 seconds during active match windows, every 5 minutes off-hours. The current bid-ask sets the trade triggers — the agent does not act when the model edge is smaller than the spread.

Layer 2 — Multi-LLM consensus

The decision layer. The same prompt — including the layered inputs from Layer 1 — runs in parallel across Claude (Anthropic), GPT (OpenAI), Gemini (Google), and an open-weight model (Llama 3.3 or DeepSeek V3 depending on regime). Each model emits a structured decision: {side, confidence, target_size, reasoning}.

The combination is not a simple vote. Each model carries a per-regime weight derived from a rolling calibration window — models that have been correct on similar past decisions get more weight; models that have drifted lose weight. The output is a probability distribution over outcomes plus a confidence number; the agent acts only when the confidence exceeds a strategy-specific threshold.

Layer 3 — Policy layer

The safety surface. Hardcoded caps in code, not in the prompt. Five rules, every deployment:

1. Per-trade size cap. Reject orders above a USD limit set by the user.
2. Per-market position cap. Reject if the resulting position would exceed the per-market limit.
3. Per-team aggregate cap. Sum of positions across all related markets cannot exceed the per-entity limit.
4. Throughput cap. Maximum N orders per rolling 60 minutes. Catches runaway loops.
5. Kill switch. A single endpoint that disables placement instantly.

The caps run before the Polymarket adapter ever sees the order. Even if every model hallucinates the same way and the consensus produces a bad decision, the policy layer bounds the loss.

Layer 4 — Polymarket adapter

The execution layer. py-clob-client is the standard Polymarket library; the adapter wraps it. Order signing uses the user's wallet — non-custodial throughout. The wallet running the agent should hold only the operational trading balance, never the user's long-term holdings; a wallet compromise then bounds the loss to the operational amount.

For users on Polymarket US (CFTC-regulated venue, in beta), the same adapter pattern uses the Polymarket US REST API with scoped trade-only credentials.

Layer 5 — Audit log

Every decision, input, model vote, policy decision, order placement, fill, and realised PnL — append-only to durable storage. The log answers three questions: why did the agent act, was the action approved by policy, and what happened. Without the log, debugging a losing trade is impossible; with it, every loss is informative.

A worked example — group-stage match

Walking through one trade from input to fill:

1. Input. Elo gives Argentina vs Mexico in a hypothetical group-stage match a 56% Argentina win probability. Polymarket prices Argentina at 60%. News: no major injuries; weather neutral.
2. Consensus. Claude and GPT both see Argentina as slightly over-priced (model 56% vs market 60% = 4-point gap). Gemini sees the gap as smaller (2 points). Open-weight model agrees with Claude/GPT. Weighted consensus: sell Argentina at 60%, expected fair value 56%.
3. Policy. Proposed trade size $500 on the SELL side. Under per-trade cap ($1,000), under per-market position cap ($2,000), throughput 1/min (under 5/min cap). Approved.
4. Execution. py-clob-client signs the order with the user's wallet, submits to Polymarket CLOB. Fill at 59.8%.
5. Audit log. Records inputs, all four model votes with reasoning, policy decision, fill price, order ID. Position open.

How the agent updates over time

Three feedback loops compound the model's edge:

• Per-model calibration. Every closed trade updates the rolling accuracy score for each model in that regime. The next decision uses the updated weights.
• Per-regime weighting. Models that consistently underperform in specific contexts (e.g., Gemini on protocol-governance markets) get lower weight in those contexts. Adapts to model drift between major updates.
• Audit-driven prompt iteration. Weekly review of disagreement cases (where the models split) feeds back into prompt structure and input weighting. The agent gets better between major releases.

What the agent will not do

Three things by design, explicit boundaries:

• Never withdraw funds. The Polymarket adapter only signs trade transactions; withdrawal permissions are not held by the agent.
• Never exceed user-set caps. Policy layer rejects in code; prompt instructions are not the safety mechanism.
• Never trade outside configured markets. The agent's market list is in its config, not in the LLM prompt. Adding markets requires explicit user action.

Where to start using it

The NickAI prediction-market AI agent is the production version of this architecture. Setup connects either a Polymarket wallet (on-chain mode) or a Kalshi / Polymarket US trade-only API key (CEX mode), then configures the market list and policy caps. The full agent runs against the user's own funds non-custodially with the methodology above.

For the deep-dive into the multi-LLM consensus methodology that drives Layer 2, see AI Predictions for the 2026 World Cup: Methodology and Live Consensus. For the comparison of Polymarket vs Kalshi as execution venues, see Kalshi vs Polymarket for the 2026 World Cup.