Agentic analytics · prediction marketsv1 · design

Agents that read the rules, research the question, and tell you when not to trade.

Agentic research and trade-recommendation platform for prediction markets. Kalshi first, venue-agnostic by design.

agents in the pipeline
3
possible answers, incl. abstain
4
venues, one interface
2
orders placed, ever
0
Illustrative · analyst → strategist
Will BTC close above $100k on Sep 30?
kalshi
40%60%80%t−14dnow
Market
62%
last trade
Model
71%
± 6%
Edge
+9%
above band
YES
size
2.5% of risk budget
entry
≤ 64¢
exit
78¢ or resolution
invalidation
daily close < $92k
Rules, verbatim: “…settles YES if the BRTI reference rate at 5:00 PM ET is strictly greater than $100,000.00.” 2 sources cited.
How it works

Three agents, one structured answer.

Every run is a background job with hard caps. Every output is structured and stored before the UI ever sees it.

01
Scanner
cost-efficient

Find markets worth attention across all open markets

scheduled; delayed for free tier, fresh for paid tiers

Signals
  • price vs base rate
  • thin liquidity or wide spread
  • mutually exclusive outcomes summing well over 1.0
  • same event priced differently across venues
  • high volume near resolution
02
Analyst
frontier

Form an independent probability for one market

on demand, or automatically for paid watchlists

Steps
  1. 1.read resolution rules literally
  2. 2.pull order book and price history
  3. 3.research the underlying question with a search tool
  4. 4.estimate probability with a confidence band
  5. 5.compare to market price and state the edge
03
Strategist

Turn an analyst result into a recommendation

Kelly-derived sizing, capped

Every recommendation carries
  • position
  • size_guidance
  • entry_price
  • exit_conditions
  • invalidation
  • explanation
  • Every run has hard caps on tool calls, tokens, and wall time
  • Every run is a background job, never inside a request handler
  • Every output is structured and stored before any UI renders it
  • Web research must cite sources; model recall is not evidence
  • Resolution rules are quoted verbatim in output, with the agent's reading of edge cases
Positions

Four answers. Two of them are “don’t.”

Abstaining is a first-class output and the abstain rate is published, never hidden. A model that only ever says YES or NO is guessing.

YES

Model probability sits above the market price by more than the confidence band. Entry, exit, and invalidation stated.

NO

The mirror case: the market is over-pricing the outcome. Same structure, opposite side.

ABSTAIN

Fairly priced, or too uncertain to call. Reported as a real answer and counted in the public abstain rate.

WAIT

Conditional entry with a stated trigger price. The thesis holds; the price doesn’t, yet.

Structural boundary

Analysis and recommendation only. No execution.

Users act on recommendations themselves. The app deep-links to the market on the venue. The provider interface excludes execution methods entirely so the boundary is structural, not a config flag.

In scope
  • Agentic scan of all open markets on a schedule, producing a ranked shortlist
  • Agentic deep analysis of a single market on demand
  • Trade recommendation per market: side, size, entry, exit, invalidation, or abstain
  • Plain-language explanation of every recommendation
  • Logged recommendations with resolution tracking and public calibration stats
Never in v1
  • Live trading account management of any kind
  • Placing, modifying, or cancelling orders on behalf of users
  • Holding user exchange API keys or wallet keys
  • Portfolio sync from exchange accounts
MarketProvider interfaceread-only
  • listMarkets(filter)
  • getMarket(id)
  • getOrderBook(id)
  • getHistory(id, range)
  • getEvents(filter)
  • getResolution(id)
  • placeOrder(...)
  • cancelOrder(...)
  • getBalance()

One MarketProvider interface, one normalized market model, one adapter per venue. Nothing outside the adapter may import venue-specific types.

Track record

Scored in public, before the first user.

Credibility and marketing; built before the first user. Every recommendation is logged at the price it was made, then graded on resolution.

Brier score over time

Calibration, not vibes. A proper scoring rule that punishes confident misses.

abstain rate

How often the system declined to call it. Published because it’s the honest number.

hypothetical P&L by position type and venue

What a unit stake at the recommended price would have returned, split by side and venue.

Logged per recommendation
  • market_id
  • venue
  • ts
  • market_price_at_rec
  • model_probability
  • position
  • tier_that_produced_it
  • model_ids_used
Added on resolution
  • outcome
  • brier_contribution
  • hypothetical_pnl_at_rec_price
Venues

Kalshi first. Venue-agnostic by design.

One normalized market model. Nothing outside an adapter may import venue-specific types, so the second venue is an adapter, not a rewrite.

kalshipriority 1

REST v2 plus WebSocket; RSA-signed auth for authenticated endpoints

series -> event -> market hierarchy; prices in cents

polymarketpriority 2

Gamma API for metadata, CLOB API for prices

outcome tokens priced in USDC; first target for cross-venue checks

Tiers

Free to browse. Credits to dig.

Metered by credits so per-action cost can be tuned without changing the product. The scanner and track record are shared computation and cheap to serve to everyone.

Free$0
  • browse and search all markets
  • delayed scanner shortlist
  • small monthly credit grant for deep analyses
  • public track record
StandardTBD
  • daily fresh scanner
  • meaningful monthly credit grant
  • watchlists
  • resolution alerts
  • private history
EliteTBD
  • real-time scanner
  • cross-venue arbitrage feed
  • auto-analysis on watchlist changes
  • API access
  • larger credit grant

Payments: stablecoins only. No custody of funds or keys on our side in v1. Auth via clerk.

Inside the system

The admin dashboard tracks milestones, open decisions, risks, and every spec document in one place.