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 emitted governed decision, allowed or blocked, becomes an audit record. The client signs it and ingest countersigns accepted records, separating client-chain continuity from proof that the backend accepted the event.

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 a live Obsvr API. The SDK verifier runs offline: structural mode checks linkage and completeness, while authenticated HMAC verification requires the relevant key. The daily-root layer uses Ed25519 so an exported bundle can be checked with the published public key.

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. SDK coverage remains an operational deployment claim; the gateway adds signed coverage heartbeats for its own enforcement window.

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.