When an AI agent fails, your first instinct is probably to open the logs. You spend some time scrolling through traces, screenshots, and tool calls like a detective, reviewing security footage, trying to piece together where it all went sideways. But this footage only shows you what happened. It rarely tells you why the task was harder than it needed to be.Now picture a new hire who gets stuck on their first day. You could review hours of hallway video to reconstruct their confused wandering, or they could just tell you, "Nobody gave me a login for the billing system”. One of those is a lot faster.Most AI agents are only capable of giving you the footage. They fail quietly, and then you’re left to reverse-engineer the reason behind what went wrong. But what if we let the agent do the other thing and simply complain? Lovable popularized this idea by giving its agent a "vent" tool, which is basically a dedicated channel where the agent can speak up when the tooling or the platform get in its way.At QA.tech, we have been exploring the same idea for testing agents, where a complaint can expose issues with the product, test setup, and tools long before a human notices anything.TL;DR Not every agent failure is the model's fault. Sometimes the instructions are unclear, the context is not provided, or there is no proper tool. You’ll likely reach out for the logs, but they will only tell you what the agent did. A complaint, however, could reveal what exactly was missing.Not Every Failure Is the AI's FaultWhen an agent fails, the screen usually just says one word: failed. No surprises there, but actually, there’s a lot hiding beneath.Maybe the agent misunderstood the instruction and went down the wrong path. Maybe it had the right idea, but the context was wrong. Maybe it needed to do something the available tools were incapable of. Or the product itself may have been so hard to navigate that no amount of cleverness would have saved the run.Lovable sorts stuck agents into two categories:Stuck in a way that better information or a better prompt would fixStuck in a way that no prompt can fix, because the tools and context are just not thereWith the first one, there’s a clear context problem. The second one, though, seems to be an environment problem, and no smarter model is going to solve it.Here is a real example from QA.tech. A customer shipped a feature that lets users ask the chat agent to manage teams; things like adding a specific person to a specific team, for instance. The agent understood the request perfectly, but when it came to actually doing the job, it had no way of finding the team ID it needed as input.When the agent can complain, it can verbalize the issue by saying something like, "I understood the task, but I could not find the team ID I needed, so I had to hack my way around it”. Suddenly, the fix becomes obvious, and it’s miles away from the simple “the agent failed”.What Logs and Complaints Tell YouLogs, traces, and screenshots are genuinely useful. The problem is that they are basically a long story you have to read backwards, and that’s rough for anyone who isn’t deeply rooted in the system.A complaint works differently. Instead of leaving behind evidence, the agent summarizes its own frustrations in plain language. It’s no longer a mere "the tool has returned an error." Instead, you get something like "I could not reach the ID I needed to finish this task.”To be clear, though, this doesn’t replace your logs. A test run already gives you the full journey: the agent's reasoning, screenshots, video of what it did, tool calls, all that jazz. The complaint just sits on top of all that and points at this one thing the footage rarely makes obvious.The main reason why this is so useful is speed. According to Lovable, users who get stuck early are four times more likely to abandon the platform. The faster you can tell why someone (or something) got stuck, the faster you can keep them from walking away.Here’s what the same old "failed" screen can be translated to:What the Screen SaysWhat Might Be Going OnWhat Actually Fixes ItFailedThe agent misread the instruction.A clearer prompt or better contextFailedThe agent needed an ID it could not find.A lookup tool or exposing that IDFailedThe right action had no matching tool.A new tool or permissionFailedThe product flow was buried or indirect.A change to the product, not the agentWhy This Matters More for Testing AgentsWhile a regular agent is just trying to get the job done, a testing agent wants to answer an important question: does this product actually work the way a user expects it to?Say the agent stalls while checking out or midway through onboarding. From the outside, it looks like a plain test failure. But the complaint might reveal something more useful: an unclear UI state, a missing role or permission, an ID that the agent had no way to grab, or a flow so roundabout that no one could reasonably verify it.This is where a lot of QA goes wrong. While a wall of green, passing tests feels like quality, it really isn’t. You can rack up hundreds of passing checks and still never come near the flows your customers care about. A complaint is much more useful, as it lets the agent go beyond pass or fail and tell you exactly where it got stuck.At QA.tech, these complaints go privately to the engineering team, not the end users. That means the agent can be blunt about missing tools and ugly workarounds without messing up the customer's experience. Convenient, isn’t it?Agents That Help Fix Their Own WorkplaceWhen we want an agent to be more reliable, our first instinct is almost always to reach for a better model or a better prompt. And don’t get me wrong, those do matter. But they are not enough on their own. An agent's success rides just as much on the tools it runs on, the context it has, the shape of the product, and whether anything is paying attention when it struggles.The next step toward agent reliability is to stop treating it as nothing more than a task runner. A well-built system goes beyond measuring whether the job got done and notices where the agent struggled with environment and what slowed it down.Another great thing about complaints is that they compound over time. So, if you collect them and feed them back in, they become the system's memory.As you can see, letting an agent complain may sound like an insignificant feature at first, but in reality, it’s the start of the feedback loop that makes agent systems more reliable and trustworthy.Built for Complex ProductsQuick context: QA.tech is an agentic QA platform where QA agents test your product the way a real user would. You describe what a flow should accomplish in plain English, and the agents work out how to run it, adapting when the UI changes rather than breaking the way recorded scripts do. That difference matters most on complex products.The more interconnected flows, states, and surfaces an application has, the faster a suite of recorded scripts turns into maintenance debt, since every UI change ripples through dozens of brittle selectors.QA agents handle that complexity differently: they reason about intent, so a single test can run end-to-end across the web app, the API, and mobile, and the agent's understanding of your product compounds over time through a behavior-based knowledge graph. The harder your product is to test, the more that adaptive, intent-based approach pays off.Frequently Asked Questions (FAQ)Isn't a "vent tool" just logging with extra steps?No. Logs record what the agent has done. A complaint is the agent explaining, in plain language, what it was missing or what has made the task harder than it should have been.Won't the agent just complain about everything?A single complaint is easy to ignore, and it should be. But when the same complaint appears across many runs, it becomes clear there’s a real issue that needs to be addressed.Do these complaints go to my users?Not at QA.tech. They are routed straight to the engineering team, so the agent can be honest about missing tools without it affecting the user experience.