← Back
Payment Ops · AI Agents

Payment Ops: Three AI Agents

...walk into a bar, but there's no one there. A payment processing company asked for three AI use cases as a technical exercise after the first interview round. I delivered all three; the silence afterward counted as an answer on its own. Their loss - the architecture docs and the working n8n agent are here instead, free.

Built as a take-home technical exercise. The work outlived the interview.

The three agents
01
Sentiment-Based SEPA Monitor
n8n · WORKING AGENT
02
Crypto Gateway Health Monitor
CONCEPT · ROUTING
03
Semantic Error Translator
CONCEPT · VECTOR SEARCH

What makes this interesting

Back in the days of my naive youth, when I worked support trenches, I could tell it was Monday just by looking at a bunch of emails with the subject "WHERE IS MY MONEY" or some variation of it. That lesson (trauma) taught me that sometimes the real signal comes from humans rather than dashboards - an angry email lands before any monitoring graph admits something's wrong. The interesting part wasn't proposing "add AI here" - it was figuring out where a model actually earns its keep without becoming the thing that approves a wire transfer unsupervised, or the thing that replies to those angry emails in the same tone. Every agent below ends in a human decision, not an automated one. That wasn't a nice-to-have, it was the whole design constraint, and it's the difference between something a team will actually run in production and a slide someone nods at once.

Gemini made this in 27 seconds. Three times. Each one worse than the previous one. I spent 2 hours making this image.

What I expanded it into

Only one of the three got built end-to-end, on purpose. The Sentiment-Based SEPA Monitor has the clearest signal and the smallest blast radius if it's wrong - tightening a monitoring threshold is reversible. The other two stayed concepts: the Crypto Gateway Health Monitor and the Semantic Error Translator are real problems, but doing them properly needs live provider relationships and a fix library that doesn't exist yet outside this write-up. That's the right order regardless - start with the piece that proves value on real data, and let the data earn the rest of the build.

Read whichever one interests you. SEPA has the full build. The other two have the reasoning without the implementation - which is sometimes the more honest version of "done."