How An Agentic AI Bot Wins On Polymarket By Buying Below Fair Value

A small autonomous bot has made $70 on Polymarket without its builder placing a single manual trade, compounding at roughly $25 a week at zero marginal operating cost. The pattern it runs is not a gambling secret. It is a pricing discipline that accounts payable teams at any small firm can replicate directly.

The moment taker costs killed the first approach

Most people who try prediction markets start as takers. You see a price that looks mispriced, you want the position, you bet. It is fast, certain, and completely natural. It is also structurally expensive in ways that are easy to miss.

Every taker trade carries two costs that arrive before the outcome is known. There is the platform fee, which comes off every fill regardless of whether you win. Then there is slippage: you ask for a fill at 40 cents and get filled at 44, because market latency, a thin order book, or a moving price all push your actual execution away from the price you saw when you decided to act. You are 4 cents in the hole before the event resolves, and whatever edge you believed you had is already gone.

The builder ran the numbers on a series of early taker trades and found the pattern every time. The underlying predictions were often correct. The strategy still lost money. Fees plus slippage were eating the margin before any edge could compound. The conclusion was structural: you cannot fix taker costs by finding better predictions. You fix them by changing which side of the trade you occupy.

Flipping to the maker side means posting resting orders on the book rather than chasing prices. You set the price you are willing to pay and wait. When a seller arrives at your price, the fill happens. When one does not, the order sits there doing nothing. This sidesteps slippage entirely because you are not chasing, and it avoids the taker fee on platforms that price maker and taker activity differently. The catch is that resting at the wrong price is worse than not resting at all. You need to know what the right price actually is, which is where the real building began.

What 144,000 snapshots actually teach a model about fair value

The whole strategy rests on one number: the fair value price, meaning the builder's best estimate of the true probability of an outcome, independent of whatever the market currently shows. If a market says a particular event has a 55 percent probability and the builder's model says the honest probability is 51 percent, there is a potential edge, but only if the model's 51 is trustworthy.

Trustworthy fair value requires a lot of history. A small sample produces a number that looks precise and is not. The calibration gets tested against reality when markets resolve, and a small sample has too few resolutions to catch systematic bias in the estimate.

The builder collected 144,000 fair value snapshots across 2,000 resolved Polymarket markets, supplemented by 170 hours of live data accumulated over roughly seven days. With 2,000 resolved markets as ground truth, the model could compare what it would have calculated as fair value against what actually happened and tune the calculation until it consistently tracked reality. Adding more data stopped shifting the result. That stabilization is the practical test for whether a dataset is large enough.

The AI handled the data collection and calibration. The underlying math is simple, an expected value calculation weighted by historical outcomes, but doing it reliably across 144,000 data points and validating it against 2,000 known resolutions is work that belongs to a machine. A human analyst building the same calibration manually would spend weeks on what the model did in the background.

What the dataset taught the builder was not just that the fair value estimate was trustworthy. It also revealed the distribution of prices in the market relative to fair value, which was the input needed for the next calculation: how far below fair value does a price need to sit before acting on it is worth doing?

The number that unlocked the edge: why 4 cents, and not 3

The 4-cent threshold is not intuitive. It came from modeling the costs and the distribution of historical prices together.

Once you know your fair value, you need a discount large enough that positive expected value survives across all outcomes. If you buy at a 1-cent discount and the market resolves in your favor, you net a fraction of a cent after fees. If the market resolves against you, you lose the full amount. The edge needs to be wide enough that across many fills, the positive outcomes consistently outweigh the negative ones even accounting for costs.

The builder ran this calculation against the full historical dataset and found 4 cents was the inflection point. At 3 cents, the margin was too thin. Minor errors in the fair value estimate or any remaining cost friction could flip it negative. At 5 cents, the edge was robust but orders filled far less often, because prices rarely fell that far below fair value and stayed there long enough to generate consistent volume. Four cents was the minimum required to stay positive and the maximum that still generated enough fills to matter.

On a Bitcoin five-minute up-or-down market with a fair value of 0.51 for the up outcome, the bot sets its resting buy at 0.47. For the down outcome, it calculates 1 minus 0.51, which is 0.49, and subtracts another 4 cents to set a resting buy at 0.45. Both orders sit on the book simultaneously. As the fair value drifts based on incoming data, the bot updates both orders to reflect the current calculation. The symmetry is deliberate: both sides carry resting orders at the same discount from their respective fair values, so the system does not carry a directional view. The edge is present regardless of which way the market resolves.

The bot also uses caching to keep operating costs near zero. Rather than recalculating fair value from scratch on every tick, it stores recent results and refreshes only when conditions change enough to warrant it. The compute overhead of running the strategy is negligible compared to even the small weekly earnings it generates.

Going live: how impatient sellers became the profit source

Once the fair value model was calibrated and the 4-cent threshold was set, the strategy ran itself. The bot posts its resting orders and waits. Nothing happens until a seller decides they want out of their position at a price that meets the bot on the book.

This is where patient pricing becomes the mechanism, not a nicety. Taker strategies require you to be present and react. Maker strategies require you to be patient and let the deal come to you. The profit source in this system is not superior prediction. It is the discount that impatient sellers accept in exchange for immediate liquidity. A trader who panics during a volatile window, or who simply wants to exit a position quickly, hits the bid at whatever price is sitting there. The bot is always there at 0.47 or 0.45, willing to transact at a price that already includes the edge.

Because both the up side and the down side carry resting orders, the bot captures fills from whichever direction attracts the impatient seller. The outcome of the event is irrelevant to profitability. The only scenario where nothing is earned is the scenario where neither order fills, in which case nothing is lost either. Every actual fill is a positive-expected-value transaction by construction.

Higher volatility periods generate more impatient sellers and therefore more fills. Calmer periods generate fewer. The bot runs through both without any adjustment, because the 4-cent threshold handles both environments. It was calibrated across a historical dataset that included both kinds of periods.

$70 up, $25 a week, zero marginal cost: what passive really means here

At the time the original walkthrough was documented, the bot was up approximately $70 since going live and tracking toward roughly $25 per week in ongoing earnings. Those numbers are modest in absolute dollar terms.

The relevant comparison is not to a large trading operation. It is to the input cost. The marginal operating cost of this system after initial setup is zero. The model runs on existing API access. The scheduler is free. Caching keeps repeated lookups cheap. The human time required after deployment is essentially nothing. There is no ongoing labor cost, no per-trade maintenance fee, no subscription bill that accumulates into a meaningful number. The system runs in the background while the builder does other things.

That changes the framing entirely. The question is not whether $25 a week is a lot. The question is whether $25 a week against zero ongoing cost makes sense to run. It does, obviously. And the implication is that a collection of such background systems, each generating a small and consistent positive edge at near-zero marginal cost, can together produce real aggregate value over time. Twelve months of $25 a week is $1,300. The initial setup, calibration, and deployment probably took two to three weeks of focused work. That payback math is compelling for any background system.

The system also improves over time. As more markets resolve and more data accumulates, the fair value model can be retrained on a richer dataset. The initial 144,000 snapshots that powered the first version can grow, which may allow the threshold to be refined or the strategy to be extended to other market types. The hard work was done once. Improvement is incremental from there.

What an accounts payable team at a 10-person firm can steal from this

Strip away the prediction market context and the underlying discipline is: compute honest fair value from enough data to trust the number, refuse to transact unless the price offers a meaningful edge, and be patient enough to let the deal come to you. That is a general business principle, not a trading tactic.

A 10-person professional services firm processing a steady volume of vendor invoices, software renewals, and contractor bills is a taker in exactly the same way the early trading approach was. An invoice arrives, someone glances at it, and it gets paid. There is no systematic check against what the firm's own history says the same service should cost. There is no threshold below which a charge gets fast-tracked and above which it gets flagged. Every invoice is treated the same way, which is the equivalent of placing a market order at whatever price the market shows.

The three-step structure from the bot applies directly. First, build a fair value for every recurring cost from the firm's own invoice history. Two years of clean accounts payable data is enough to establish what each vendor, software seat, or service category should cost, including the normal range of variation. The midpoint of that range is your fair value. Second, set a threshold, the equivalent of the 4-cent spread. An invoice that arrives meaningfully below fair value gets routed for immediate approval and early payment to capture any discount the vendor offers. One that arrives meaningfully above fair value gets queued for human review before payment. One inside the normal band gets auto-approved without further scrutiny because the band was already calibrated to absorb typical variation. Third, let the logic run in the background and catch outliers automatically.

In illustrative terms, a firm with annual vendor spend of roughly $400,000 might find that 3 to 5 percent of invoices fall outside the expected range in one direction or the other. That translates to $12,000 to $20,000 in annual value either recovered from contested overcharges or captured through early-payment discounts. The setup work, roughly one week to clean and analyze historical invoice data and build the flagging logic, pays back within the first quarter. Marginal operating cost after that is near zero, identical in structure to the trading bot.

The AP team stops being a taker that pays whatever lands in the inbox. It becomes a patient system with a calibrated fair-value model, a tolerance band, and the discipline to act only at the edges. Impatient sellers on Polymarket become, in the AP context, vendors who accidentally underbill or who are testing whether the firm notices an overcharge. Both categories generate edge for the patient side. Madhuranjan Kumar builds systems like this for clients who want to stop leaving money in their own back-office operations.

The lesson holds across industries. Compute honest fair value from enough data to trust the number. Set a threshold that keeps every transaction worth doing. Be the patient one. The deals and the errors will find you.