My background is in payments infrastructure, regulated banking operations, risk, and platform strategy. I use AI and working prototypes to test decisions earlier, explain difficult systems, and learn quickly in new domains.
A visual operating environment for agentic work.
I built this animated office to explore how persistent roles, explicit approvals, bounded autonomy, and verification could make an AI organization easier to manage.
Enter the office →A payment simulation that makes the differences among three rails visible.
The simulation follows ACH, Fedwire, and debit-card payments across institutions, ledgers, returns, and settlement. It shows the operational consequences that sit behind a familiar customer action.
Follow the money →
A cash-optimization agent with deterministic financial logic.
Liquidity Assistant explores how an AI agent can make a recommendation while keeping the underlying financial decision explainable and providing fallback behavior when information is incomplete.
An early test of cash-flow data as a credit-risk signal.
The current proof uses transaction-derived features, synthetic profiles, XGBoost, and SHAP explanations to test whether cash-flow behavior could provide an earlier, more explainable signal. 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 began with a management question: what would a leader need to see before trusting a group of agents with meaningful work? I built the pixel office as an operating surface, giving a person a way to grasp the scale of the work agents were doing on their behalf, understand each agent’s mission, and see where the work stood. That led to an environment in which every agent has a role, location, workload, and visible relationship to the rest of the organization.
As soon as the work became visible, gaps in the operating model became visible too. A conversation needed to become a durable plan. Delegation needed handoff packets, ownership, dependencies, file boundaries, and stop conditions. Autonomy needed budgets, concurrency limits, permissions, and explicit reasons for stopping. Review needed evidence from the work itself rather than the agent’s confidence.
Those discoveries pushed the prototype from a visual metaphor into a working study of agentic management. The current system keeps plans and decisions outside the model, assembles context only when a role acts, and records enough of each run for a person to inspect or intervene.
The prototype is still evolving. Each iteration turns an abstract question about the future of work into an organizational choice that can be tested, challenged, and improved.
Payment Rails in Motion compares how ACH, Fedwire, and debit-card payments move through institutions and ledgers. The goal is not to make the rails look identical. It is to show where batching, reversibility, finality, returns, and settlement create different product and operational obligations.
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. Failure paths, compensating entries, and audit history became part of the product experience rather than background implementation detail.
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. A working model gives teams something concrete to challenge, reveals constraints before commitments harden, and helps us make better decisions together.
Across Capital One, Plaid, Meta, Amazon, and Microsoft, my work has included payments infrastructure, platform product management, product strategy, risk, governance, operational resilience, and adoption.
That experience shapes how I approach newer AI-enabled products: make the important decisions visible, examine how the system behaves under pressure, and add controls where the consequences require them.
