Traversal Raised $120M for Site Reliability Agents; the Model Was the Easy Part

Research

The item is one line. Traversal builds AI agents for site reliability engineering; it raised $120M co-led by Kleiner Perkins, Redpoint, and Khosla at a $1B valuation. Category, amount, three leads, one number.

What the agents read, what they are allowed to touch, and how often they are right are not in it. A valuation is not a demo.

I read the line twice and then did the only useful thing left: built the smallest version of the same idea on my own hardware and watched where it fell over.

My homelab has the shape of a small production stack — containers, a reverse proxy, a disk that fills up — at a scale where I can check every answer by hand. I am usually the one who broke it.

The design is deliberately thin. An alert arrives as a JSON file. The agent may request one read-only command at a time from a fixed list, and returns a diagnosis plus the command it wants next. I run it and paste the output back.

The model runs locally, on the box beside it. If the question is whether an agent can reason about an incident, I did not want a frontier model’s price or a vendor’s hidden prompt in the way. Local also keeps the transcript on my hardware, which is where an incident transcript belongs.

I scored the runs against a fault I already knew: a container that had been restarting since morning. I had fixed it myself earlier in the week, so the answer key was in my head — the cheapest evaluation set available, and the most biased one.

Setup

Two text files, a shell script, one alert. No framework, no API key, no orchestration.

triage/
  alerts/photos-restart.json
  tools.txt
  triage.md
  ask.sh

tools.txt is the entire permission model, and it fits on a sticky note:

docker ps
systemctl status
journalctl --since today
df -h

All read-only. Nothing on that list can change the box, which was the point: find the ceiling of a well-behaved agent before handing over a write.

triage.md holds the instructions. Triage one alert on a small Linux host; request one command at a time; do not guess at output; any proposed fix must name the evidence behind it.

ask.sh glues the two together:

#!/bin/sh
cat triage.md alerts/photos-restart.json | ollama run mistral

Swap the filename for the next alert and run it:

sh ask.sh

The agent answers with a command. I run that command in another terminal, paste the output into the prompt, and ask again. A few turns is usually where it settles.

That manual loop is the honest part of the setup: for one evening, the human is the sandbox, the permission boundary, and the audit log.

Findings

Attempt A. The agent asked for docker ps, saw the restart status, and proposed restarting the container. The restart policy was already doing that, which is why the alert existed. Correct reading, empty advice.

Attempt B. Same alert, same prompt, nothing added. It pulled journalctl --since today and found the failing write I had seen earlier in the week. Then it stopped.

The fault looked like it was inside the service, so it stayed inside the service. The disk never came up, even though df -h sat on the list and cost one turn.

The disk was the fault. Old container logs had filled the volume; the container could not write; the supervisor kept restarting it; the alert reported all of that as a service problem. I found it in the opening minute because running df -h is a reflex.

Attempt C. I added a line to triage.md: check the host before the service. Same model, same tools, same alert. It asked for df -h, read the full volume, and named the cause. Then it proposed clearing the log directory, which is what I had done.

No model change, no new parameters. A sentence about ordering, and a tool already on the list. If there is a $1B insight in this category, it is not sitting in the weights.

The failure that matters. A later run, on a different alert, produced a confident fix pointing at a path that does not exist on my machine. Perfect formatting. The path looked lifted from generic documentation.

I caught it because I know the box; I have typed ls in that directory often enough to feel the wrongness. Someone new to a rotation would have pasted it.

That is the asymmetry. The agent’s errors arrive in the same shape as its correct answers, at the same speed, in the same tone. Everything that makes it pleasant to read makes it harder to doubt.

What worked. Compressing a long log into a few lines. Naming the unit that was actually failing. Drafting the incident note in a shape I could paste into the team channel.

The transcript came free. Every step was a command I ran myself, so the record of why the agent concluded what it did was already written down. That is the payoff of making the agent slow and observable on purpose.

Latency was real. Each turn took long enough that I stopped watching and made tea. On a page at night, a slow answer that is right still beats a fast one that is confident and wrong.

The uncomfortable sum. My alert said the service was unhealthy and named the service. The fault was on the host. Every incident tool I have used treats the alert text as ground truth; an agent inherits that trust and answers with more confidence than the text deserves.

The version that worked was a shell script, a whitelist of read-only commands, and a sentence about ordering. The model was the least differentiated part of the stack, and it is the part the funding item is about.

Whether Traversal sells curation or a model, I cannot tell from one line. Curation is the part that does not scale with a check.

Boundaries

One alert class, one homelab, one model. A restart loop caused by a full disk is the easiest incident there is: a single cause, a visible symptom, a fix I already knew.

None of this carries over to a bad deploy that spans services, a network partition, or anything touching a database with state worth keeping.

I never gave the agent write access. Remediation safety, rollback, and blast radius are the questions that decide whether this ships in a real on-call rotation, and I have no evidence about any of them.

My setup also kept a human in the loop by construction, since I ran every command myself. Take the human out and the failure modes change in ways I did not test.

No Traversal product was involved. The item describes the category and the money and none of the behavior, so nothing here is a review of their agents, their accuracy, or their pricing.

Verdict

Build, for now. On a small stack, the version I built is an evening of work and earns its keep as a log summarizer and an incident-note drafter.

It is not an on-call engineer and should not be sold as one. Skip the paid pitch until alerts name the host and tools are scoped per service. An agent on top of vague alerts is a confidence machine with a pager.

Platform teams that already have a clean tool API and a reviewer on the other end are the ones who should buy. That is also the only place where a $120M raise at a $1B valuation can be checked against reality, because it is the only place where the agent’s output carries a cost when it is wrong.

The picture I keep: a phone lighting up at night, a sentence on the screen, someone deciding whether to trust it. Add the host name to that sentence before the phone lights up again.