AI · multi-agent
Multi-agent investigation platform
An orchestrator and 18 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.
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.
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.
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.
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.
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.