Skip to content
← Home

AI systems

Production AI workflows for teams that sell and operate complex products.

I use PM judgment to understand the workflow first, then build the automation with n8n, code, data sources, and LLM steps. The goal is simple: make recurring work reliable enough for a team to depend on.

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
Express · pdf-lib · JSZip · workflow tooling

PDF report merger

A small tool that merges customer PDF reports with two shared report templates. Drop in a batch of customer reports and the templates, then download a ZIP with one complete deliverable per customer.

For a batch of 39 customer PDFs, the tool returns 39 merged deliverables without re-uploading the templates each time. It solved a real workflow problem without adding a headless browser dependency.

  • 39 reports in one batch
  • two reusable templates
  • ZIP output
  • no headless browser
System pattern

The architecture I keep coming back to.

Start with a vague business question. Route it to narrow agents or workflow branches. Pull from trusted sources. Produce a reviewable answer or deliverable. Feed the useful pattern back into the playbook.

trbt · agent run tracestep 01 / 08

Illustrative reconstruction using representative data. Not live customer data.

Input + orchestrator
  • INPUT
    /investigate
    Engineer input
  • ORCH
    main-orchestrator
    Triage · synthesize
Knowledge
  • KB
    Knowledge Base
    Playbooks · queries
Focal agents
  • AGENT
    balance-agent
    Balances · positions
  • AGENT
    tx-latency
    TX status · timing
  • AGENT
    blockchain-explorer
    On-chain verify
  • AGENT
    logs-investigator
    Log traces
Data sources
  • DATA
    Data store
    Core records
  • DATA
    Log platform
    Logs · traces
  • DATA
    Blockchain RPCs
    Multi-chain checks
  • DATA
    Data warehouse
    Trends · aggregates
Outputs
  • OUT
    Cited report
    Root cause · evidence
  • LEARN
    tech-lead
    Learning · KB updates
01
node · routeInvestigate · input
Engineer pastes a complex customer question into an agentic IDE. The orchestrator activates and prepares to triage.
Agentic IDE
step log
  • graph.invoke ▸ run started
  • checkpoint ▸ thread state saved
  • route ▸ intent = investigate
respond · reportcited deliverable
Root cause identifiedhuman-reviewed before send

The transaction was signed and broadcast cleanly, but it sat below the network fee floor during a congestion window [3], so it stayed pending instead of confirming [1]. A fee-bumped rebroadcast cleared it, and the same pattern had clustered in earlier high-fee windows [4].

Evidence
  • [1]Data store · Transaction marked submitted, with no confirmation height recorded.
  • [2]Log platform · Signing and broadcast both succeeded, with no error in the pipeline.
  • [3]Blockchain RPC · Transaction visible in the mempool at a low fee, not yet mined.
  • [4]Data warehouse · The same pending pattern clustered in prior high-fee windows.
✓ Two or more independent sources✓ Root cause is specific✓ No conflicting evidence

Drafted for the engineer to review before any customer reply. The agent never messages the customer on its own.
Live demo · runs in your browser

Try the operator workspace yourself.

This is how I would answer a realistic customer-facing question inside a working canvas. Pick a question or type your own, choose which public sources to search, and run it. The assistant only speaks from public Fireblocks documentation, every claim carries a citation, and the run trace stays visible so a person can check the work before it ever reaches a customer.

trbt · live operator workspace
Sources to search
Answer ready. 2 sources cited.
Question

A prospect’s desk wants to trade on a connected exchange without moving assets out of custody. Where do they start?

Assistantcited: [1] [2]

Assets stay in the customer’s own custody and are mirrored to the connected exchange as collateral, so a desk can trade without pre-funding the exchange. [1] The flow defines clear roles for the custodian, the exchange, and the trader, with collateral locked and released as positions open and close. [1]

Trades execute against the mirrored collateral and settle later, which limits how much is exposed on the exchange at any one time. [1] Fireblocks is API-first: a REST API plus official SDKs let teams automate vaults, transactions, and policy from their own stack. [2]

Evidence

Browser-only prototype. Retrieval runs client-side over a small set of public Fireblocks documentation — no backend, no API keys, nothing leaves this page. Illustrative, not a live product surface.

Prefer to just ask in plain words? Ask Citepilot → a chat that answers Fireblocks SDK questions from public docs, with a citation on every claim.

Operating principles

What makes the workflows useful.

Start with the business problem

The useful work starts before the workflow canvas. I map who is blocked, what decision they need to make, and what a good output would let them do faster.

Route before generation

The model's first job is not to answer, it is to route: decide which source, query, or specialist workflow should run first. Agents that try to cover everything get vague.

Evidence before polish

Outputs are useful only when a person can check where they came from. The systems I trust produce cited answers, show the path, and keep a human in the loop for anything customer-facing.

Measure the boring wins

The best AI workflows remove repetitive work. What matters is reporting time, investigation time, handoff quality, and prep quality.

Where it maps to GTM

The same pattern can help revenue teams.

The same thinking maps to account research, pre-meeting briefs, RFP response drafts, technical discovery notes, competitor research, enrichment workflows, and knowledge bases that improve after every customer conversation.

That is the AI work I want to do next. I care about results a team can measure, and about staying close to the actual technical problem so the system earns its place instead of becoming another chatbot.

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