← Building Glasstrace

Choosing Development Time Over Production: The Founding Constraints

Building Glasstrace, Part 1 · August 27, 2026

The first substantive decision in the Glasstrace program was made before the first line of the software development kit (SDK) shipped: the product would not operate in production environments at all. Every established observability company lives in production. That is where the revenue and the incidents are, and where Sentry and Datadog built their businesses. I excluded it anyway, and most of what follows in this series traces back to that choice.

The observed problem

Artificial intelligence (AI) coding agents now write a growing share of application code. When a web application fails at runtime, however, those agents debug without visibility. An agent can read source code, diffs, and browser state. It cannot observe what actually happened across the request, the object-relational mapper, and the database when a real user action failed. So it speculates: it inserts logging statements, modifies code, and retries, spending tokens and time on symptoms instead of causes.

The remedy was clear enough: capture the causal chain (user interaction, server processing, database operation, with runtime values) and serve it to the agent in a queryable form. The harder question was where that capture should be permitted to run.

The two constraints

Two rules were adopted early and still define the product’s risk posture.

The first is that Glasstrace is observational only. It never drives the browser and never modifies the application under observation.

The second is that Glasstrace is development only. The SDK disables itself in production. Because no production mode exists, none can be misconfigured.

Commercially these constraints have a real price. Production debugging is the incumbent vendors’ territory, and the decision conceded it on day one. What the concession secured would have been difficult to obtain any other way.

The first gain is a privacy posture in which agent access is lower-risk by construction. Development traffic is the developer’s own traffic against a development database. Capturing returned rows, query parameters, and side-effect evidence in that setting carries a different risk profile than performing the same capture against production customer data. Every ambitious item on the roadmap, from agents adjusting capture policies at runtime to governed in-memory inspection, is defensible only because the blast radius is a development environment. A production monitoring vendor that allowed an autonomous agent to write its own capture policy would be accepting a compliance exposure I wanted no part of. That said, a development environment is only as low-risk as what the developer keeps in it, and production-derived seed data is common. The posture reduces the stakes but does not remove them.

The second gain is adoption friction near zero. No change-management review, no data-processing agreement, no operations approval. The developer installs one package and the agent can observe the application.

The resulting architecture

With the constraints fixed, the architecture mostly followed: an OpenTelemetry-based SDK performing automatic capture inside the application, streaming to a cloud backend, fronted by a Model Context Protocol (MCP) server so that any compatible agent (Claude Code, Cursor, Codex, Gemini, Windsurf) can query evidence instead of parsing logs.

The commit history shows how early these commitments landed. The product repository opened on March 17, 2026 (glasstrace-product@d0405a0d), and MCP tool types entered the schema during the initial bootstrap wave (e543cb47, SCHEMA-004). The agent interface was in the schema before most of the product existed. The SDK was extracted into its own MIT-licensed repository on March 31 (glasstrace-sdk@1a26f5b, 4f28361). A commit from the first week of April defines the kit’s character: bcbb81a (April 6), which bundled the OpenTelemetry packages into the kit for zero-dependency tracing. The bundling means the project owns the dependency surface, so installation stays a single command, paid for by tracking upstream OpenTelemetry releases and by coexisting correctly with applications that already run OpenTelemetry. Commit 14691e9 records the coexistence work, which along the way corrected a Prisma instrumentation gap.

April was the heaviest construction month of the project: 1,902 commits on the product side and 224 on the SDK (main branches, April author dates), most of it unglamorous plumbing work on ingestion, span normalization, trace assembly, and the 8 MCP tools that turn a collection of spans into answers an agent can act on.

Testing whether the position was actually unoccupied

A decision this large deserved a falsification attempt, so in July I ran a structured competitive review rather than trusting my own framing. The grid placed development time against production on one axis, and agent-native against human-first design on the other. The production, agent-native quadrant is filling up: Sentry’s Seer product, Hud (which reportedly raised $21 million for a production runtime sensor for agents, the same thesis pointed at the other environment), and Datadog’s MCP work. The development-time, agent-native quadrant has neighbors as well. Cursor’s Debug Mode keeps ephemeral logs and is confined to one editor. Sentry Spotlight’s MCP server exposes span trees but carries no runtime values and no join between user action and server activity.

The review’s recorded conclusion: no other occupant was found in Glasstrace’s cell, meaning development-time, agent-native, causal click-to-server-to-database traces with runtime values. The nearest threat is Sentry, scored internally at roughly 70 percent overlap on the core loop (a directional score, not a measurement). The most serious distribution threat is free and pre-installed: the built-in MCP server in Next.js, which removes the standalone “latest error” use case even though it offers no span tree, no database visibility, and no values.

An unoccupied cell is not, by itself, defensible. It becomes worth holding when the emptiness has a cause competitors cannot adopt, and this one does: Sentry cannot let agents steer capture against production data without inheriting the compliance exposure this program declined.

Sixteen weeks of validation work later, the constraints remain in force, unchanged. The decision was a wager rather than a deduction; these articles record its terms.

Supporting data and commit references

Evidence availability: references to glasstrace-sdk are public — the repository, commits, and files are linked in the series evidence manifest. All other repositories cited above are private; artifacts may be shared as needed, and the manifest publishes each cited artifact’s SHA-256 digest so that any shared copy can be verified against the version these articles describe.