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 18 specialist 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.

Observability

Production monitoring and measurement

Daily Datadog work at Fireblocks: dashboards and alerts for live services, reading production signals before customers feel them. The same discipline applied to AI systems: time to root cause, report quality, and whether teams keep using the tool.

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.

Incident 01 · Throughput under loadRESOLVED

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.

Incident 02 · On-chain decodingRESOLVED

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. It is also the pattern the EVM Transaction Troubleshooter now automates end to end.

Incident 03 · Constrained integrationRESOLVED

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.

Production workflows

Built from zero to production.

n8n · SQL data warehouse · Google Drive · LLM summaries

Recurring customer reporting workflow

A recurring customer reporting process became a production n8n workflow. It pulls customer metrics from the data warehouse, builds branded HTML reports with charts and LLM-written summaries, renders them as PDFs, and delivers each file to the right Google Drive folder.

Reporting period dates calculate from the current date, so the next run needs no manual configuration. The workflow keeps the output consistent across customers and removes the repetitive build step from the team.

0 to production in n8n
dynamic date logic
charts and branded PDFs
Google Drive delivery

n8n · data warehouse · JavaScript · QuickChart

Customer reporting automation

Killed a 30-minute manual report and built a 4-second pipeline in its place. 42 sequential SQL queries became 2 bulk operations, a 99% runtime reduction.

A director-requested initiative, now used across 50+ customer-facing reports.

42 queries → 2 bulk ops
99% runtime reduction
50+ reports
director-requested

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. Two of those fixes grew into the flagships on this site: TRBT and the EVM Transaction Troubleshooter.

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.

Outside support and AI systems I also shoot photo and video, and run my own footage through an AI media pipeline: see the visual work.

Get in touch

Let's talk.

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