How does the NickAI prediction market AI agent work?

The NickAI prediction-market AI agent is a four-layer system: an inputs layer pulling Elo ratings, real-time news, and Polymarket order book data; a multi-LLM consensus decision layer running Claude + GPT + Gemini + an open-weight model in parallel with per-regime weighting; a policy layer that enforces hardcoded per-trade, per-market, per-team, and throughput caps; and a non-custodial Polymarket execution adapter via py-clob-client. Every trade emits a full decision trace for audit.

Is the NickAI prediction-market agent custodial?

No. The NickAI prediction-market AI agent is non-custodial by design. Funds remain in the user's own wallet (on-chain mode via Polymarket on Polygon) or in their own account at a regulated venue (Polymarket US or Kalshi via trade-only API keys). The agent signs trade transactions through the user's wallet or places orders via a permission-scoped API key: it cannot withdraw funds at any point.

What LLMs does the NickAI prediction market agent use?

The agent runs multi-LLM consensus across Claude (Anthropic), GPT (OpenAI), Gemini (Google), and an open-weight model (Llama 3.3 or DeepSeek V3 depending on the regime). The same prompt runs in parallel; each model emits a structured decision; outputs are combined with per-regime weighting derived from a rolling calibration window. In internal benchmarks, the weighted consensus is directionally more accurate than any single frontier model on prediction-market outcomes.

What safety bounds does the NickAI agent enforce?

Five hardcoded policy rules enforced in code, not in the LLM prompt. Per-trade size cap rejects orders above a USD limit. Per-market position cap rejects if the resulting position would exceed the per-market limit. Per-team or per-entity aggregate cap limits exposure across related markets. Throughput cap rejects more than N orders per rolling 60-minute window: catches runaway loops. A kill-switch endpoint disables order placement instantly. Caps bound the worst-case loss regardless of model outputs.

How does the NickAI agent connect to Polymarket?

Via py-clob-client, Polymarket's open-source Python library for the central limit order book. The agent signs orders with the user's wallet; Polymarket validates and executes on-chain (Polygon, for the international venue). The agent's wallet should hold only the operational trading balance, never the user's long-term holdings, so a wallet compromise is bounded to the operational amount. For Polymarket US, the same pattern uses the regulated venue's REST API with trade-only API keys.

How does the agent improve over time?

Three compounding feedback loops. First, per-model calibration, every closed trade updates the rolling accuracy score for each model in its regime; the next decision uses updated weights. Second, per-regime weighting, models that consistently underperform in specific contexts get lower weight there. Third, audit-driven prompt iteration, weekly review of model-disagreement cases feeds back into prompt structure. The agent gets measurably better between major releases through these loops, not just through model upgrades.

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	Component	Responsibility
1	Inputs	Elo ratings + news + Polymarket order book
2	Multi-LLM consensus	Claude + GPT + Gemini + open-weight decide
3	Policy layer	Per-trade, per-market, per-window caps
4	Polymarket adapter	py-clob-client signs and submits orders
5	Audit log	Decision trace per trade, append-only

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:

Per-trade size cap. Reject orders above a USD limit set by the user.
Per-market position cap. Reject if the resulting position would exceed the per-market limit.
Per-team aggregate cap. Sum of positions across all related markets cannot exceed the per-entity limit.
Throughput cap. Maximum N orders per rolling 60 minutes. Catches runaway loops.
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 illustrative trade from input to fill (hypothetical match, illustrative numbers):

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.
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%.
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.
Execution. py-clob-client signs the order with the user's wallet, submits to Polymarket CLOB. Fill at 59.8%.
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.