← All projects

Crypto market making · AI / LLM

Warren, an LLM copilot for the trading desk

A read-only LLM agent plugged into Slack, with access to the code, every service configuration and the metrics database, so the whole team can interrogate a complex platform in plain language.

Timeline
2024-present
Role
Co-founder & CTO
Stack
OpenClaw, LLM agents, Slack, time-series DB

Context

We founded a market-making firm, which meant everything had to be built from the ground up: the engine, the trading algorithms and the infrastructure around them. As co-founder and CTO I designed and wrote the whole system, and it now runs across more than thirty clients in production.

The platform is large. The diagram below shows the whole system and the people who operate it; this case study zooms in on Warren, the AI copilot the team uses to query everything (the AI agent brick highlighted below). The core engine and the observability stack have their own case studies.

trade metrics query control operate CEX Binance · OKX · … DEX Uniswap · … Fortuna services · VMs Fortuna service Fortuna service Fortuna service core engine Time-series database Grafana dashboards · alerts AI agent Warren ★ this page Admin platform configure · deploy Trading team operates the desk
The full platform and its actors. This page focuses on the highlighted AI agent, Warren.

The problem

The platform is large and intricate: many services, a configuration per client, and a metrics database that grows continuously. Getting an answer out of it was slow and uneven.

  • Answering a simple operational question often meant digging through code, configs and dashboards.
  • Most of the team is not technical: traders, client management and business development need information but cannot read code or write database queries.
  • Engineers became a bottleneck, constantly asked to pull numbers or explain how something works.
  • Knowledge was scattered across the codebase, the configurations and the metrics, with no single place to ask.

Objectives

  • Give the whole team self-serve access to the platform's knowledge, in plain language.
  • Answer across three kinds of knowledge at once: code, configurations and live metrics.
  • Take routine questions off the engineers' plate.
  • Stay safe by design: the assistant must inform, never act on the system.

My approach

I built Warren, an LLM agent (on top of OpenClaw) connected to our Slack. The team simply talks to it in a channel or a direct message. Warren is given read-only access to three sources, the codebase, the configuration of every service, and the metrics time-series database, and a set of tools to read and compute over them. It has no write path of any kind.

read-only ask & answer Codebase all services Service configs per client Metrics database time-series Warren LLM agent · OpenClaw read-only tools Slack Traders Client management & business dev Operations & others
Warren reads the code, the configs and the metrics, and talks to the whole team through Slack. Every arrow into Warren is read-only; there is no path back out to the system.

The technical solution

Warren is an agent built on OpenClaw: a tool-use loop where the model plans, calls tools, reads the results and answers. The tools are the three knowledge sources, exposed strictly for reading:

  • Code: it can search and read the codebase of every service, to explain algorithms and implementations.
  • Configurations: it can read the configuration of every running service, to explain what a given client or strategy is actually doing.
  • Metrics: it can query the time-series database and compute over it, to answer quantitative questions and build reports.

It lives where the team already works: a Slack bot anyone can mention in a channel or DM. The access model is deliberately one-way. Warren's credentials are scoped to read only, so it can search code, read configs and query metrics, but it cannot change a configuration, modify code, or place a trade. The assistant informs; it never acts. That boundary is what makes it safe to hand to the entire company rather than only to engineers.

What the team uses it for

Traders, client management, business development and operations all use Warren, each for their own questions.

Pull & compute, instantly

Ask for numbers in plain language, for example inventory and realized PnL for a client over the last seven days, and Warren queries the metrics and does the math.

Understand the system

Ask how an algorithm works, how a strategy behaves, or what a specific implementation does, without opening the repository.

Explain a configuration

Ask what a given client or service is set up to do; Warren reads the live config and explains it in words.

Investigate with the metrics

Dig into the data to understand a move, for example why a spread widened on a venue overnight.

Generate reports

Produce recurring summaries, such as a weekly performance recap or a per-client report, on demand.

Self-serve for non-engineers

Client management and BD get the data and answers they need themselves, instead of queuing behind an engineer.

Results

  • The whole desk, technical or not, gets answers in Slack, in plain language.
  • Engineers are freed from a steady stream of "can you pull this / can you explain that" requests.
  • Client management and business development self-serve data without SQL or code.
  • Safe by construction: read-only access means Warren can inform but never alter or act on the system.

Key takeaways

Putting a read-only agent over the code, the configurations and the metrics, right inside the tool the team already lives in, turned a complex platform into something anyone can interrogate in plain language, without giving up safety. The one-way access model is what made it possible to open it to the entire company.

Related case studies

Have a similar challenge? Get in touch →