Engineering at Morse: what this lane covers
How we build an observability product for agents, the few rules we hold ourselves to, and what you'll read in the engineering posts.
By The Morse team
Morse is AI-agent observability and evals. Underneath the performance brief is a fairly ordinary-looking system: SDKs that capture what your agent did, an ingestion path that accepts it, storage that keeps it, and analysis that turns it into a ranked list of what needs attention. The interesting engineering is in the details, and that is what this lane is for.
The rules we build by
A few decisions were made on day one and have shaped almost everything since.
- Every span has a type. Agent, LLM, tool, HTTP, database, or custom — plus a few more specific ones. Typing up front is what lets cost land on the right LLM call and tool failures stay distinguishable from model failures.
- Ingestion doesn't care which protocol you used. Stock OpenTelemetry exporters and our own SDKs arrive through different endpoints, then translate into one internal model before anything is stored.
- Infrastructure shows up inside the agent trace. A slow database call or a failing HTTP dependency appears where it happened in the run, not on a separate dashboard. We are deliberately not building a general metrics or logs product.
- Payloads are sensitive by default. Traces hold prompts and completions, so stored payloads are encrypted at rest, and access is scoped to the organization that owns the data, with a test matrix that checks that isolation across endpoints.
- Numbers say where they came from. A cost that couldn't be priced stays empty rather than showing zero, and a sampled signal is labeled as sampled.
How we work
We test against the stored result, not against the code path we hoped ran. Several of our CI checks work as ratchets: a list of known gaps that can only shrink. And we write down decisions, including the ones we reversed, so the next change starts from what we learned rather than from memory.
We also run Morse on Morse. Our own agents report into it, which is how a few of the bugs in these posts were found.
What you'll read here
- Design decisions and their trade-offs, like why spans are typed from day one.
- How a piece of the system works, like staging OTLP exports on a stream before we parse them.
- What broke and what we changed, written up honestly, including what we chose not to build yet.
If you're building agents and wondering how the telemetry side should work, we hope these are useful even if you never use Morse. Subscribe via RSS to follow along.