Skip to content
← Back to portfolio

TRBT · AI workflow case study

A case study on complex crypto investigations, repeatable workflows, and answers backed by evidence.

How it works

Bring TRBT a goal, and it returns a clear answer with the evidence behind it.

Three steps sit between the question and the report.

  1. 01 · Intake

    A goal comes in

    An investigation request arrives in plain language. The orchestrator triages it, auto-derives the missing context, and decides which specialists the job needs.

  2. 02 · Fan out

    Specialists work in parallel

    A handful of focal agents run at once, each with its own proven queries and bounded permissions. Findings are cross-checked against each other before anything is trusted.

  3. 03 · Answer

    A report you can act on

    The orchestrator merges everything into a structured report: root cause, an evidence table, and a resolution. The pattern is captured so the next run starts smarter.

Production to date
Daily users
7
Specialist agents
~20
Product domains
9
Phases per run
5

Used daily by a 7-person support team. Every run feeds the learning loop, so the playbooks keep improving with use.

The problem

Complex investigations depended on a few people.

The hardest crypto investigations needed product memory, data knowledge, log queries, on-chain checks, and judgment. A few senior people knew where to look. That knowledge was fast, but it did not scale. TRBT, Tickets Resolved Before Tea, started as a way to capture that expertise in a repeatable workflow.

The approach

An orchestrator plus specialists, not one giant model.

TRBT does not ask one model to know everything. One orchestrator reads the context, routes the request, and synthesizes the result. Around twenty specialized focal agents each own a narrow piece of the product, with curated queries, validated patterns, and bounded permissions. The orchestrator picks the right handful for a request, and the specialists run in parallel.

The architecture

What moves when an investigation runs.

The diagram below shows the system shape. Hit Auto and watch an investigation flow through input, context extraction, domain classification, routing, primary agents, conditional agents, the quality gate, the report, and the learn cycle.

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.

Knowledge sources

Built from real workflows, not generic wiki text.

Primary sources are hand-curated: trusted data patterns, proven queries, error corrections, and playbooks written from real investigations. The learn command extracts patterns from completed work and updates the playbooks. Secondary sources like SDK docs and public API references add context when needed.

The journey

5 phases per investigation.

Triage, Context, Investigate, Synthesize, Learn. Triage is fast and routes the request across product domains. Context fills in missing customer, case, asset, and chain details from trusted sources. Investigation runs the parallel specialists. Synthesize merges findings into a structured report with root cause, evidence table, and resolution. Learn captures the pattern for next time.

Outcomes

What changed.

A 7-person support team uses TRBT daily on live tickets. Patterns that used to be tribal knowledge are now playbooks. New engineers ramp faster. Senior engineers do less rote work and more of the hard work that needs them. The system gets better with use; every investigation feeds the learn loop.

What's transferable

This pattern works far outside one team.

Sales intelligence: account briefs, prospect research, RFP responses. Product analysis: feature requests clustered by domain, customer pain mapped to roadmap. Security: log triage and anomaly explanation. The TRBT shape (orchestrator, specialist agents, curated knowledge, learning loop) is a reusable building block, not a single product.

Want to see this pattern applied to your problem?

Let's talk →