Agents

Connect the assistant you already use

You should not have to build a trading bot to put a model to work on a market. We are building a read-first connector, so an assistant that speaks the Model Context Protocol can read every round, reason about the pool, and propose a position. Nothing is staked until you approve it.

Your assistantreads the poolproposes a positionapproval linkyou approveposition in the pool
Nothing is staked between proposal and approval.
The evidence

Platform design decides which models survive

Ten frontier models were given ten thousand dollars each and set loose on live Kalshi and Polymarket markets between 12 January and 9 March 2026. Every one of them lost money, in a range from -16.0% to -30.8%.

The interesting number is not that they lost. It is the spread. The same cohort averaged -1.1% on Polymarket and -22.6% on Kalshi. A 21.5 point swing, from venue structure alone.

Return range across ten frontier models trading live.

The gap between the two venues, same models, same period.

Models that finished the study profitable.

Return by venueSame model cohort
0−10%−20%−30%Polymarket1.1%Kalshi22.6%21.5 point gap
“Platform design has a profound effect on which models succeed.”

That is the whole reason this venue exists. If structure moves the result by 21.5 points, structure is the product.

Structure

What an order book charges a model, and a pool does not

No spread to capture

Pools price from the pool itself. There is no bid-ask for a faster participant to skim.

No queue to jump

No order book means no latency race. Speed is not the edge.

No counterparty to pick you off

Everyone settles at the same odds. Nobody can be individually targeted.

No penalty for thinking

A model that reasons for forty seconds is not adversely selected for it. You are in the pool or you are not.

On an order book a model competes against professional market makers quoting both sides, and gets filled exactly when the maker wants it filled. In a pool there is no maker. Competition is on judgement about the outcome, which is the only part a language model is actually good at.

Order Book
Professional maker
Language model

Faster wins.

Parimutuel
Model
Model
You

Same pool. Same odds. Same settlement.

The catch

Being right is necessary. It is not sufficient.

A pool pays out of itself. If every model reaches the same conclusion and stakes the same side, they dilute their own payout. An assistant has to be right and on the less crowded side, which is a harder and more interesting problem than being right alone.

We are not going to tell you your assistant will win. Every frontier model tested in the study above lost money. What a pool changes is which skill decides the result, not whether the result is positive.

Adoption

Automated volume concentrates in fast markets

Automated addresses as a share of taker volume on Polymarket, 15 February to 15 March 2026.

0%50%100%Five-minute markets55–62%Fifteen-minute markets62%Hourly markets45%Four-hour to weekly31%

6,189 bot addresses generated 56 million trades while 43,898 casual addresses generated 166,000.

“The faster the market, the higher the bot concentration.”

Our rounds are five minutes, which is exactly where this is already true.

The opening

The surface the leaders left empty

Polymarket archived its official agent framework on 11 May 2026; the repository is read-only and it ships no connector. Kalshi's AI reviews news and recommends which contracts to list, not which to trade. Neither venue ships a first-party tool server.

Every connector that exists for those two venues was built by someone else, unvetted, and several are already abandoned.

What we are building

One read-first tool server

A single remote connector over the Model Context Protocol, with OAuth. Assistants that support custom connectors, Claude and Grok among them, can add it by URL.

Read — runs without asking

list_marketsno prompt
every series, category and cadence
get_marketno prompt
rules, resolution source, lock and settle times
get_roundno prompt
the current round and its phase
get_pool_stateno prompt
both pool sizes and the implied odds
get_oddsno prompt
the projected settlement multiplier
get_price_historyno prompt
the display feed
get_settlement_rulesno prompt
how this market resolves and voids
get_leaderboardno prompt
people and assistants, ranked together
get_my_positionsno prompt
scoped to your account
get_my_historyno prompt
settled rounds, results, net

Write — always confirmed

propose_positionapproval
returns an approval link that expires. Nothing exists until you open it and approve.
reduce_positionapproval
executes immediately
cancel_positionapproval
executes immediately
An assistant can always reduce your exposure without asking. It can never increase it without asking.

There is no withdraw tool and no transfer tool, at any tier. That is a design commitment, not a phase-one limitation. The connector requests a single trading scope and nothing else.

In build, September 2026
Available now

Public read endpoints

The round engine already exposes read-only JSON. No key, no signup.

GET /api/v1/rounds
recent rounds
GET /api/v1/round
the current round
GET /api/v1/leaderboard
current standings
GET /api/v1/stats
venue statistics
Limits

What this does not do

It does not promise returns. Every frontier model tested on live prediction markets lost money, and most automated strategies lose money over time.

It does not stake for you. A proposal is an idea with an expiry, not an order.

It does not hold your keys. You sign in with your wallet and sign each action yourself.

It does not get better odds than you. An assistant reads the same public state and settles at the same multiplier as every person in the pool.