AI Engineer Europe 2026
How agent o11y differs from traditional o11y
Read the talk
Agent observability: from uptime to explainable quality
Agents need more than latency and error monitoring: their variable behavior, text-heavy traces, and domain-specific failures change both the storage system and the improvement workflow.
From a talk by Phil Hetzel
Before you start: Familiarity with HTTP requests, LLM prompts, and tool calls will help; traces and spans are defined in the article.
Why does a working prototype stall before production?
A generative AI prototype works well enough to demonstrate. What would make you confident enough to put it into production? Phil Hetzel encountered that gap repeatedly during twelve years in consulting and systems implementation, including leading Slalom’s Global Databricks practice: customers were prolific at producing proofs of concept, but much less successful at deploying them. He began using Braintrust to address that problem before joining the company, where he leads solutions engineering.
The confidence problem runs in two directions. Once an agent is live, you need to know whether it performs as well as expected. When you change it, you need evidence that the next version deserves your confidence. Braintrust’s framing of agent quality connects these two activities: monitoring production behavior and evaluating experimental changes.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Keep the operational measurements
If your team already uses Grafana or Datadog, why introduce another observability system? Those tools already answer essential operational questions: is the application available, how long do interactions take, and are users encountering HTTP 400- or 500-level errors? Hetzel notes that Braintrust itself uses Datadog to monitor website errors. Agent observability does not eliminate that need.
The underlying vocabulary carries over, too:
| Primitive | What it represents |
|---|---|
| Metric | A measurement, such as latency or error count, aggregated over time |
| Trace | One complete workflow interaction |
| Span | One step within that interaction |
An agent still performs a workflow made of steps. The difference is what you must capture and evaluate inside those steps.
Suggest correction
A fast response can still be wrong
Conventional application code deliberately constrains control flow. An agent can choose different paths while attempting the same task—the flexibility that makes LLMs useful also makes their behavior harder to characterize. Observability must therefore help explain why the agent selected one path rather than another, not merely how long the selected path took.
Time to first token, total tokens, duration, and latency remain useful. But a response can arrive promptly and still fail the task. Quality measurements ask additional questions:
- Grounding: Does the answer follow from the context the application gathered?
- Tool selection: Did the agent use the tools expected for this request?
- Brand alignment: Does the response follow the standards in the system prompt?
Technical success does not establish behavioral quality. To evaluate these questions, the trace must retain the relevant context, tool interactions, instructions, and response content. That is much richer evidence than a duration or status code.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Large traces, immediate inspection
Agent traces combine a semi-structured hierarchy with substantial unstructured text. Hetzel reports seeing customer agent traces larger than one gigabyte and individual spans as large as twenty megabytes. These are reported examples, not typical trace sizes; he does not specify their composition or measurement method. The systems challenge includes ingesting and processing those payloads, but also making them usable.
As usage grows, AI engineers and product managers still expect to inspect interactions in real time. In the trace example Hetzel shows, the model calls and tool calls form a collection of spans, with large amounts of text inside those spans. A trace viewer has to expose both the execution structure and the content needed to understand the result.
The same data must support two read patterns:
- Interactive inspection: A user interacts with the agent, and an engineer wants to see that interaction almost immediately.
- Programmatic improvement: A developer issues SQL queries through a CLI and uses observability or evaluation traces to improve the application automatically.
Serving a recent interaction quickly and querying a large collection of traces are different access requirements. Both have to work against the same bulky records.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Visibility, indexing, and text search
Braintrust built a database specifically for this workload. The architecture separates immediate visibility from indexed query performance: incoming data enters a write-ahead log, while indexing supports filtering and analytical queries. The related Brainstore architecture explains the visibility mechanism: queries can read committed log entries alongside indexed data before background indexing finishes. Immediate visibility here means avoiding a wait for that indexing step, not zero ingestion latency.
Text search is a central requirement. Hetzel says Braintrust forked Tantivy to provide text indexing. His example is straightforward: find every trace containing the word Amazon. Answering that request efficiently across large trace bodies requires an index over their text, rather than relying only on structured fields such as duration or error status.
For a simple relational representation with one text row per span, the search intent can be expressed in SQL:
sql
SELECT DISTINCT trace_id
FROM span_text
WHERE text_content LIKE '%Amazon%';
Here, span_text names an illustrative table, and DISTINCT returns each matching trace once even if several spans match. The query expresses a substring search; a full-text index supplies its own token-matching semantics and avoids treating every search as a scan through every text body. The important requirement is retrieval by content across the trace.
When an audience member asks whether Tantivy is like OpenSearch, Hetzel compares it more directly to Apache Lucene, but written in Rust. The log, indexes, and text-search capabilities then need a unified SQL or SQL-like query interface. That is the purpose of the architecture diagram: incoming traces become visible, acquire indexes, and remain accessible through a common query path with results streamed to the UI.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The people who can recognize a failure
Operational observability usually serves systems engineers and product engineers. Agent quality brings in another group: people close to the users or the problem domain. Natural-language prompts give those contributors a direct way to influence behavior. Hetzel describes clinicians, registered nurses, wealth advisors, and lawyers inspecting traces to improve agents, and attributes stronger agent teams to collaboration between technical and nontechnical contributors. The person best equipped to recognize a bad answer may not be the person who operates the infrastructure.
This also connects observability to evaluations. In Braintrust’s framing, evaluations use the same basic machinery but run in batches with inputs known ahead of time. Trace storage, quality assessment, and human review are useful in both settings. The depth of the platform follows from supporting both complex data and the different people who need to work with it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
What are people doing with the agent?
Once traces contain the substance of user interactions, another question becomes possible: can the system explain how people are using the agent? Hetzel describes a capability rolled out in Braintrust’s SaaS offering roughly a month before the talk. At the level described in the recording, a lightweight LLM, embeddings, and clustering support topic modeling over incoming traces. The resulting analysis surfaces user intent, sentiment, and possible issues.
The purpose is to shorten the distance between a problem observed in production and a fix tested through experimentation. Instead of requiring someone to discover every recurring issue by reading individual traces, grouping interactions can help reveal where to investigate next.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From expert judgment to automated scores
The audience’s first distinction is between functional quality and non-functional performance. Hetzel agrees that traditional observability can measure technical performance; agent tracing also captures prompts, duration, time to first token, and cache hits alongside quality measures. These measurements are complementary: one set describes the execution, while the other assesses whether the agent did a good job.
A question about human annotation on the iceberg slide makes the quality workflow concrete. A product manager or domain expert reviews an incoming trace, but the useful artifact is more than a grade:
- Inspect the interaction. Determine whether the agent performed well or poorly.
- Explain the judgment. Record why the behavior deserves that grade.
- Identify the failure mode. Use those explanations, potentially with an LLM, to help construct scalable scoring functions.
- Automate the recurring check. Turn the recognized failure mode into something future traces can be scored against.
Human annotation helps discover what the automated evaluator should look for. The justifications connect domain expertise to repeatable quality checks.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Bring production failures into experiments
The next question joins two concerns: integrating with agent frameworks for offline optimization, and choosing a custom database instead of an OLAP system such as ClickHouse. Hetzel says Braintrust previously used ClickHouse and moved away from it. He describes the founder as an early SingleStore employee, with the background to undertake database development, but gives a specific workload reason for the decision: the text indexes they needed were not adequately available in ClickHouse at that time. This is a historical explanation, not a measured efficiency comparison or a claim about present-day ClickHouse capabilities.
For the optimization question, the distinction is when the inputs become available:
| Workload | Inputs | Execution |
|---|---|---|
| Evaluations | Known in advance | Batch |
| Production observability | Arrive from users | Real time |
Braintrust uses the same system for both. That shared infrastructure makes a production interaction usable as evidence in an offline experiment.
When the questioner presses for the practical integration step, Hetzel gives a direct workflow: capture the trace, add it to an offline dataset, and experiment on it. The handoff is the recorded interaction becoming a test case. His answer specifies that dataset workflow rather than a framework-specific integration procedure.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Leave room for failures you have not defined
The final question asks whether observability results must be quantitative. User satisfaction might be a number, but could a result instead be prose or a flag? Hetzel separates two kinds of analysis. Online scoring addresses known unknowns: you know the dimension you want to measure, even though you do not yet know how this interaction performed. Open-ended analysis addresses unknown unknowns: it derives insights without requiring every issue to have a predefined score.
Scores measure the failures you have learned to recognize; open-ended inspection helps you discover the next ones. A quality workflow needs space for both, so its understanding of agent behavior can grow beyond the checks already written.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Rust full-text search library inspired by Apache Lucene, with examples and development documentation.
Further reading
- Brainstore architectureArticle
Explains Brainstore’s object storage, write-ahead log, Tantivy indexing, and specialized trace queries.
Introduces automated grouping of production traces by user tasks, sentiment, and agent issues.
Updates since the talk
- Inside the Topics pipelineArticle
Details how trace summaries become embeddings, clusters, named topics, and classifications.
Instructions for assembling versioned test cases and adding production traces to evaluation datasets.
Search production logs through filters, SQL, and the CLI for debugging and dataset creation.
Documents production availability of ClickHouse’s native inverted text indexes in March 2026.
Read the complete timestamped transcript
- 0:00
[upbeat music] Uh, thanks for joining me today, uh, towards the end of the day here.
- 0:17
So I hope, um, everyone has enough energy left for, um, maybe what is your most exciting topic of, of the day. [laughs] Remains to be seen, uh, how traditional observability differs from agent observability.
- 0:30
Um, quick agenda. Uh, do a quick intro about myself and the company that I work for. Um, this is not gonna be a very product-forward talk. It's gonna be more theoretical.
- 0:39
So I won't drown, drown you in sales slides, I promise. Um, and then we'll get into, uh, how these two ideas differ, and also talk about, um, um, like, what's next in the, um, in the space.
- 0:52
Uh, my name is Phil Hetzel. I lead solutions engineering for Braintrust. What that means effectively is that me and my team, we're the folks that, uh, are charged with making sure that, um, our customers are getting the most value out of the platform as quickly as possible.
- 1:08
Prior to Braintrust, I spent 12 years in consulting and systems implementation. Uh, I led the Global Databricks practice for Slalom Consulting before I came here, and I noticed that a lot of my customers were prolific at creating generative AI proofs of concepts, but not nearly as good at bringing those proofs of concepts to production.
- 1:26
So I started using Braintrust as a user first, and I really liked it, and I applied for a job, and I've been here for about a year. Uh, I like to play chess out- outside of work.
- 1:35
I like to spend time with my wife and dachshund. Um, that's Pistol Pete right there. That's, that's, that's my dog. Um, he's the person in brown and not black.
- 1:45
Um, those of you who have been to my sessions before didn't laugh at that joke 'cause you've heard it, uh, at least, at least once already.
- 1:52
Uh, what is Braintrust? Braintrust is a, um, agent quality platform. We mainly look at agent quality in two different ways. Is your agent performing as well as you thought it would when it's in production?
- 2:05
Um, i.e., uh, can you remain confident in your agent? And then on the other side of that is, as you're experimenting with new versions of your agent, um, do you feel like you can become confident as you, as you tweak it and change it over time?
- 2:21
Those are a couple of things that, that Braintrust does, obviously relevant to today's discussion because, uh, uh, agent observability is a massive part about what we do. Uh, anyone has, has heard of Braintrust?
- 2:33
Show of hands. Before this week, did you hear of Braintrust? Yeah. Okay, a couple folks. Well, welcome back for the folks that have heard of us [laughs] before. Um, I'm gonna go, like, pretty quickly through the slides.
- 2:43
Hopefully, we have enough time for questions a- as well. I don't have, like, a ton of content.
- 2:48
Uh, traditional observability is established. So e- even when, uh, folks come to us, they'll say, "Well, we already have, uh, open source tools like Grafana," or, or, uh, a- as an example.
- 2:58
Why wouldn't this be the same problem that we're solving with, uh, perhaps either an implementation or a contract that we already have? Uh, it's very established and, um, we know that these applications can operate at scale.
- 3:12
So, um, the case that I'll be making is that, uh, the scope of traditional observability is actually quite different from the scope of agent observability, and, and I'll explain why.
- 3:23
Scope of traditional observability, uh, it's all about uptime and technical performance. Um, is the application up, and is the application giving a user experience from a technical lens that we would expect?
- 3:36
So, um, latency, uh, duration of, of interactions, four hundred and, and five hundred level errors, these are all things that we're measuring with, uh, with very established tools like a Grafana, like, uh, like a Datadog.
- 3:50
Um, I, I will even say that, uh, at Braintrust, though we are an agent observability platform, we're happy users of Datadog. Like, it's, it's great for this specific type of use case for us to understand if people are running into five hundred or four hundred level errors on, on our website a- as an example.
- 4:07
Is the system operational? Are we up or are we down? That's what traditional observability is. The building blocks of this are, uh, a couple different things. Um, metrics, these are the things that you're, you're measuring.
- 4:22
I gave a couple examples before, but latency is, uh, is, is the most obvious one. Error count is another. The things that you can aggregate and, and, and measure over time.
- 4:32
And then traces and spans, um... Uh, uh, is everyone here familiar with o- observability? Does everyone know what a trace is? Okay. I don't wanna take that for granted.
- 4:40
A trace is just, like, a full interaction of, of some workflow. Um, and a span is just one step within that interaction. Uh, all of these things would apply to agent observability as well.
- 4:52
So we have, we have the same, uh, building blocks.
- 4:56
Um, problem one for why agent observability is different, agents are non-deterministic, whereas applications are deterministic. The reason why we love LLM so much is because they have high variety.
- 5:08
They can do a lot of different things. They are abstracted. So because of that, while typical applications have very deterministic code paths by, you know, uh, um... And, and it, it's, it's on purpose that, that they do that, where they're performing some type of known control flow.
- 5:27
Agent applications are very much non-deterministic. We're curious about why an agent might take one path versus the other. Um, this also means that traditional observability, um, are-- is going to really have to focus on very constrained and known metrics, whereas agent observability, um, needs to be a little bit broader in terms of the things that, um, that
- 5:52
it needs to measure. This is, this is just an example of that. Um, so at the bottom, let's start there. Agent observability can- Uh, can measure some of these more traditional metrics.
- 6:05
I, uh, I'll, albeit with, with more of a, an, an AI flair, time to first token, total tokens, duration, uh, latency. These are all things that you would think would be very traditional observability level metrics.
- 6:21
But also you might want to understand more qualitative things about your application. So it's not just how, how long did I take to start responding to my user, which is more traditional observability.
- 6:34
I wanna know was the information that I gave grounded in the context that I gathered with my application? Did I use the tools that I would have expected, um, in this, um, uh, in, in...
- 6:46
as I was reasoning towards my response? Is, is a response aligned to the brand standard that I set for this agent in, in the system prompt? These are all things that are not really able to be tested by traditional observability tools because if you think about it, like, the, the trace necessary, the information and the trace that's
- 7:08
necessary for us to compute these things up at the top is far larger than the, than the volume that a traditional observability trace would handle. Um, that kind of goes to, to the next point here.
- 7:22
Agent traces are really nasty. They're, um, in, in a variety of different ways. Uh, they're nasty because they're highly semi-structured. Even within those semi-structured, there's a ton of unstructured text data that we need to chew through.
- 7:35
They're voluminous, so they can be... an agent trace could be over a gigabyte in size. We've seen that, uh, uh, even with our own customers. An individual span can be twenty megabytes in size.
- 7:47
So it, it's just a far different systems problem that you have to solve in order to ingest, process, and most importantly, use that, that type of data. And also it's, it's just as fast as a traditional observability data.
- 8:00
So hopefully your, your agent that you're putting in production gets product market fit, and you have a ton of users and, and, and usage associated with it. You as the AI engineer or as the product manager for that agent, you're going to want to see that observability in real time, in true real time.
- 8:19
Uh, trust me, we know that's the case because we always get the feedback. Yeah. Can you, can you just make it faster? We're always trying to make it faster.
- 8:27
People always want it, want it to be faster. Tough to do when the agent traces look like this. Basically, this is just like an ex- example of an agent trace in Braintrust, where not only does it have a bunch of spans here enco- encompassing the model calls and, and, and, and tool calls, but even within those spans,
- 8:47
you saw the amount of unstructured text that's in there as well. Very different problem to solve.
- 8:54
Um, a little bit, a little bit more here. Um, like very... like may- maybe I'll just dive in, into the read pattern, uh, piece specifically. We need to do, uh, two things simultaneously.
- 9:08
We need to be able to perform like the very fast read, uh, in- ingest and read style workflows that are common with observability, i.e., if someone does an action with my agent, um, uh, I need to be able to see that interaction basically inst- instantaneously.
- 9:28
We also have to commit to read patterns where someone wants to use our CLI and fire off SQL commands to us so that they can incorporate either observability or eval traces to impro- to improve their application automatically.
- 9:45
There are just a lot of different mediums that people use now in order to query these very large, uh, uh, trace shapes.
- 9:53
Uh, this is a new, it's a completely new systems problem. Um, at least at, at Braintrust, we designed a, a database from the ground up specifically for agent traces.
- 10:03
I'm not gonna really go into depth about this. We have a, we have a blog on our website. I think it was the last blog that we published, if, if you're really interested in diving deep.
- 10:11
But just very quickly, there are a lot of different components that we have to build into this database in order to make it work. For example, we need to, um, immediately get data into a write-ahead log so that people can instantly see these traces as soon as they expect.
- 10:30
We need to be able to perform indexing on these data so that whenever someone is performing a, a filtering or analytical query, that it's fast. And, um, we have this thing called a, a Tantivy index.
- 10:42
Tantivy is a, um, is, is an open source framework that we forked. Anyone know what Tantivy does? Any guesses? Tantivy is how we perform, uh, like text style in- indexing.
- 10:56
So if you remember when I was showing this trace, it makes so much sense for someone to want to perform the workflow of, okay, I would-- I just wanna know every trace that had the word Amazon into it.
- 11:09
Well, it turns out it's really hard to do that unless you perform a, a full text-based index across your traces. That's another reason why, um, a- agent observability is far different than traditional observability.
- 11:22
You really don't have to think about the text problems in traditional observability.
- 11:27
Is that the same as OpenSearch?
- 11:29
Sorry?
- 11:29
It's kind of like an OpenSearch
- 11:31
Tantivy is most similar to like an Apache Lucene ex- except it's, uh, written in Rust. Yeah. Um, and then all of these things, uh, come together and have to be unified through a, a SQL or SQL similar language.
- 11:45
That's what we've... that's the route that we've gone to at Braintrust. Um, problem three, uh, this is a... whereas there's a very specific type of persona for traditional observability.
- 11:58
It's a systems engineer. Maybe it's a product engineer. Um, it's probably not a subject matter expert or if it's a medical application, it's not a, not a clinician or, or, or a registered nurse.
- 12:10
It's very technical people that align with traditional observability. Uh, that could not be further from the truth for a- agent observability if you're doing it well. We noticed that the best teams that are building agent have both technical and non-technical people in the fold performing this work because it's the non-technical people that are either, A, closest to
- 12:31
the users, or B, have knowledge that is closest to the problem space. And what can they do now with prompts? They can write it in natural language. So they can add real value into being able to participate in, in agents.
- 12:44
Um, we have folks that, that are clinicians or registered nurses or wealth advisors or, or, or lawyers. We have seen them operate in our platform looking through traces and using that information to improve their agents.
- 13:00
That is a workflow that you j-- that you simply don't see in traditional observability where you're more worried about uptime.
- 13:08
Um, I think it... Like, in, in general, people don't realize that in order to perform observability and, and also evals well, we kind of think of observability and evals as the same problem.
- 13:20
The only difference between evals is that you're running them in batch and you know the inputs ahead of time. Um, it's, it's incredible. It, it... The, the depth that you end up going into when you create a platform like this, it looks like, it looks like this, um, because of the, the reasons that I've described.
- 13:38
The nuances with the data, um, the amount of and, and types of people that you have to bring into the fold. Those are some of the reasons why it's so different to perform in this space.
- 13:50
Uh, where is this space going? Um, we- we've done a lot of work in this area. I think the, the natural question that we used to get asked was, "If you're c-- If, if you, Braintrust, are collecting all of our agent traces and all of our agent traces have all of these valuable data in them, can't you
- 14:08
just tell me how people are using my agent?" Um, and it's the si- it's the simple questions that usually need the, the most com- complex systems behind them. Um, this is something that we are starting to do.
- 14:20
Um, we, we just rolled it out, I think about a month ago in, in our software as a service offering, where we see agent observability traces come in and then we'll run like a very lightweight LLM on top of them to perform embedding and then clustering on those traces to see how we can perf- like elevate topic,
- 14:41
uh, e- elevate topic modeling to see, for example, how people are using, uh, your traces, their intent, how people are feeling about interacting with your agent, the sentiment, or if they're running into issues, what those in- issues potentially are.
- 14:54
The whole idea is there is that you can, um, make the iteration loop between a problem that you're seeing in production and the fix that you perform experimentation on.
- 15:04
Whole idea is to just make that faster and a little bit more direct. Um, I promised I would go through that really fast. I've got about three minutes for questions if there are any, uh, and I'd be really happy to answer them. [audience applauding]
- 15:23
Anyone curious about this? Yes.
- 15:24
So Braintrust is clearly about, uh, the, the functional observability of agents. Um, would you say it's-
- 15:33
I would say technical as well
- 15:34
... would you say it's also good for non-functional agent performance, or is traditional observability good for that?
- 15:40
That's a good question, yeah. I would-- Well, I think traditional observability can do that. Um, Braintrust specifically does do-- I like the way that you put that, functional observability.
- 15:50
Um, what's the quality of my agent? How I've defined it? And then the technical observability just kind of comes on the house. Like, when, when, when you, when you trace the application, you automatically get prompts, duration, time to first token, et cetera, cache hits, et cetera.
- 16:07
Yeah. In your iceberg slide- Yeah ... the human annotation- Yeah ... at the waterline there. Yeah. Could you explain what the human annotation part is in, in this platform?
- 16:18
So let's think about it this way. Um, actually if, if I can, I'll go on a high wire act here and, um, and just show and, and, and not tell.
- 16:29
So let's say that you have a trace come in and you want your product manager to be able to opine on whether that agent did a good job or a bad job. [clears throat]
- 16:39
It's really valuable for you to have an expert come in, grade the agents, but then also like justify why they're grading the agents the way that they are. 'Cause eventually you're gonna take those justifications, you're gonna probably run an LLM over it, and you're going to make more, um, scalable scoring functions from those justifications.
- 17:01
You're finding the failure modes that you can then implement in automated scores through that. Yeah. Human annotation is a really key part of this process. Okay. Thanks. Uh, yes, in the second row.
- 17:12
Um, yeah, I just have a question, uh, because I've, I... You know, you just focused on observability piece today, but I'm interested actually how you also integrate with the other agentic framework to, uh, close the loop, like for the offline optimization.
- 17:27
Mm.
- 17:28
And then also, um, I guess the... Yeah, the, I think the main, uh, difference I feel that I see in this, your, uh, your database is that you're not using OLAP or ClickHouse like some of the users.
- 17:40
We used to use ClickHouse actually.
- 17:42
Oh, okay.
- 17:42
Yeah. We moved away from it.
- 17:43
Yeah. I just wanted to-- curious to, like, why you built your own? Like, what is the efficiency you found?
- 17:49
Well, the, the funny answer there is that our, um, our founder is kind of an insane person. Like, he-- like only an insane person would build their own database.
- 17:59
But he, he is, he is cut from that cloth. [chuckles] Um, he, he was one of the first employees at SingleStore, so he's kind of used to doing that. Um, but what he found was when, um, [lip smacks]
- 18:11
I think it was, let's see, this slide. He found that when, um, he was performing some of these workloads, he just needed the more of the text-based, uh, indus- indexes, which ClickHouse wasn't really able to do, at least at that time.
- 18:24
So we, we built our own. Um, and then the first part of your question, observability and evals to us, it's like we solve it with the same system. The only difference is that with evals, we know the inputs ahead of time, with obs- and we're doing it in batch.
- 18:37
With observability, we, we don't know what the inputs are ahead of time, and we're doing them in real time.
- 18:41
Oh, right. Uh, but I mean the experiment functionality. Like, um, how, how easy is it to integrate with like,
- 18:50
uh, um, Braintrust?
- 18:51
Oh, yeah. It should be pretty easy. Like, once, once you've traced ... And I, I apologize that I'm making this like about the product. Um, but when you, when you have a, a trace come in, you've traced it, and then you just like add it to an offline data set basically, so that you can experiment upon it.
- 19:06
Yeah. And do we have, do we have... I'm not sure if there's anyone, uh, after us in this room. Do we have to- Yeah. Not sure. Okay. But ca- carry on.
- 19:16
According to agenda, yes. Oh, is it? Okay. I'm, I'm happy to go on then. Yeah. I wanna- Yeah. Great.
- 19:26
Carry on until- Perfect. Yeah ... until 11:30.
- 19:27
Do you always, um, measure it quantitatively or do you also sometimes have some kind of qualitative piece of prose as the result? Like user satisfaction can be a number.
- 19:38
You can also imagine certain metrics to be just-
- 19:41
Yeah
- 19:41
... yeah, a flag check or something.
- 19:44
Um, we can... Do, uh, do you wanna talk specifically about Braintrust, uh, like for that answer?
- 19:50
Yeah.
- 19:51
So like there is like the online scoring piece here where it's like a known unknown where you can like very much put a score behind that. Uh, but also there are, there are ways where more ...
- 20:03
Like, like this is, these are not scores. This is like the unknown unknowns piece. Got it. Yeah. Thanks.
- 20:09
Thank you.
- 20:09
Um, where we can in a, in a more like open-ended way derive insight from it. Yeah.
- 20:18
Yeah. Probably time for, for one question. If not...
- 20:26
Great. I appreciate everyone's attention today. Thank you. [outro music]