AI Engineer World's Fair 2026
The Missing Layer After Launch
Read the talk
The Missing Layer After Launch
A working demo does not tell you whether an agent helps real users. Production agents need a loop that turns traces, session analysis, and browser checks into reviewed improvements.
From a talk by Raphael Kalandadze
Before you start: Familiarity with agent tool calls, execution traces, and pull-request review will help you follow the operational workflows.
The demo works. What happens in production?
You built an agent, launched it, and watched it work well in a demo. Now hundreds or thousands of real conversations arrive every day. How do you know whether it is working? How do you understand the system’s health, improve it, and find problems you do not yet know to look for? The demo establishes that the agent can succeed. Operating the product requires understanding what happens across actual use.
Raphael Kalandadze calls this the missing layer after launch. Models make it possible to build products quickly, sometimes in days or weeks, but shipping starts the work of maintaining control over their behavior. The feedback loop is part of the product: it supplies the evidence needed to improve the system every day. Monitoring, logs, diagnosis, and fixes are familiar software practices; agents make each harder because their behavior is much less constrained.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
You cannot enumerate the conversations
An agent does not expose only a few buttons and predefined flows. Coding agents such as Claude Code and Codex illustrate the breadth of the task surface: users bring instructions, and the system attempts to handle them. You cannot write every possible conversation in advance. After launch, that breadth can make you lose the feel for your own system—whether it is getting better, getting worse, or behaving differently from what you intended.
Unit tests, regular expressions, rule-based checks, and scripted customer conversations still help. Kalandadze’s team tried all of them. They cover a slice of the problem, while customers continually introduce conversations outside that slice. Model-driven execution also varies: the same input can take a different path, and a small input change can redirect an entire trajectory. Pre-launch testing therefore cannot exhaust the behavior that production will reveal.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A completed itinerary can still be wrong
Long tasks widen the investigative surface further. They can involve extensive tool use, intermediate summarizations, sub-agents, generated code, terminal commands, external services, and third-party libraries. Each introduces behavior that the final response alone cannot explain. Kalandadze describes a scale of hundreds or thousands of tools, without distinguishing separate tools from repeated invocations. The operational point is the size and variety of the execution path.
In the team’s travel use case, a user asks for an itinerary. The agent runs the flow and builds a trip, but books a different service and makes mistakes calculating the price. Technically, the workflow completes; the user’s task fails. That distinction gives production analysis a concrete target: compare what the user requested with what the system actually produced.
For example, the service and price checks can become small regression tests once the failure is understood. This TypeScript example uses an illustrative itinerary with prices represented in cents:
typescript
type Itinerary = {
serviceId: string;
lineItemsCents: number[];
totalCents: number;
};
function checkItinerary(
requestedServiceId: string,
itinerary: Itinerary,
): string[] {
const problems: string[] = [];
if (itinerary.serviceId !== requestedServiceId) {
problems.push("Booked service differs from requested service");
}
const expectedTotal = itinerary.lineItemsCents.reduce(
(sum, price) => sum + price,
0,
);
if (itinerary.totalCents !== expectedTotal) {
problems.push("Total differs from the sum of line items");
}
return problems;
}
const problems = checkItinerary("airport-transfer", {
serviceId: "city-tour",
lineItemsCents: [4000, 2500],
totalCents: 7000,
});
// Both the service mismatch and the incorrect total are flagged.
These checks capture two known failures; they do not determine whether the whole trip is useful. Production teaches you which assertions were missing in the first place.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Turn logs into a reviewed fix
Logs are the starting evidence for understanding what happened. Their structured information is well suited to agents that can write scripts to filter large volumes of records. But filtering is only the beginning. The investigator must distinguish a real bug from noise, follow the relevant trace or trajectory, and separate the symptom from its root cause. Operating an agent becomes an agent task itself because that work requires reasoning across evidence.
The repair loop follows a concrete sequence:
- Give a diagnostic agent traces, trajectories, and access to the codebase.
- Have it investigate the problem and submit a pull request.
- Give a separate review agent fresh context so it can examine the proposed fix from another angle.
- Have the reviewer run focused tests, criticize and score the change, and request revisions or close the PR when appropriate.
- Hand the reviewed change to a human where the workflow retains human review.
Separating diagnosis from review matters because the fixing agent is eager to produce a patch. A reviewer with fresh context can challenge both the explanation and the proposed solution.
The loop needs calibration before the team can trust it. Kalandadze reports that a PR can be ready in half an hour once this loop is in place. That is time to a proposed fix, not a measured time to merge or deployment. He presents the implementation as his team’s practice, rather than an optimal design: one flow handles rapid diagnosis and repair, while another provides a wider view of system health.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make recurring investigations actionable
The log-monitoring agent runs on a schedule, with hourly or fifteen-minute intervals offered as options. It receives logs, trajectories, and codebase access, then investigates questions such as whether a user ended up stuck. Depending on what it finds, it can produce a PR or send a Slack alert. Critical problems need immediate attention; other findings can wait.
The output must make the investigation easy to understand:
- Pull request: a short explanation of the problem, supporting metadata, and diagrams or tables that explain the change. Kalandadze mentions Mermaid diagrams, ASCII tables, and optional HTML artifacts for a quick visual understanding.
- Slack notification: a concise signal that distinguishes a critical problem from a heads-up warning someone can investigate later.
These artifacts carry the diagnostic work forward. The human should be able to understand why a change exists without reconstructing the entire investigation.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Close the loop before removing the human
The review agent criticizes and scores the proposed change before handing it to a human. That creates a throughput challenge: Kalandadze reports that the PR and review agents send ten times as many PRs per day as the three-person team. This is a reported comparison of PR volume, without acceptance-rate or task-complexity data; it does not establish a tenfold increase in useful fixes.
Clear descriptions and supporting artifacts help manage that volume. Kalandadze says he can often understand a problem in a few minutes, which makes continued human participation workable for the team. Removing the human is a possible future choice. His practical ordering is to close the loop first, then address the human bottleneck if it becomes the limiting factor.
The review examples show summaries, diagrams, risks, edge cases, and requests for changes. Fixing and reviewing can repeat until no further changes are needed, at which point the human enters the loop. The completed review slide shows a ready verdict tied to a root-cause fix and a test that reproduces the problem—a more useful handoff than an unsupported assertion that the patch looks good.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Look beyond the latest incident
In the team’s actual setup, the local monitoring agent runs hourly and examines the preceding hour of logs. That makes it useful for local problems, but gives it little basis for understanding the system as a whole. A separate session analyzer supplies the wider view by inspecting conversations and scoring their outcomes.
The analyzer aims to examine every conversation through multiple sub-agents. It consumes substantial tokens, but can connect observations across sessions: recurring patterns, clusters of problems, and possible causes. It also tracks tool calls, sub-agent use, and summarizations, while producing insights and extracting entities. The purpose is to restore a sense of system health that individual incident investigations cannot provide.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From system health to affected sessions
Kalandadze demonstrates a custom dashboard built around the questions he wants to investigate, despite the availability of commercial alternatives. It starts with system health, the number of analyzed sessions, cost, average score, success rate, and trends. The most valuable layer for him is the AI insights: findings that connect observations rather than merely display counters. Each critical insight explains what happened, why it matters, the root cause, the affected sessions, and a recommended fix.
The demonstration uses anonymized data derived from real conversations. Its views move from aggregates to individual evidence:
| View | Information shown |
|---|---|
| Distribution | Session scores and per-company session counts or costs |
| Conversation analysis | Sentiment and extracted entities |
| Tool analysis | Success rates, rejected calls, and rejection reasons |
| Session detail | Ranking, score, runs, messages, tool calls, and summarizations |
Detailed explanations accompany individual sessions so an investigator can understand the problem behind a score. The talk does not define the scoring rubric or success-rate denominator, so those labels should be read as this system’s analytical outputs rather than standardized measures.
The dashboard’s main job is oversight across hundreds or thousands of conversations, rather than fixing a particular bug. Kalandadze suggests running this broader analysis once or twice a week. That slower cadence complements the fast repair loop: one catches local problems promptly, while the other reveals patterns and changes in overall behavior.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Check what the customer actually sees
Both monitoring and session analysis primarily look through logs, code, or recorded conversations. They need a complementary customer perspective. A computer-use agent opens the browser, logs in, and simulates customer interaction to find UI problems that backend evidence may not reveal. Kalandadze names Codex as one tool the team sometimes uses to drive this work.
Generic browser interaction is slow in his experience. The team therefore built a skill that knows its website and DOM, which he reports makes the workflow faster. The agent can open the site, log in, open a session, send messages, and inspect both behavior and appearance, including the resulting artifacts. This adds direct evidence of the user experience, though it remains token-intensive.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Connect the evidence into a meta harness
These agents need the evidence a human investigator would need: logs, trajectories, metrics, database state, and the live UI. A computer-use agent that discovers a visible problem should be able to follow it into the execution trajectory and inspect the database to understand what happened. Otherwise, it can describe the symptom without establishing its cause.
Kalandadze calls the connected system a meta harness. The diagram brings the live product’s evidence sources into an internal harness containing log monitoring, PR review, session analysis, and computer-use QA, with Slack carrying notifications. Connecting those capabilities lets a finding lead to investigation and a proposed fix grounded in the actual failure.
The durable advantage is the operational system around the model. At minimum, it observes the product and helps the team understand its behavior. Ideally, it closes the loop with proposed fixes and notifications that accelerate improvement. Other teams can use the same model, agent, or harness; the internal system that discovers your product’s problems and turns production experience into better behavior is what keeps improving after launch.
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
Anthropic explains persistent progress records, feature lists and browser testing for coding agents working across multiple context windows.
Updates since the talk
Wandero's expanded written account covers monitoring, PR review, session analysis, customer usage and codebase maintenance.
Read the complete timestamped transcript
- 0:00
All right. So you built an agent, you launched it, everything works pretty well in a demo, everyone is happy. But now let me ask you a few simple questions.
- 0:09
So how do you know if it's actually working out there? How do you watch across hundreds or thousands of real conversations every day? How do you feel or understand the health of the system?
- 0:20
How do you make it better? How do you find the holes that you don't know are there yet? And that's the thing, right? So most of the talks about the agents end at the moment when you ship.
- 0:29
So we build it, it work, the end. But I think the shipping is the moment when the real work begins. And somehow only a few peoples are talking about that, and I'm calling it the missing layer.
- 0:40
So let's dive into it. So that's the world we are living. So you can create the whole product. You can create a whole startup in a couple of days, in a couple of weeks.
- 0:49
You can write hundred thousands of lines of code. You can spend a lot of tokens. And to be honest, it's the easiest part today with the help of the latest models.
- 0:58
But I think the shipping is the moment when the real work begins because you need to close the loop as soon as possible. So after you launch, you need to have some control and understanding of the system.
- 1:09
And, uh, from my experience, the loop is, uh, at least as important as the product itself, sometimes even more, because the tight feedback is the one that helps you to make the product better every single day.
- 1:22
And that's the missing layer, and that's what the rest of this talk is all about. So what happens after you launch? And this is not something surprising. We had the same questions in the classical old software.
- 1:33
You need to monitor what is happening. You need to understand how it behaves. You need to have some logs to detect the problems and fix them. Uh, and for agentic systems, each one of those are even harder and sometimes, uh, they turn into something genuinely new.
- 1:50
So let's talk about why this is hard and why this is hard now. So the agent is on a normal software, right? You, you don't have a few features and several buttons.
- 1:59
You don't have a, uh, predefined flow that you can test before you go to the, to the live. Uh, and the coverage is endless. So think about like CloudCode or Codex.
- 2:10
They can do a giant range of stuff, whatever the user needs, and, uh, most of the agents do the same, right? So you give the instructions, and they can handle it.
- 2:18
And you cannot write all the conversations, uh, in advance. So th-this leads to the deepest part of the problem. The part that keeps me up all night, which is you lose the feel for your own system.
- 2:31
So after you, uh, build the product, you need to have some kind of understanding. Does it get better or worse? So you need to monitor, understand what is happening.
- 2:41
And the problem is that this normal-- the normal safety nets don't save you here. Uh, and believe me, we try, uh, a few stuff or we, we build a unit test.
- 2:52
We have some regex, some rule-based checks. We even create some scripts to simulate the customer conversation. Uh, and, uh, yeah, it helps in some ways. Uh, but at the end of the day, uh, it is like only a one slice of the whole problem
- 3:08
because, uh, customers always do something different. Uh, you cannot write it all down. They are too many, and they are all different. And the horizon for it in the same way.
- 3:20
So you don't know what your agent will do until it is in the production.
- 3:25
So why this is a new problem? So as you know, LLMs are not, uh, deterministic. Uh, the same input can have a different path. Even slight modification on the input can call a different trajectory, and the coverage is endless.
- 3:39
You cannot list it all down. You cannot pretest until you go into production.
- 3:44
The second and the scariest one is the failure hides itself. So let's think about what happens when the agent is running for a long time. It struggle in the middle of a task.
- 3:55
Uh, it has some problems, but it was lucky. Uh, it was recovered. It finds some workarounds, uh, try some other tool calls or wherever, and you did not get any red alerts, any problems on the dashboard.
- 4:08
Everything looks fine. But you know, this is a early warning for you. This is a problem that, uh, that is hidden, uh, and that lives in your code base.
- 4:18
And you need to fix it as soon as possible because if you're talking about the reliable agents, uh, each will be dependent on the luck, right? And, uh, also as Anthropic mentioned in the blog post, sometimes the agent loves to make-- mark the feature as complete, uh, without checking if they actually worked.
- 4:38
The next one is, uh, the tool calling, right? So the tool surface is huge. So long-running task needs a hundred of tools, even thousands of tools. Um, sometimes it have, uh, several summarization in the middle.
- 4:51
It use some sub-agent, writes a lot of code. It use a terminal for sure. It calls some other company services, third-party libraries, and, uh, they, they work with different way, uh, all the time.
- 5:04
So actually, you don't know what you're looking for. So sometimes finished does not mean it is helpful for the user. Maybe there wasn't any-- there wasn't any problems. So agent finished, everything looks good.
- 5:16
The answer was successful. But what happens, like for example, for our use case, sometimes, uh, user asks to build the itinerary, agent run the flow, it builds a trip, but it book a different service.
- 5:30
It made a lot of mistakes in calculating the price, so user is not happy. So technically is successful, but still fail in the task. And as I mentioned, the unit tests don't save you here and production is the place when you learn what you need to, uh, what you need to test on the first place.
- 5:47
All right, so what happens after you launch the product, right? So you need to monitor, you need to understand and improve the system. Uh, and what's the source of the truth, right?
- 5:57
This is the logs. Everyone has the logs. Everyone loves the logs. You have structured information. And, uh, you know, those machines are the best to understand and explore the logs much better than any human, much faster.
- 6:10
They can write some scripts to filter the giant of walls. Um, and this is the most obvious way that you can hand it to the agent. Uh, but as soon as you start working on that, maybe you build an agent or skill or whatever, you, you quickly understand this is not as easy as you imagine because it
- 6:30
needs a lot of reasoning. You need to understand the problem to, uh, differentiate if, if it's a real bug or a noise, to keep time in its phrase or trajectory, understand if it's a, a symptom or a root cause.
- 6:43
So actually, you'll find out that the operat-operating an agent itself is an agent problems.
- 6:50
So this is a loop like end-to-end. So you have a traces, you have trajectories, you give the agent to access the code base. It diagnose the problem, understand what was happening, and send the PR.
- 7:02
And then you can have a scale or sub-agent or, or wherever that controls the PR, uh, because you know, most of the agents are pretty eager to send the PR.
- 7:11
They love to fix the problems. We prefer to have a separate agent, which has a, like, fresh context. It try to check, um, mm-hmm, the PR on different angle, on different view, run the, um, uh, the focus test.
- 7:27
And, uh, it is not biased of the problem itself. It tries to criticize, score the PR, and, uh, sometimes it, uh, requires the changes. Maybe it close the PR directly and help us to, to filter those problems.
- 7:41
Uh, and, uh, mm, then you have the human-in-the-loop. Sometimes you don't. Uh, and we can talk about this later, but you know, this is the most obvious thing that you can hand it to the agent, which is-- which seems like, uh, pretty obvious for most of the people.
- 7:57
And, um, a lot of teams use the same practice, but I think people don't appreciate how important it is. And you need s-- you need to spend some time on that.
- 8:07
You need to calibrate. You need to make it reliable, to trust the loop. And this is the, the fastest loop that we ever had. So,
- 8:16
you know, after you build this simple, uh, simple system, you, uh, already have the feel and understanding how it behaves, what is happening. You detect the problems and local fixes as soon as possible.
- 8:30
And you can have the PR in-- PR ready in half an hour, and you can, uh, easily understand what is happening. So let me walk you through, uh, how I'm handling this.
- 8:40
Maybe this isn't optimal, but I think this, this will help you to, to get some point. So actually we have a two main flow. The first one is the, the fastest loop that helps you to, to detect and, uh, fix the problems as soon as possible.
- 8:56
And another one is like more on a zoom out that hel-- that helps you to have, uh, on a high-level understanding, and it helps you to have hand on the pulse.
- 9:07
So the first one is a log monitoring agent, the one that I already mentioned. So you have trajectories, you have logs, you have the access to a code base, and it runs every hour or, um, uh, every few, uh, fifteen minutes.
- 9:21
And it try to understand the problem. It deep dives in the, in the logs, uh, understand does the us-user end up stuck and, uh, send the PR or sometimes send the Slack alert.
- 9:33
And this is, this is pretty, uh, important because sometimes the problem is, uh, uh, so critical, so we need to, mm, fix them as soon as possible. And, uh, yeah, it works pretty well.
- 9:48
So this is the one example how the PR can look like. So you have a nice description, a short explanation what is happening. You have some metadata. You have nice diagrams, Mermaid or ASCII tables.
- 10:00
Maybe you will have some HTML artifact that helps you to give you a glance of the problem and quickly, mm, understand what is this PR for.
- 10:12
So this is an example how a stack notification can look like. It helps you to quickly, uh, give you a feedback, detect if there are some, uh, critical problems.
- 10:21
Sometimes it just, it is just like heads up, so you know there are some warnings, there are some problems, so you need to check them, uh, when you have some time.
- 10:31
And as I mentioned, the review agent is, uh, pretty critical because it try to check the problem in different angle. It always try to criticize the problem, score the problem, and, uh, as soon as it's ready, it send the PR to the human.
- 10:45
And sometimes people talk about that if you need to have the human in the loop because you know, still human in the bottleneck in this case. Uh, in our case, the, the, the PR agent and the review agent send ten times more PR than three of us, uh, every day.
- 11:01
So you need to have some clean system how we're gonna handle this to not be a bottleneck in this system. But from my experience, as I mentioned, this PR and the review agent helps me to have a n-nice description, uh, some artifacts that helps me to quickly understand the problem.
- 11:20
Uh, may-- and maybe I spend a few minutes to at least understand what is happening. So I think at this time it's okay, but maybe we will remove it in the future.
- 11:30
And yeah, people are talking about that. So you need to... You ne-- you don't need to be a bottleneck in this problem. Some of them prefer, uh, to remove the humans in this loop.
- 11:40
But you know the trend is that you need to close the loop first. So let's make the problem when you are the bottleneck, and then you can remove yourself pretty easily, I think.
- 11:52
So this is, uh, some examples how the review agent feedback can look like. As you know, uh, it requires some changes. You have some summary. You have some diagrams, explanation where there are some risks, some edge cases.
- 12:05
And sometimes, uh, after a few iterations or they go in loop, uh, where the k- where the kid is ready, so we don't no- we don't need to, uh, have any more changes.
- 12:16
So after that, the human will, uh, jump, uh, into the loop.
- 12:22
For the previous agent, as I mentioned, that is especially good when you want to fix some local problems. Uh, for our case, it runs every hour. It checks only a one-hour window of the logs, and, uh, it doesn't have any, uh, high-level understanding of the problem.
- 12:39
So we find-- found out that we need to have another system that helps us to, to get, uh, to get, uh, mm, like more on a high level explanation, some kind of a health of the system.
- 12:51
And, you know, visibility is the easiest piece. Um, before the agent view was impossible, so you cannot, uh, deep dive or summarize hundreds of conversations. But right now we can have a system that helps you, uh, to, to score every conversations, understand what is happening, and give you a high level zoom out of the system.
- 13:12
So this is the session analyzer, and the main goal is to just give me the score of the health of the system, right? So we try to check every, every conversation, run through a lot of sub-agents.
- 13:24
It spend a lot of tokens. Uh, but yeah, it helps us to detect some patterns, connecting the dots and, uh, try to understand some high-level patterns. And, uh, yeah, it also detects some, uh, mm, uh, like cluster problems.
- 13:42
What is the cause? Uh, how many tool calls are used? How many sub-agents? Uh, how many summary happened or wherever. But also it gives some AI insights, some entities, so we have an understanding of the problem.
- 13:55
So, right. As I mentioned, one of the main problem is that you lose the control after you launch the production. So you need to have the system that helps you to control at least to have some understanding what is happening, how it looks like, is it healthy or what or not.
- 14:10
So, um, [lip smack] actually let me, let me show you,
- 14:16
uh, one of the example how, how it looks like. So actually we build it ourselves. So there are a lot of other, um, companies and tools that provide the same kind of system, but [lip smack] I prefer to build it myself because I know what I'm interesting for, what I'm looking for.
- 14:33
So as you can h-- see, we have the health of the system, we have number of sessions that was analyzed, the cost, we have the average score, some success rate.
- 14:41
We have some trends, we have the AI insights, and this is the most important part. When the AI or when the agent try to connect the dots, find the patterns.
- 14:50
If there are some critical ones, you have a description for each of them. What is this? Why it matters? What are the root cause? All the sessions, uh, affected, and some recommendation fix.
- 15:02
So right now this is just, uh, anonymized data, but it comes from a, from a real conversations. So we have a score distribution. Uh, each company, um, number of sessions or the cost.
- 15:15
We have, uh, the sentiment analysis, some entities. We have analytics about tool calls, all the success rate, how many rejected and why. And you have, uh, detailed, uh, analysis of the each session.
- 15:28
So it ranks each one of them, scores, that is, um, how many times it was running, how many messages, how many tool calls, how many summary. And you have a detailed explanation for each of them.
- 15:40
What was the problem? It is something that you need to session and, uh, believe me, it helps a lot and it helps you to check and watch across hundreds of, uh, conversations.
- 15:52
So the, the main goal of this dashboard and the system is not to fix some, uh, um, uh, specific problems or bug. This is more on a high level that helps you to watch across hundreds or thousands of real conversations.
- 16:07
So you can run it once in a week, two times in a week, or something like that. All right, so the next one is that, mm, so the problem of the previous, uh, agent that I mentioned is like the first one helps you to detect the specific problems.
- 16:22
The second one is to give you a high-level understanding, but both of them work from a angle of the logs or a, uh, code or a session itself. But you need to have some kind of user perspective, right?
- 16:37
So that's why we have some computer user agent that helps you to, uh, to open the browser, uh, to log in and try to simulate the customer itself, because sometimes you have some problems in the UI.
- 16:49
You need to, um, um, check if everything looks good. Uh, and uh, yeah, sometimes code and logs don't help you, uh, in this way. So this is, uh, example how it looks like.
- 17:03
So you, you use Codex, uh, sometimes. So it use, um, uh, the browser itself.
- 17:10
Uh, actually it is pretty slow. Uh, and we try to build the specific skill that know our, uh, website, our DOM, how it looks like, and that is much faster.
- 17:22
And it can, uh, open the website, log in, open the session, send the messages, check what is happening, uh, and also check, uh, how it looks like, what are, what are the some artifacts.
- 17:34
And uh, yeah, it works pretty good. But yeah, you, you, you need to know that it, it, it will spend a lot of, uh, lot of tokens.
- 17:43
And also, uh, for all of those problems, you need to remember that, uh, you need to give access to all kind of tools, uh, that is needed. So you need to have a log, trajectories and metrics, database, UI as, uh, so as the humans need, right?
- 17:59
So you need to give all context, all possibilities to understand what is happening. For example, for the computer use agents, when detect some problems, it, uh, should be able to, uh, analyze the trajectories, check the, uh, database to understand what happened.
- 18:16
And you know, that's why I'm calling it the meta harness, the whole system when everything is connected and, uh, the PR or the answer from the agents are, uh, depend on the, depend on the real problem and they're not guessing what is happening.
- 18:33
So the most, uh, is not the model alone. And you need to build, uh, the agent or a system or a harness around it, uh, which, which, uh, watch itself, understand, improve, and help you at least to, uh, at least to monitor what is happening.
- 18:50
But also in the ideal case, to close the loop, send, uh, automatic PR notifications wherever and, uh, help you to speed up the process. So shipping is the easiest part today.
- 19:03
Uh, if you want to ru-- If you want to build a production agent, you need to close the loop first because somehow people are not talking about how important it is, uh, what happens after you launch.
- 19:13
So everyone can have the same model, everyone can have the same agent or harness. But you need to have some internal system that helps you in this process, uh, detect the problems, uh, and give you a sense what is happening and helps to make the product better.
- 19:31
Thank you.