Selected work

Customer-facing work for hard technical problems that need reusable answers.

I work where customers meet complex custody, wallet, and settlement problems: understand the issue, debug it in the real environment, fix it, and leave behind something the next person can reuse.

What I build

Systems I build at the customer edge.

AI · multi-agent

Multi-agent investigation platform

An orchestrator and around 20 focal agents that triage ambiguous technical questions, check trusted data sources, and hand back cited reports a reviewer can verify. In daily use across 9 product domains.

Tooling

Operational tooling for structured workflows

Command-line and workflow tooling for operational tasks where structure matters: transaction actions, policy and webhook checks, account reviews, and hardware-backed flows with clear operator guardrails.

Automation

Automation and reporting pipelines

Recurring customer reporting, rebuilt as production workflows: metrics from trusted data stores, branded PDFs, model-written summaries, reusable templates, and delivery scheduled automatically between cycles.

Debugging

Exchange and settlement debugging

Tracing issues across wallet, exchange, and settlement flows: asset mapping, failed transfers, webhook callbacks, and off-exchange settlement behavior across major exchange and settlement venues.

Environment

Constrained, security-sensitive environments

Troubleshooting offline and restricted workspaces: approval flows, policy behavior, connectivity constraints, device state, restricted access, and careful reversible changes with a clear trail.

Security context

Working inside high-stakes, restricted environments.

Some of my work happens at the edge of deliberately constrained environments: offline and cold workspaces, hardware-backed key operations, allowlist and policy controls, and restricted customer setups where shortcuts are not acceptable. The customers are high-value institutions, so the job is to understand the flow, debug from observable state, and propose steps a security team can approve without weakening the model.

Field notes

Incidents that became systems.

Throughput under load

A signing flow under load, and the work that would not clear

Problem: A high-volume customer was running a production workflow that stalled under burst load. The failure looked intermittent, retries sometimes helped, and the visible health checks did not explain why the backlog kept growing.
What I found: I treated it as a distributed-systems timing problem: the same state looked different depending on the observation point, so the dashboards did not tell the whole story. Reconstructing the order of events across stages exposed a race between steps that no single component revealed.
Fix: I handed the customer a mitigation they could run themselves: safe steps inside their own environment, each with an expected observable result, plus a clear split between immediate recovery and longer-term product follow-up.
Outcome: The workflow recovered and worked through its backlog. The case also became a reusable diagnostic path for high-throughput backlog issues: which signals to read first, how to spot stalled stages, and how to package findings into customer-safe actions.

On-chain decoding

The contract that reverted: reading the bytes to find a one-address mistake

Problem: A customer transaction kept reverting on chain, and the error gave no clear reason why the call was failing.
What I found: Decoding the function selector, arguments, and error shape narrowed the failure to an address-type mismatch: the call expected deployed contract code but received a plain wallet address.
Fix: Showed the customer the exact field to change, validated the corrected call in a safe simulation path, and wrote the explanation up as steps they could execute without guessing.
Outcome: An opaque smart-contract error became a precise integration fix, and the decode pattern became reusable for future contract-support cases.

Constrained integration

When a local recovery workflow meets a provider mismatch

Problem: A local recovery workflow failed in a restricted environment because the customer-required provider did not match the integration assumptions available in the setup.
What I found: The mismatch was structural: the provider interface, response shape, and authentication path did not line up with what the workflow could use locally.
Fix: Mapped the mismatch, gave working provider alternatives, and separated what the customer could change immediately from what needed product support.
Outcome: The case produced clearer guidance for constrained environments and sharper product requests for provider compatibility, without asking the customer to weaken their setup.

The common thread

Customers, hard infrastructure, and the systems between them.

The work starts with the customer's actual failure mode, then moves toward a fix that survives the current ticket. Sometimes that is a CLI workflow, sometimes an automation, sometimes a short product note with the right reproduction.

That is the loop I want to run inside a Forward Deployed, Solutions, Sales Engineering, or AI PM seat: customer context, technical depth, and fixes that keep working after the ticket is closed.

Get in touch

Let's talk.

Hiring for a role where customer-facing engineering meets AI systems? Building AI workflows for a technical GTM or product team? Same answer:

Email me Schedule a call Résumé page ATS résumé (PDF) LinkedIn