A talk by Raphael Kalandadze, co-founder and CTO of Wandero AI, on operating a production agent-based product where the operations team itself is composed of agents. Failures in an agent system appear in conversations rather than stack traces, so the company uses specialized agents: one monitors production conversations to judge where the agent let customers down, one watches logs and system health and traces problems to code, one writes and runs tests to address the limits of green CI for non-deterministic agents, and one reviews PRs for root-cause fixes. Humans remain at merge and approval boundaries. The talk covers what each operating agent checks, where the team trusts it and where it doesn't, and why operating agent systems is becoming its own engineering discipline. # Channel Identity Observations — "The Missing Layer After Launch" (Raphael Kalandadze, Wandero AI) ## Explicit Self-Description Evidence - The speaker identifies himself via the title and company: **"Raphael Kalandadze, Wandero AI"** (from video title). - He positions the talk around a named concept he coined for the audience: *the missing layer* — **"And I'm calling it the missing layer."** - He repeatedly anchors claims in his own team's practice, implying a small team: **"the PR agent and the review agent send 10 times more PR than the three of us every day."** - He claims ownership of his tooling choice: **"Actually we built it ourselves... I prefer to build it myself because I know what I'm interested in, what I'm looking for."** ## Intended Audience - **Builders and operators of production AI agents**, specifically those past the launch stage: > "You built an agent, you launched it, everything works pretty well in a demo... how do you know if it's actually working out there?" - Practitioners familiar with the current tooling ecosystem — references to **"Claude Code or Codex"**, **Anthropic blog posts**, **LangSmith ("Harrison"** — likely Harrison Chase of LangChain), and **Slack alerts** suggest a technical, insider audience. - People at startups/small teams, given references to **"the three of us"** and rapid building: **"you can create the whole product, you can create a whole startup in a couple of days."** ## Claimed Scope of the Talk - **Post-launch operations of agentic systems** rather than building: > "Most of the talks about the agents end up the moment when you ship... But I think the shipping is the moment when the real work begins." - The scope is framed as a gap in industry discourse: **"only a few people are talking about that."** - Concrete scope includes: why agents are hard to monitor, why classic testing fails (**"We build the unit test. We had some regex, some rule-based checks... it is like only one slice of the whole problem"**), and an end-to-end architecture he calls a **"meta harness."** ## Demonstrated Presentation Patterns (Observable) - **Conference/talk format**: rhetorical opening questions, structured walkthrough with slides ("this is one example how the PR can look like," "this is the example how a static analysis can look like"). - **Practitioner-depth demonstrations**: detailed architecture descriptions of four systems — a log-monitoring agent (runs "every hour... on the one hour window of the logs"), a review/critic agent, a session analyzer dashboard (health scores, sentiment, entity extraction), and a computer-use agent testing the UI. - **Transparency about limitations**: **"Everything is not optimal, but I think this will help you to get some point"**; also notes costs — **"it will spend a lot of tokens."** - **Opinionated stances grounded in experience**, e.g., on human-in-the-loop: **"the trend is that you need to close the loop first... then you can remove yourself pretty easily."** ## Notes on Distinguishing Claims from Demonstration - The creator *claims* the feedback loop is "at least as important as the product itself, sometimes even more" — a stated opinion, not demonstrated. - The dashboard and agent workflows are *demonstrated via slides/description* ("this is just an anonymized data, but it comes from real conversations"), but effectiveness ("it works pretty well") is a self-report, not independently verified in the material. # Delivery Observations: Raphael Kalandadze — "The Missing Layer After Launch" ## Tone & Overall Style - **Conversational, informal talk delivery**: frequent fillers ("uh," "um," "you know"), false starts, and self-corrections appear throughout, e.g., "Uh and uh from my experience, the loop is uh at least as important." - **Direct audience address**: opens with a second-person scenario — "All right. So, you built an agent, you launched it, everything works pretty well in a demo." - **Rhetorical questions as structure**: "How do you know if it's actually working out there? How do you watch across hundreds or thousands of real conversations every day?" ## Recurring Phrases & Verbal Anchors - **"So," as a sentence opener** — extremely frequent, appears in nearly every paragraph ("So, let's dive into it," "So, why this is a new problem?", "So, actually you don't know what you're looking for"). - **Repetition of the core thesis**: "the shipping is the moment when the real work begins" is stated twice, at [23] and [54], and echoed in the closing "shipping is the easiest part today." - **"As I mentioned" / "as I mentioned"** — repeated callback phrase: "And as I mentioned, the unit test don't save you here," "as I mentioned the review agent is uh, pretty critical." - **"right?" as a checking tag**: "the agent is not a normal software, right?", "All right. so what happens after you launch the product, right?" - **"You know" as a connective**: "And you know, this is a early warning for you," "But, you know, still human in bottleneck in this case." ## Teaching Habits & Structure - **Problem → why it's hard → solution walkthrough**: sets up the gap ("most of the talks about the agents end up the moment when you ship"), explains difficulty, then walks through his system in labeled parts. - **Concrete example anchoring**: uses a real product case to illustrate abstract failure — "user asked to build an itinerary. Agent run the flow. It built the trip... So, technically it's successful but still failing the task." - **Enumeration of components**: presents a clear two-flow split — "we have a two main flow. The first one is the the fastest loop... And the another one is like more on a zoom out." - **Demo-style narration**: "let me let me show you. One of the example how how it looks like," followed by feature-by-feature listing ("we have the health of the system, we have number of sessions..."). - **Honest caveats about his own work**: "Everything is not optimal, but I think this this will help you to to get some point." ## Vocabulary & Register - Practitioner/engineer vocabulary: **trajectories, logs, unit tests, regex, tool calls, sub-agents, PRs, code base, tokens, DOM**. - Naming/branding habit: coins terms for concepts — "the missing layer," "meta harness," "the fastest loop." - Cites external authority: "as an Anthropic mentioned in the blog post, sometimes the agent love to make marketing features as complete." ## Communication Patterns - **Short emphatic restatements for emphasis**: "And that's the missing layer, and that's what the rest of this talk is all about." - **Humor through mild personification of agents**: "most of the agents are pretty eager to send the PR. They love to fix the problems." - **Anticipates audience objections**: raises and addresses the human-in-the-loop debate directly: "sometimes people talk about that if we need to have a human in the loop." - **Quantifies claims with personal/team data**: "the PR agent and the review agent send 10 times more PR than the three of us every day." ## Uncertainty Notes - The transcript shows no audience audio, so **pauses, laughter, or visual-demo timing cannot be assessed**. - Whether gestures or slide mechanics accompanied phrases like "let me show you" is not observable from text alone. - The "10 times more PR" figure and personal anecdotes ("The part that keeps me up all night") are taken as spoken claims, not independently verifiable. # Position Record: "The Missing Layer After Launch" — Raphael Kalandadze, Wandero AI ## Central Thesis Kalandadze argues that **shipping an agent is when "the real work begins,"** not the finish line. Most talks about agents end at launch, but post-launch monitoring, understanding, and improvement constitute a **"missing layer"** that few people discuss. - **Key claim:** The feedback loop is "at least as important as the product itself, sometimes even more," because tight feedback is what makes the product better every day. ## Why Post-Launch Monitoring Is Hard for Agents The speaker attributes the difficulty to several properties of agentic systems: - **No predefined flow or testable coverage** — unlike normal software with features and buttons, agents (he cites Claude Code and Codex) handle a giant range of tasks; "you cannot write all the conversations in advance." - **Non-determinism** — LLMs produce different paths from the same input; slight input changes alter trajectories. - **Hidden failures** — the "scariest" problem: agents struggle mid-task, recover via luck or workarounds, and no red alerts appear. He states reliable agents "shouldn't depend on the luck." - **Citing Anthropic:** agents sometimes mark tasks complete without verifying they actually worked. - **Large tool surface** — long-running tasks involve hundreds of tools, sub-agents, summarizations, terminal use, third-party services. - **Success ≠ helpfulness** — example: an agent built a trip itinerary but used the wrong service and miscalculated prices; "technically it's successful but still failing the task." - **Lost feel for the system** — he calls this "the part that keeps me up all night." **Stated experience with failed safety nets:** unit tests, regex checks, rule-based checks, and simulated customer conversation scripts — these help but cover "only one slice" because customers always behave differently. ## His Team's Solution Architecture ("Meta Harness") ### 1. Log Monitoring Agent (fast loop) - Access to trajectories, logs, and code base; runs every 15 minutes or hour. - Deep-dives logs, detects stuck users, sends PRs or Slack alerts. - PRs include descriptions, metadata, mermaid/ASCII diagrams, HTML artifacts. ### 2. Review Agent (fresh-context critic) - Separate agent with fresh context that criticizes and scores PRs, runs focused tests, requests changes or closes PRs. - Rationale: "most of the agents are pretty eager to send the PR." - PR and review agents send **10× more PRs daily than the team's three humans**. ### 3. Human in the Loop - Currently retained; PR descriptions/artifacts let him review in minutes. - Position: "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." - Qualification: "I think at this time it's okay but maybe we'll remove it in the future." ### 4. Session Analyzer (high-level zoom-out) - Scores every conversation, detects patterns, "connects the dots," produces health metrics: sessions analyzed, cost, average score, success rate, trends, sentiment, entities, tool-call analytics. - Built in-house rather than with existing tools: "I prefer to build it myself because I know what I'm interested in." - Run weekly or semi-weekly; purpose is high-level oversight, not fixing specific bugs. ### 5. Computer Use Agent (user perspective) - Opens browser, logs in, simulates the customer; catches UI problems logs can't. - Generic browser use (Codex) was slow, so they built a faster skill tailored to their site's DOM. - **Qualification:** "it will spend a lot of tokens." ## Broader Claims and Qualifications - **Logs are the source of truth**, and machines explore them far better than humans — but building the operating agent "is not as easy as you imagine"; it requires real reasoning to distinguish bug vs. noise, symptom vs. root cause. - **Reflexive point:** "operating the agent itself is an agent problem." - **Context access matters:** agents must get tools, trajectories, metrics, database, and UI access — "as the humans need." - **The model alone is not enough:** one must build "a harness around it, which watches itself, understand, improve." - **Strategic claim:** since "everyone can have the same model," the internal post-launch system is the differentiator for production agents. - **Honest caveats:** his setup is "not optimal"; visibility is "the easiest piece"; some companies provide similar systems commercially. ## Sources Cited by Speaker - Anthropic blog post (agents marking tasks complete without verification) - Examples: Claude Code, Codex # Video Attribution & Provenance Record ## Video Identification - **Title:** The Missing Layer After Launch - Raphael Kalandadze, Wandero AI - **Video ID:** `01a15ca8-d5e9-78e1-a053-0ad20ae8e247` - **Format:** Single-speaker conference/talk-style presentation ## Speakers & Roles | Speaker | Role | Evidence | |---|---|---| | Raphael Kalandadze | **Creator / Presenter (sole speaker)** | Named in title; delivers entire monologue, uses first person ("we tried a few stuff", "we built it ourselves") | - **No guests, narrators, or other identified speakers** appear in the transcript. - Speaker self-identifies as part of a small team ("the three of us") at Wandero AI (per title metadata). ## Referenced Sources & Third-Party Claims - **Anthropic blog post** (unspecified): speaker attributes a claim — > "as an Anthropic mentioned in the blog post, sometimes the agent love to make marketing features as complete without checking they actually worked." - No title, URL, or date given in transcript. - **Harrison** (referenced once, incomplete sentence): "And Harrison for it in the same way." — identity and source of reference unclear; likely garbled/verbatim transcript artifact. - **Named tools/products mentioned as context** (not sources): Claude Code ("cloud code"), Codex, Slack (alerts), browser/DOM-based computer-use agents. - **Own company artifacts:** internal dashboard, log monitoring agent, review agent, session analyzer — speaker states data shown is **anonymized real conversation data**. ## Promotional Segments - No explicit promotional segments detected. Speaker describes **his own team's internal tooling** in detail, which functions as a de facto showcase of Wandero AI's practices, but no direct product pitch or sponsorship is stated in the transcript. ## Availability & Uncertainty - **Comment availability:** not stated (no metadata supplied). - **Curated metadata:** none supplied beyond title. - **Ambiguities:** the "Harrison" reference is fragmentary; the Anthropic blog post is cited without enough detail to locate. 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. 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? 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 up the moment when you ship. So, apparently it did work, the end. But I think the shipping is the moment when the real work begins. And somehow only a few people are talking about that. And I'm calling it the missing layer. So, let's dive into it. So, that's the world that we're living. So, you can create the whole product, you can create a whole startup in a couple of days, in a couple of weeks. You can write 100,000 of lines of code. You can spend a lot of tokens. And to be honest, it is the easiest part today with the help of the latest models. 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. 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 product better every single day. 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. 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. So, let's talk about why this is hard and why this is hard now. So, the agent is not a normal software, right? You You don't have a few features and several buttons. You don't have a predefined flow that you can test before you go to the to the live. Uh and the coverage is endless. So, think about like cloud code or codex, they can do a giant range of stuff whatever user needs and most of the agents do the same, right? So, you give the instructions and they can handle it. And you cannot write all the conversations in advance. So, this leads to a detailed part of the problem. The part that keeps me up all night. Which is you lose the feel for your own system. So, after you build the product, you need to have some kind of understanding, does it get better or worse? So, we need to monitor and understand what is happening. And the problem is that the normal the normal safety nets don't save you here. Uh and believe me, we tried a few stuff. We we we build the unit test. We had some regex, some rule-based checks. We even created some scripts to simulate the customer conversation. Uh and yeah, it helps in some ways. Uh but at the end of the day, it is like only one slice of the whole problem. Because customers always do something different. Uh you cannot write it all down. They are too many and they are all different. And Harrison for it in the same way. So, you don't know what your agent will do until it is in the production. So, why this is a new problem? So, as you know, LLMs are not deterministic. The same input can have a different path. Even slight modification of the input can cause a different trajectory and the coverage is endless. You cannot list it all down. You cannot pretest until you go in the production. The second and the scariest one is the failure height itself. So, let's think about what happens when the agent is running for a long time. It struggled in the middle of a task. Uh it has some problems but it was lucky. Uh it was recovered. It finds some workarounds. Uh try some other tool calls or whatever. And you don't get any red alerts, any problems on a dashboard. 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. And uh you need to fix it as soon as possible because if you're talking about uh reliable agents, uh it shouldn't be depend on the luck, right? And uh also as an Anthropic mentioned in the blog post, sometimes the agent love to make marketing features as complete uh without checking they actually worked. The next one is uh the tool calling, right? So, the tool surface is a huge. So, long-running task needs a hundred of tools and thousands of tools. Um sometimes it have a uh several summarization in the middle. 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 pretty different way uh all the time. So, actually you don't know what you're looking for. So, sometimes finish doesn't mean it is helpful for the user. Maybe there was any there wasn't any problem. So, agent finished, everything looks good. The answer was successful. But what happens like for example for our use case, sometimes uh user asked to build the itinerary. Agent run the flow. It built the trip. But it took a different service. It made a lot of mistakes in the calculating the price. So, user is not happy. So, technically it's successful but still failing the task. And as I mentioned, the unit test 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. All right. so what happens after you launch the product, right? So you need to monitor and you need to understand and improve the system. Uh and what's the source of the truth, right? This is a log. 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, taking rise and 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 needs a lot of reasoning. You need to understand the problem to uh differentiate if it's a real bug or a noise, to deep dive into the fresh trajectory, understand if it's a a symptom or a root cause. So actually, you'll find out that the operate operating agent itself is an agent problem. So this is a look like end-to-end. So we have a traces, you have trajectories, you give the agent to access the code base. It diagnose the problem, understand what is happening, and send the PR. And then you can have a skill or sub-agent or or whatever that controls the PR uh because you know, most of the agents are pretty eager to send the PR. They love to fix the problems. We prefer to have a separate agent which has a like fresh context. It try to check um the PR on different angle, on different view, run the um the focus test. And uh it is not biased of the problem itself. It tries to criticize call the PR. And uh sometimes it uh requests the changes. Maybe it close the PR directly and it helps us to to filter those problems. Uh and uh 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 a pretty obvious for most of the people. And uh a lot of teams use the same practice, but I think people don't appreciate how important it is, and you you need to spend some time on that. 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, you know, after you build this simple uh simple system, you uh already have the feeling and understanding how behaves, what is happening. You detect the problem, some local fixes as soon as possible, 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. Everything is not 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. And the another one is like more on a zoom out that that helps you to have a on a high-level understanding, and it helps you to have hand on a pulse. So, the first one is a log monitoring agent, the one that I already mentioned. So, you have trajectories, so we have logs, we have the access to a code base, and it runs every hour or uh uh every few 15 minutes, and it try to understand the problem. It deep dives in the in the logs, uh understand does the user user end up stuck, and uh send the PR, or sometimes send the Slack alert. And this is this is pretty uh important because sometimes the problem is uh, uh so critical so we need to fix them as soon as possible and yeah, it works pretty well. 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 a nice diagrams, mermaid or ASCII tables, maybe you will have some HTML artifacts that helps you to give you a glance of the problem and quickly understand what is this PR for. So, this is the example how a static analysis can look like. It helps you to quickly give you a feedback, detect if there are some critical problems. Sometimes it it is just like heads-up or you know, there are some warnings, there are some problems so you need to check them when you have some time. And as I mentioned the review agent is uh, pretty critical because it tried to check the problem in different angle. It always tried to criticize the problem, score the problem and as soon as it's ready, it send the PR to the human. And sometimes people talk about that if we need to have a human in the loop because you know, still human in the bottleneck in this case. In our case the the the the PR agent and the review agent send 10 times more PR than the three of us every day. So, we need to have some clean system how we're going to 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 nice description, some artifacts that helps me to quickly understand the problem 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'll remove it in the future. And yeah, people are talking about that so you need to you need you don't need to be a person like in this problem. Some of them prefer to remove the humans in this loop. 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. So, this is our some examples how the review agent feedback can look like. As you know, it requests some changes, you have some summary, you have some diagrams, explanation, what are them some risks, some edge cases. And sometimes after a few iterations of the code in the loop where the key where the key is ready, so we don't need you don't need to have any more changes. So, after that the human will jump into the loop. For the previous agent as I mentioned, that is especially good when you want to fix some local problems. For our case, it runs every hour with the chance on the one hour window of the logs and it doesn't have any high-level understanding of the problem. So, we found found out that we need to have another system that helps us to to get to get like more than high-level explanation, some kind of a health of the system. And you know, visibility is the easiest piece. Before the agent, it was impossible, so you cannot deep dive or summarize some of the top conversations. But right now, we can have a system that helps you to to score every conversations, understand what's happening and give you a high-level summary of the system. 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 conversation, runs a lot of state agents, it spend a lot of tokens, but yeah, it helps us to detect some patterns connecting the dots and try to understand some high-level patterns. And yeah, it also detects some like logical problems, what is the cause, how many tool calls did you use, how many sub-agents, how many summary happened or whatever. But also it gives some AI insights, some entities, so you have an understanding of the problem. So right, as I mentioned, one of the main problem is that you lose the control of the user 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 healthy or what or not. So Actually, let me let me show you. One of the example how how it looks like. So actually we built it ourselves, so there are a lot of other companies and tools that provide the same kind of system, but I prefer to build it myself because I know what I'm interested in for, what I'm looking for. So as you can see, we have the health of the system, we have number of sessions that were analyzed, the cost, we have the average score, some success rate. We have some trends, we have the AI insights, and this is the most important part when the AI when the agent try to connect the dots, find the patterns. 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, how many sessions affected, and some recommendation fix. So right now this is just a anonymized data, but it comes from a from a real conversations. So we have a score distribution, each company number of sessions or cost we have, the sentiment analysis, some entities, we have analytics about tool calls, all the success rate, how many rejected and why. And you have a detailed analysis of the each session. So, it ranks each one of them, scores. It is 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, what was the problem. It is something that you need attention, and believe it helps a lot, and it helps you to check and watch across hundreds of uh conversations. So, the main goal of this dashboard and the system is not to fix some uh um specific problems or bug. This is more than a high-level that helps you to watch across hundreds or thousands of real conversations. 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 problem. The second one is to give you a high-level understanding, but both of them works 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? So, that's why we have some computer use 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. You need to um check if everything looks good. Uh and uh yeah, sometimes code and logs cannot help you uh in this way. So, this is uh example how it looks like. So, you used Codex uh sometimes. So, it used um uh the browser itself. Uh Actually, this is pretty slow. Uh and we try to build a specific skill that know our uh website, our DOM, how it looks like, and that is much faster, and it can open the website, login, open the sessions, send the messages, check what is happening. Uh, and also check, how it looks like, what what are the some artifacts. And, yeah, it was pretty good. But, yeah, you you you need to know that it it it will spend a lot of a lot of tokens. And also, for all of those problems, you need to remember that, you need to give access to all the kind of tools that is needed. So, you need to have a lot of trajectories and metrics, database, UI, so as the humans need, right? So, you need to give all context, all possibilities to understand what is happening. For example, for the computer use agent, when detect some problems, it should be able to analyze the trajectories, check the database, to understand what happened. And, you know, that's why I'm calling it a meta harness, the whole system, when everything is connected, and the PR or the answer from the agents are depend on the depend on the real problem, and they're not casing what is happening. So, the most is not the model alone, and you need to build the agent, or a system, or a harness around it, which which watches itself, understand, improve, and help you at least to at least to monitor what is happening, but also in the ideal case, to close the loop, send automatic PR, notifications, whatever, and help you to speed up the process. So, shipping is the easiest part today. If you want to 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 what happens after you launch, 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, detect the problems, and give you sense what is happening, and helps to make the product better. Thank you.