I am able to parallelize investigation threads, reduce manual toil, and focus on applying human judgement where it matters most.
Before Axiom, an alert might show unexpected traffic from an IP, a region, an endpoint, or a fingerprint. It used to kick off an hour or more of manual work: log into Cloudflare, inspect charts, copy IP ranges into external lookup tools, and decide by hand whether the pattern was harmless or something to block.
Today, Jared Silver, Brilliant's VP of Engineering, uses a set of Claude skills with context on Brilliant's Axiom datasets, its Cloudflare Logpush data, its WAF rules, and past investigations like this one. He gives it the alert context and asks it to fan out across traffic patterns, fingerprints, user agents, IP ranges, and historical comparisons.
Who they are
Brilliant helps more than 10 million learners build problem-solving skills through interactive lessons across math, science, computer science, and AI. Its product philosophy is that people learn best by doing, trying, failing, and trying again; Koji, its AI tutor, extends that philosophy into AI. Jared describes Koji as an antidote to AI experiences that simply hand over the answer: the goal is to keep learners in the productive middle, challenged enough to grow, supported enough to keep trying.
With Koji, machine data sits close to the heart of the product. Every prompt, token, latency spike, error, and cost signal can affect both the learner experience and the business model behind it. At Brilliant's scale, small changes have consequences in unexpected places: a prompt tweak can change latency, a client release can change traffic patterns, a GraphQL hotspot can affect product experience.
Before Axiom: fractured tools and manual investigation
When Brilliant's CTO, Kevin, joined the company, one of the first things he noticed was how fractured the observability stack had become. Logs, metrics, errors, and traces were spread across Datadog, New Relic, Better Stack, and a separate error-monitoring tool. At times, the team did not have real log aggregation where it needed it, so engineers would SSH into boxes and tail logs directly.
Without centralized log aggregation, some incidents required engineers to SSH into individual boxes and tail logs to figure out what was going on.
The old workflow had all the usual indignities: find the right box, identify the one misbehaving, and hope the right data was being logged in the first place.
Cost created another bad incentive. If every additional event made the bill feel less predictable, the team had to ask whether it should log less. Then an incident would arrive, and the missing data would be exactly what the team needed. That was the failure mode Brilliant wanted to escape: paying for observability while still rationing the data that would make observability useful.
Why Brilliant chose Axiom
The team evaluated its options, including the newer observability and tracing features of the error-monitoring tool already in its stack, and adopted Axiom because performance, cost, and implementation effort worked together in a way the previous stack had not.
Ultimately, we ended up on Axiom because the combination of performance, cost, and ease of implementation just blew everything else out of the water.
Two quieter criteria mattered too. The team wanted standard structured logging across the stack rather than vendor lock-in, and it wanted tooling engineers would actually love: observability usually comes out when something has already gone wrong, and a tool that makes those moments easier, sometimes even delightful, pays for itself in developer happiness.
Jared says one of the best signs that a developer tool is working is whether the team reaches for it without being forced.
People were clamoring to use it. This makes my job so much easier. I can actually tell what is going on in this part of the stack that I previously looked at as a black box.
How they rolled it out
Brilliant took a structured-logging approach across every layer of the stack, which meant existing work on logs, traces, and spans carried over rather than being thrown away.
One early focus was the GraphQL API layer. It touches the rest of the product: clients query it, the Django monolith serves data into it, and performance changes there can expose problems across the stack. Instrumenting it first gave the team early insight into hotspots and told them what to instrument next. Other layers followed.
The instrumentation carries house knowledge an outside tool wouldn't have. In Brilliant's Cloudflare data, for example, the team learned to filter on eyeball traffic so a single Next.js page load doesn't count as seventeen requests for its assets. Context like that lives in a set of skills that Claude uses to query Axiom, so every investigation starts with it already loaded.
Fast enough for engineers and agents
Axiom's performance mattered before Brilliant leaned into agent workflows. Once Claude and Codex entered the investigation loop, it mattered even more.
Axiom stays fast by doing less work per question, then scaling out the work that remains. Event data is stored in compressed, column-oriented blocks. APL narrows the time range, filters, and fields needed for the answer. Axiom can skip irrelevant data and read relevant fields rather than dragging every log line through a general-purpose search system.
For a human, that keeps investigation interactive. For an AI agent, it keeps the machine data layer from becoming the bottleneck.
Tools like Axiom that make us as humans more efficient and effective make agents more efficient and effective by orders of magnitude.
That is the architectural reason the MCP workflow works. An agent can issue multiple queries, compare time windows, inspect dimensions, and test hypotheses much faster than a human can type them. But if the underlying machine data system is slow, expensive, or hard to query, the agent loop stalls.
With Axiom, Brilliant can let agents explore without turning every investigation into a cost or latency problem.
Life after: Agents run the first pass
The traffic investigation that opens this story now happens in a span of a few minutes: a set of tasks that previously would have been six different things Jared had to do himself, taking an hour or more. When the pattern is malicious, minutes matter. When it is harmless, the team avoids burning attention on false urgency.
The same shift changed on-call. An engineer paged at night can immediately begin an agent-assisted first pass: with Axiom and MCP, an agent pulls the logs, compares time windows, and tests the obvious hypotheses while the human supplies context and judgment. The same exploratory instinct catches what no monitor is watching for. Exploring the data in Axiom with Claude, the team asked why so many requests were coming from a years-old client. It turned out to be an access-control exploit that served paid content for free. With Axiom's help, the issue was patched and the fix validated within minutes.
The pattern extends past incidents. For a risky rollout, an engineer or product person can ask an agent to watch the relevant Axiom data and flag Slack if anything looks strange for the next few hours. Not every operational question deserves permanent infrastructure. Some deserve a smart loop for the next six hours. Durable monitors, which the team also creates in natural language, cover the rest.
And the audience keeps widening. Axiom is Brilliant's primary tool for monitoring token throughput, time to first token, and the other performance signals behind Koji. Learning designers check how a prompt tweak changed latency and cost. Finance grounds its projections, including how much Brilliant can give away for free, in Axiom's out-of-the-box LLM spend and performance dashboards rather than vendor estimates. Jared says it has given the finance team superpowers. Across a typical week, that adds up to many hours saved across the team, and on the hardest incidents, far more.
Incidents that could have taken several days to fully resolve in the past can now be resolved in minutes.
Machine data everyone can use
In short, Axiom makes Brilliant's machine data useful enough that more people use it. When more people use it, the product gets better.
If people want to use the observability tooling at their disposal, we're going to make a better product. We're going to make better software and everybody is going to be happier all around.