How I built an AI agent that goes from sports research to an onchain position, with human approval by default (architecture + lessons)

I’ve spent the last few months building an agent that researches a sports matchup, compares its read to the market odds, and can place a position onchain. Here’s how it’s put together and what I learned. Links are in the comments, per the sub rules. The loop Intent: the user asks in plain English, like “Who has the edge in tonight’s game?” Research: the agent pulls stats, injuries, recent form and news. Compare: it reads the market price as an implied probability. A YES token at 0.62 means the market thinks 62%. Then it compares that to its own estimate. Propose: it writes a short case: its estimate, the market’s, why they differ, and a suggested position. Approve: by default, the user approves or rejects. Users can switch to autonomous mode. Execute: the agent signs from its own wallet and places the position onchain. Settle: the market resolves and pays out in USDC. Stack Reasoning: Claude Wallet: Circle Agent Wallets, so the agent has its own wallet Markets: YES and NO outcome tokens backed by USDC Settlement: Arc Design decisions that mattered Separate thinking from acting. The model outputs a structured proposal. A separate step checks it before anything gets signed: the market is open, the size is within limits, the balance covers it. Put guardrails outside the model. Position limits and spend caps live in code, not in the prompt. A prompt is a suggestion, not a guardrail. Approval on by default. Most people won’t hand an agent real money on day one. Letting them watch it be right a few times is what earns autonomy. Make the agent show its work. Proposals land better when the market’s number sits next to the agent’s, with one line on why they differ. Count the cost of thinking. Every research run costs model and data calls, and most never turn into a position. Price for the research, not just the trade. What’s still hard Stale information: injury news five minutes before kickoff can flip the whole read. Calibration: when the agent says 60%, it should be right about 60% of the time. Proving that takes a lot of resolved markets. Liquidity: a thin market can make a good read not worth acting on. If you’re building an agent that touches money Start with the proposal format and the validation layer, not the prompt. Once the agent can only act through a narrow, checked interface, you can improve the reasoning without worrying about what it might do.I’ve spent the last few months building an agent that researches a sports matchup, compares its read to the market odds, and can place a position onchain. Here’s how it’s put together and what I learned. Links are in the comments, per the sub rules. The loop Intent: the user asks in plain English, like “Who has the edge in tonight’s game?” Research: the agent pulls stats, injuries, recent form and news. Compare: it reads the market price as an implied probability. A YES token at 0.62 means the market thinks 62%. Then it compares that to its own estimate. Propose: it writes a short case: its estimate, the market’s, why they differ, and a suggested position. Approve: by default, the user approves or rejects. Users can switch to autonomous mode. Execute: the agent signs from its own wallet and places the position onchain. Settle: the market resolves and pays out in USDC. Stack Reasoning: Claude Wallet: Circle Agent Wallets, so the agent has its own wallet Markets: YES and NO outcome tokens backed by USDC Settlement: Arc Design decisions that mattered Separate thinking from acting. The model outputs a structured proposal. A separate step checks it before anything gets signed: the market is open, the size is within limits, the balance covers it. Put guardrails outside the model. Position limits and spend caps live in code, not in the prompt. A prompt is a suggestion, not a guardrail. Approval on by default. Most people won’t hand an agent real money on day one. Letting them watch it be right a few times is what earns autonomy. Make the agent show its work. Proposals land better when the market’s number sits next to the agent’s, with one line on why they differ. Count the cost of thinking. Every research run costs model and data calls, and most never turn into a position. Price for the research, not just the trade. What’s still hard Stale information: injury news five minutes before kickoff can flip the whole read. Calibration: when the agent says 60%, it should be right about 60% of the time. Proving that takes a lot of resolved markets. Liquidity: a thin market can make a good read not worth acting on. If you’re building an agent that touches money Start with the proposal format and the validation layer, not the prompt. Once the agent can only act through a narrow, checked interface, you can improve the reasoning without worrying about what it might do. Disclosure: I’m the founder of Mantua, which this comes from. The demo is in the first comment. Happy to go deeper on any part of the architecture.