I work in payments and regulated platforms. These are projects I’ve built to understand unfamiliar systems, try product ideas, and explore what AI makes possible.
A team of AI agents planning and building software inside a digital office.
I give the team a goal, review its plan, and let workers carry out the assignments. I’m exploring what the office needs to show so I can follow their progress, understand why work stopped, and decide when to intervene.
Enter the office →Follow ACH, Fedwire, and debit payments through simulated banks and ledgers.
I built this to learn what happens after a customer presses “Send.” Each service has its own state and records. The inspector shows how a payment changes balances, moves toward settlement, and unwinds when it is returned.
Follow the money →
An agent that plans around upcoming bills and surplus cash. Done well, this could help customers avoid transfers that leave them short for upcoming bills and earn more interest on money they don’t need immediately.
The agent forecasts cash needs and recommends how to allocate money between checking and savings. Financial calculations follow fixed rules, and the recommendation explains its assumptions. I’m testing how it should respond when the available information is incomplete.
Testing how cash-flow patterns assess credit risk.
I used synthetic profiles to test a model built from transaction patterns. XGBoost produces the scores, and SHAP shows which features contribute to them. The experiment asks whether cash-flow behavior could reveal risk earlier and make the score easier to explain. It is not a production underwriting model.
The project starts with a practical management problem: once AI agents can plan and delegate work, how does a person see who owns what, where work has stopped, and whether a result is ready to accept?
The first version makes roles, work, approvals, budgets, permissions, and verification visible in one environment.
Animated Agent Office started with a management problem: if several AI agents were working at once, how would a person know what each one was doing and when to step in? I began with a pixel office because it gave that work a physical shape. Each agent had a role, a place, an assignment, and a visible status.
Making the work visible exposed a harder problem. Seeing activity is different from understanding it. The system needed to show how a goal became a plan, who owned each part, where work was blocked, and what evidence justified calling it complete.
The office now preserves the plan, assigns every task, and shows when work is waiting, blocked, under review, or complete. Each agent receives only the context needed for its assignment. A result is accepted only when the system can connect it to evidence from the work.
I use the office to run real software projects and watch where my own understanding breaks down. If I cannot tell who owns a task, why an agent stopped, or whether the result is actually complete, that becomes the next product problem. The interface grows from those moments.
Payment Rails in Motion compares how ACH, Fedwire, and debit-card payments move through institutions and ledgers. Each rail creates different obligations: batching changes when a payment moves, finality determines whether it can be reversed, and returns can extend its lifecycle beyond settlement.
Payment Rails in Motion began with an onboarding problem: how do you make sense of the US financial ecosystem? When a customer hits “Send,” a single confirmation screen compresses banks, networks, ledger entries, settlement windows, and exceptions into one moment, even though each rail creates different obligations for the product and its operators. That machinery is opaque to product managers learning the domain, and I wanted a simpler way to make it legible.
I started by modeling the participants as separate components: a payment gateway, bank ledger, receiving bank, and simulated Federal Reserve. I then made the movement of state among them visible. That exposed decisions a static diagram could easily hide: which institution owns the authoritative state, when funds become available, which instructions can be retried, and which ledger writes must remain immutable and idempotent.
Adding ACH, Fedwire, and debit required the system to behave according to each rail. Wire finality changes how errors must be handled. ACH returns extend the lifecycle beyond the original posting. Debit separates authorization from clearing and settlement. The interface now shows failure paths, compensating entries, and audit history alongside the payment’s progress.
The prototype is a controlled simulation, not a production payment processor. Its value is making infrastructure concrete enough for a team to inspect the assumptions, product obligations, and operational consequences before those decisions harden.
I use prototypes to turn strategic questions into something a team can inspect, challenge, and learn from. A working system exposes assumptions that can stay hidden in a deck: what the product needs to know, where judgment enters, how failure appears, and which controls matter.
I build early enough that the evidence can still change the decision.
Across Capital One, Plaid, Meta, Amazon, and Microsoft, my work has included payments infrastructure, platform product management, and product strategy.
The change with AI-enabled products is that we can make important decisions more visible, see firsthand how the system behaves, and add controls where they are needed.
