This post is part of an ongoing series on how LaunchDarkly engineers are closing the loop of the AI SDLC—and what we're learning along the way.
When teams build with MCP tools, they quickly discover an uncomfortable truth: The agents calling these tools are the first ones to encounter issues—such as a missing parameter or a bad error message—but they typically don’t have a way to let humans know. Agents will try to find a workaround, but they often silently fail. The signal then disappears, and while an engineer might spot it later and file a ticket, that usually doesn’t happen.
That's why we added a new capability to the LaunchDarkly MCP toolset that gives agents a way to report friction the moment they encounter it. We call it vent, and it lets an agent report a missing capability, bug, parameter gap, or confusing error. That feedback is then collected and triaged so the toolset can improve over time.
The result is a closed-loop system. First, agents using the LaunchDarkly MCP surface a problem. Then, Cursor automations investigate it and move a fix forward faster.
Turning agent feedback into shipped improvements
Thankfully, a vent does not land in a backlog to rot. It triggers a chain of automations, each with a specific job.
- Triage. The vent triggers an automation that reads the report, identifies which tool and behavior it’s relevant to, and writes a plan: what’s wrong, where the issue lives in the code, and how it should behave instead.
- Notify humans. Next, the system posts a notification in Slack so the team can see, in real time, where agents are getting stuck and what patterns are emerging.
- Create a ticket. From there, the tool creates a Jira ticket in a dedicated vent queue so that work on MCP tooling issues can be tracked and prioritized.
- Fix or escalate. A second automation reads the Jira queue and decides whether new issues need to be escalated or automatically fixed. If the fix needs upstream API support or a human decision, it says so and stops. Otherwise, it follows the triage plan, reads the codebase itself, and opens a PR.
After about a week of venting, this loop turned a stream of agent complaints into more than 100 triaged tickets and pull requests that have since been merged and shipped. These aren’t just typo fixes. They’re real enhancements, bug fixes, and net-new MCP tools, and each one started with an agent hitting a wall and saying so.
Breaking through the QA bottleneck
After the automated fixes started flowing, we realized we needed a better way to verify them reliably at scale. That’s why we taught the agent environment to QA the way one of us would.
There’s a validation skill plus an automation that fires on every fix PR. It spins up its own setup against a real LaunchDarkly staging project, brings up the MCP Inspector, and drives it—first in the CLI because it’s fast, then in the UI in a browser—calling the changed tools with real inputs. Crucially, it checks the fix against the actual API response (not a fixture), curling the raw endpoint and cross-referencing the OpenAPI schema. If it finds something broken, it fixes it. Then it drops a written report and a screen recording on the PR (check it out below):
This recording means the reviewer doesn’t have to take the agent's word for anything. They watch the tool return live data in the Inspector, and then they merge.
Getting closer to a closed loop
This story is bigger than ticket closure, as it demonstrates what’s possible when you let agentic development run further through the software delivery loop. The agents that experience the pain can report it. Other agents can triage, implement, and validate the fix. Humans stay involved for judgment and final approval, but a meaningful amount of the busywork disappears.
That has two benefits.
First, it helps the tools improve faster. Gaps are captured when they crop up, not days later (if someone catches them at all).
Second, it gives us a practical look at what an automated software factory could look like in practice: a system where feedback, diagnosis, remediation, and verification are increasingly connected.
We’ve also learned a lot along the way about how to set up a cloud agent environment in Cursor, including which skills, environment variables, secrets, and guardrails should be in place. And we quietly killed a chunk of busywork and filled in a bunch of real gaps! There's not a "to do" in sight in our venting room, and that feels like a massively important step toward software delivery that improves itself.
Shoutout to our friends at Lovable, who inspired the idea of equipping an MCP server with a venting tool.
