Tripwire

• 

• 

• 

• 

The idea

Tripwire reads PayPal activity as one stream and, for each anomaly it finds, writes the grid that explains it.

The agent chooses the columns, grouping, filters and chart through tool calls against an AG Grid specification. A rules check validates every generated spec before it renders, and the run shows how many were rejected and rebuilt.

The stream carries 52 real PayPal object IDs across 101 rows.

---

The dashboard you needed was never the one you had

Every payments dashboard is built in advance. Someone decides which columns matter, which filters to offer, and what to group by. Then the thing that actually goes wrong is none of those.

Refunds spike on one plan, through one channel, on one day. Payouts to a single address keep failing. Four invoices quietly age past thirty days. Each of those needs a different view of the same data, and by the time you have built that view by hand, the money is gone.

You cannot pre-build a dashboard for a problem you have not had yet.

---

So the agent builds it

Tripwire reads Orders, Payouts, Invoicing and Disputes as one stream. When it finds something unusual, it does not just describe it — it writes the grid that shows it.

The agent chooses the columns, the grouping, the filters and the chart through tool calls against an AG Grid specification. Each finding on the board is a widget the model built for that specific problem.

Four findings from a recent scan:

• $2,117 held across 7 unclaimed payouts, all to one recipient address that is not registered with PayPal
• 78% of annual-plan captures refunded on the app channel, against a 2.7% baseline — a 28× spike
• 9 duplicate-transaction disputes on annual-plan in 7 days, where the normal rate is 0.03 a day
• $4,460 across 4 invoices now more than 30 days overdue

The second and third are the same underlying fault seen from two directions, and the agent says so.

---

Letting a model build UI, safely

A model writing a grid specification can write a broken one. So every generated spec passes a rules check before anything renders — valid columns, valid aggregations, no field that does not exist in the data.

The agent trail at the foot of the board shows the whole run: how many model requests, how many tool calls, how many widgets were built, and how many specs were rejected and rebuilt. That last number is the honest one. A model that never gets anything wrong is a model nobody is checking.

You can change what it built

Every widget is editable. The agent gives you a starting point for a problem you had not anticipated, not a verdict you have to accept.

It also knows when to do nothing

Click Scan the stream when nothing has changed and it tells you so, without spending a model call. An agent that burns tokens confirming yesterday's answer is an expensive way to learn that nothing happened.

---

What it is reading

The stream carries 52 real PayPal object IDs across 101 rows from the sandbox. The webhook listener is live and signature-verified, so new activity arrives in the stream as PayPal reports it.

Agent	Claude Sonnet 4.5 on Amazon Bedrock, with tools for reading the stream and writing grid specs
Grid	AG Grid Enterprise and AG Charts, with AG Studio used to design the shapes the agent generates
PayPal	Orders, Payouts, Invoicing and Disputes read into one stream; signed webhooks for each
Platform	AWS Lambda, DynamoDB, S3 and CloudFront

---

Built With

• ag-grid
• bedrock
• claude
• paypal
• sonnet