Inspiration
I work in AI safety, in mechanistic interpretability. We understand something as complex as a transformer with a few simple probes: knock a component out and see what breaks, trace a behavior to the circuit that causes it, look for the smallest intervention that changes the output. The US benefits system is another machine nobody can see inside — thousands of pages of interacting rules. So I pointed the same probes at it. Peira is Greek for "probe." It's the root of the word empirical.
What it does
Peira maps what a Colorado family actually keeps at every income level, and pins every benefit cliff to the program that causes it. Then it gives you the tools to investigate your own map:
- Knock a program out and see which other programs move.
- Trace a cliff to the exact eligibility rule that flips.
- Overlay a changed life — marriage, a new baby, different hours — on top of today's.
- Search an income × childcare grid for safe regions.
- Find the smallest legal rule change that would make a cliff disappear, and watch it heal on screen.
Why WebMCP
Cliff charts already exist. PolicyEngine's CliffWatch and the Atlanta Fed's CLIFF suite are good ones. But a chart can't answer "why?" or "what if?". A chatbot can answer, but it can't compute anything trustworthy or show its work.
WebMCP puts the tools inside the page, next to the chart. The agent runs the probes. The person edits the household card, clicks the cliffs, scrubs the map, and decides what matters. Every action lands in one shared log — human moves in green, agent moves in purple.
That's the thing that wasn't possible before. The person can't drive a 600MB rules engine. The agent doesn't know this family's life. Together, "is my raise actually worth it?" gets a real answer — and the person learns why, instead of taking a chatbot's word for it.
There's no retrieval anywhere in Peira. The thousands a family loses at the wrong income isn't written in any document — it only exists once you run the law. Every answer here is a computed experiment on a real rules engine, not a search result.
How I built it
The engine is policyengine-us, the open-source model of actual US tax and benefit law.
A FastAPI backend on Render runs it. A React frontend on Netlify draws the map. Eleven
WebMCP tools connect the two, registered through document.modelContext and validated
with zod.
Two rules shaped every tool. First: the agent can't see the canvas, so every reply is about a kilobyte of findings — cliffs, recovery points, safe regions — never raw data dumps. The screen keeps the detail; the reply says what it means. Second: the agent can't be trusted with the engine, so policy edits pass through a server-side whitelist with bounds. A parameter path the agent makes up never reaches the engine.
Challenges I ran into
Getting the balance between person and agent right. I didn't want a chatbot that hands out answers — today's benefits tools already do that, and the person learns nothing. So everything the agent can do, a person can do by hand, and each side can see what the other did. The person is a participant, not a spectator.
Accomplishments that I'm proud of
WebMCP is pull-only: the page can never tell the agent "the human just changed something." So every tool reply includes a digest of what the person did since the agent's last call — card edits, cliff clicks, probes run by hand. Change the daycare cost yourself, ask "what do you make of what I just did?", and the agent answers from the digest. It saw you.
What I learned
The programs are secretly wired together. Remove TANF and this family silently loses $5,139 of SNAP, through a rule called broad-based categorical eligibility. No chart shows that dependency. I found it the same way you find circuits in a transformer: by knocking something out and watching what else broke.
What I learned
The programs are secretly wired together. Remove TANF and this family silently loses $5,139 of SNAP, through a rule called broad-based categorical eligibility. No chart shows that dependency. I found it the same way you find circuits in a transformer: by knocking something out and watching what else broke.
What's next for Peira
More states. Colorado is the verified wedge, and the instrument is built state-parameterized — other states with full childcare-subsidy models are next.
Built With
- fastapi
- netlify
- policyengine
- python
- react
- render
- typescript
- vite
- webmcp
Log in or sign up for Devpost to join the conversation.