Can an AI Agent File Its Own Feature Requests?
Yes. If a coding agent is connected to an MCP server that exposes a tool for filing feedback, there's nothing stopping it from calling that tool the moment it notices something missing or broken, the same way it calls a tool to read a file or run a test. The tool doesn't know or care whether the caller has a keyboard. It takes a title, a description, maybe a severity, and it writes a row.
Whether it should run unattended is the harder half, and the honest answer leans conservative. Not without a human seeing it first, at least until you've built the dedup and confidence checks that make an agent's judgment as trustworthy as a person's. The Model Context Protocol's own spec agrees with the cautious framing. Its guidance on tools says that for trust and safety, "there SHOULD always be a human in the loop with the ability to deny tool invocations," and recommends clients show tool inputs before calling and confirm sensitive operations. Filing a request that a teammate later acts on is exactly that kind of operation.
+ ChatGPT
issue filedagent taskWhy the confirmation step is the real question
The interesting failure mode isn't the agent filing something dumb. It's the agent filing something plausible but wrong, at volume, because nothing pushes back on it. An agent debugging a flaky test might conclude the flakiness is a missing retry feature rather than a race condition in the test itself, and file a feature request that sounds reasonable and solves nothing. A human doing the same job would have the same failure mode occasionally; the difference is a human files maybe a few requests a week, and an agent running continuously across dozens of sessions can file dozens.
That argues for a specific shape, not a blanket rule. Let the tool call happen freely, since it costs nothing to record an observation. Route the result to a review queue rather than straight into the roadmap, the same "confirm before consequential action" pattern MCP's own security guidance recommends. And weight agent-filed items differently from human-filed ones in whatever counting or prioritization you do downstream, at least until you have enough history to know how often the agent's read is right. A reviewed queue also reveals something worth noticing once it's running for a few weeks. The items an agent surfaces while doing unrelated work tend to be a different population from customer-reported bugs. A customer says a feature doesn't do enough; an agent working in the code says a documented behavior doesn't match the actual behavior. Both are worth catching. Neither is worth catching automatically without a look.
What the tool call actually looks like
Mechanically, it's unremarkable. MCP tools are ordinary functions with a name, an input schema, and a result, and per the spec, "tools in MCP are designed to be model-controlled, meaning that the language model can discover and invoke tools automatically based on its contextual understanding and the user's prompts." If your MCP server exposes a file_feedback tool alongside your read_file and run_tests tools, an agent mid-task can decide on its own that the missing rate-limit header it just ran into is worth a ticket, and call it, no different than deciding a failing test needs a rerun.
Claude Code, Cursor, and any other MCP-speaking client can connect to custom tools like this today. Anthropic's own Claude Code documentation describes MCP as letting the agent "update tickets in Jira, pull data from Slack, or use your own custom tooling," which covers a homegrown feedback tool as much as it covers anything else on that list. The mechanism is not the hard part. Anyone comfortable writing an MCP server can add a two-field tool that appends to a queue in an afternoon.
What the agent actually notices tends to fall into a few buckets: an API it called that doesn't support a parameter a task obviously needed, an error message that describes a gap rather than a bug, a workaround it had to build because the direct path doesn't exist yet, or a customer-facing behavior it read about in a support ticket while gathering context and confirmed doesn't work as described. None of that requires new intelligence from the model. It requires giving the model a place to put the observation instead of discarding it at the end of the session, which is what happens today in the overwhelming majority of setups.
What that looks like in practice
Picture a team running exactly the setup above. Slipstream builds browser-based video review software that lets teams comment on cuts frame by frame. Callen Hoyt, a staff engineer there, runs Claude Code against a small internal MCP server that exposes the product's own API alongside a flag_gap tool the team added themselves, writing to a shared Linear view labeled "agent-noticed."
Callen had asked Claude Code to add support for exporting a comment thread as a timestamped transcript. Partway through, it called flag_gap three times in one session:
Claude Code: Filed
agent-noticed: the/exportsendpoint accepts aformatparam documented as["srt", "vtt", "json"], but the handler only implementssrtandvtt;jsonreturns a 500. Filed while implementing the transcript export, unrelated to this task's scope.
Claude Code: Filed
agent-noticed: no endpoint exists to fetch a single comment's reply thread without paginating the full comment list first. Built a local workaround for this task; flagging in case other export work hits the same gap.
The third was a duplicate of something already sitting in the human backlog, filed by a customer three weeks earlier in slightly different words. Because the queue was reviewed rather than auto-promoted, Callen caught the duplicate in under a minute and merged it instead of letting it sit as a second open item nobody would connect to the first.
Callen, afterward: "The JSON export bug is real, we would not have found it without someone specifically trying that param. The duplicate would have cost us nothing to catch by hand, but we've had agent sessions running unattended overnight, and unattended is exactly when a duplicate slips through."
Two of the three were genuinely new information the team wouldn't have had otherwise. One demonstrated exactly the risk: an unreviewed queue would have quietly doubled a request that already existed.
Three ways a one-tool setup falls behind
A single flag_gap tool writing to one Linear view holds up fine for one team on one codebase, checked by a human a few times a week. It falls behind in the same three ways any homegrown feedback system does, just faster, because an agent produces volume a person doesn't:
- Dedup against human reports requires the two streams to actually meet. Callen's third item only got caught because someone happened to remember a similar customer complaint. At any real volume, agent-filed and human-filed items live in different views maintained by different habits, and they drift apart instead of merging.
- Nobody tells the person who reported the same thing that it's already known. The customer who filed the JSON export bug three weeks before Claude Code independently rediscovered it never heard back, because the agent's discovery didn't know a human report existed to connect to.
- A queue with no priority signal grows forever. Ten flagged items a week that nobody weighs against actual customer volume becomes a hundred by the end of the quarter, and "agent-noticed" turns into a label everyone has learned to skim past.
That's the point where routing the agent's flag into the same aggregation layer your human feedback already runs through matters more than the filing mechanism itself. This is the seam Modem is built for. It watches the Slack channels, support tools, and GitHub or Linear issues a team already has connected, so an agent-filed gap posted into one of those channels gets classified and deduped against the customer report that already exists for it, instead of sitting in a separate queue nobody cross-checks. The Claude Code integration runs the other direction too, handing tasks back to the agent built from real customer quotes and topic data, so the same channel that catches an agent's flagged gap is also where the next task for that agent gets composed. Modem is our product. Treat that description with the skepticism you'd give any vendor describing its own tool; the mechanism, one aggregation layer instead of two disconnected queues, is worth adopting regardless of who builds it.
For the review-queue habit itself, our guide on triaging GitHub issues at scale covers the labeling and sweep discipline that keeps a growing "agent-noticed" backlog from becoming its own unmanaged pile. And if the question is less "should the agent file this" and more "what does the agent need to see before it starts," our piece on context engineering for AI agents covers the other half of the same wiring.
Practically, this starts small regardless of which layer eventually catches it: add one tool to whatever MCP server your agents already talk to, two fields, a title and a description, writing to a queue a human reviews at least twice a week. Don't wire it into your tracker automatically yet. The value shows up fast, in the "we wouldn't have found that" items; the risk shows up just as fast, in the duplicate that would have doubled a request already sitting three rows away. A reviewed queue catches both. An automatic one only shows you the first.
