Why We Built obsvr

Here is a question worth sitting with. Your agent ran for a week. It read files, called APIs, wrote to a database, and spent money. Someone asks what it did, and specifically whether it ever touched customer data it shouldn't have. What can you actually produce?

For most stacks the honest answer is a pile of application logs, a trace viewer showing latency and token counts, and a shrug. Not because anyone was careless, but because nothing in the standard stack was built to answer that question. The logs are whatever the app happened to write. The traces show that a call occurred, not whether it should have. And every one of those records lives in a database that anyone with write access can edit, which means it proves nothing to an auditor who is paid to assume you might.

That is the gap obsvr was built for.

The layer nobody built

Every tool in the usual stack is good at its job. LLM providers ship capable models. Orchestration frameworks handle agent loops and tool routing. Observability platforms produce dashboards: token counts, latency graphs, traces.

What none of them provided was a control plane: something that actually sits in the execution path, not watching from outside it, and intercepts, enforces, and records what an agent is about to do before it does it. Logging tells you what happened. It doesn't stop anything from happening.

What we built

obsvr sits in that path. It intercepts LLM calls before they go out, and tool calls before they execute.

Enforcement runs first, deterministically. PII in a prompt gets redacted or blocked depending on policy. A tool that isn't on the allowlist doesn't run. None of this requires an LLM to make the call - it's regex, rules, and lookups, and it happens in microseconds.

Every call, allowed or blocked, gets written to an audit record. That record is signed on the client and countersigned by the server, so it can't be forged by either side alone - that's the record you hand to your compliance team or your auditor when they ask what actually happened.

And where you want a human in the decision, the SDK gives you the hook to put one there. You wire your own approval flow into onPreCall; obsvr enforces the decision and logs it either way. We don't ship the human interface for you - what we guarantee is that the decision point exists and that what happened is provable afterward.

The integration decision

Early on we decided obsvr had to work with what people already had. We are not another agent framework, and we're not asking anyone to restructure how they build. Wrapping an existing LLM client is one line. Patching an existing MCP client is one call. The governance layer shows up in the execution path without anyone having to rewrite how the code is structured.

This matters because the teams that need governance most are usually the ones already running agents in production. Telling them to pause and re-architect isn't a realistic ask.

Where this goes

Near-term, the roadmap is what you'd expect: more integrations, more policy primitives, better evidence export. The longer bet is that human approval flows, wired through the hooks we expose today, become the way teams build a track record for their agents - a history detailed enough that eventually the system can tell you which actions genuinely don't need a human anymore.

We're not trying to keep a human in the loop forever. We're trying to make it possible to prove when one isn't required.

The bet underneath the product

Every infrastructure company is a bet about which layer becomes load-bearing. Ours is that the model stops being the interesting part.

For two years the model was the whole decision. You picked a provider, standardized on it, and everything downstream followed from that choice. That is already ending. Teams run several models for different jobs, swap them as prices and capabilities move, and increasingly run open-weight models on their own hardware. The model is becoming a component you choose per task rather than a platform you commit to.

What does not become interchangeable is the answer to what your systems did. That question survives every model swap, and it gets harder to answer with each one, because every provider console shows you its own slice and none of them show you the whole. The layer that stays constant while the models underneath change is the one worth building carefully.

That is why obsvr is not a model router and not an observability dashboard. Routing is about which model runs. Observability is about what happened to latency and cost. Neither of them answers the question a regulator, a customer's security team, or your own incident review actually asks, which is what the system decided, under what rules, and how you know.

Three decisions we would make the same way again

Deterministic enforcement. No second model in the decision path. It costs recall on novel attacks and buys three things worth more for this job: microsecond latency, decisions reproducible from a ruleset hash months later, and an answer to "why was this blocked" that names a rule rather than a score.

Signed at capture, not at storage. A record signed when it is written to a database proves the database's account of events. A record signed in the process that made the decision, chained to the one before it, proves something stronger and proves it without the customer having to trust our storage layer.

Verification that does not require us. The verifier ships in the SDK and runs offline. An auditor can check a chain without calling our API, which means we are outside the trust boundary of our own evidence. Any design where verification requires the vendor's cooperation is weaker in exactly the moment it matters most.

What we are still honest about

The SDK covers TypeScript and Python. A service in another language calling a provider directly is not governed by it, and the gateway exists partly for that reason. Pattern-based injection detection is defense in depth rather than proof of prevention, and our own documentation says so rather than burying it. Coverage depends on the SDK actually being installed, which is why coverage heartbeats exist: so an unattested window is a visible fact rather than an assumption.

Stating limits plainly is not modesty. A governance product that overstates its reach produces exactly the false confidence it was bought to eliminate, and the first serious security review will find the gap anyway. Better it comes from us.