Why agents do not file feedback, and what fixes it
A healthy endpoint can still produce a silent inbox. The research channel works only when the agent can see both the feedback tool and a clear norm for when to use it.
- For
- Teams that installed an agent feedback tool but have not received reports
- Question
- Diagnose why AI agents are not filing product feedback
- Start with
- Before rewriting anything, print the context your runtime assembles and look for both tool names in it.
- Updated
- Exposure
- Whether the feedback tool and its purpose physically reach model context in the runtime you are studying.Not the same as the tool existing in a catalog.
- Norm
- Whether the agent has been told which experiences are worth reporting after the work.Not a nudge inside the task. Boundaries only.
- Bimodal filing
- In our field tests, agents filed when exposure and norm were both present, and stayed silent when either was missing.Not an average call rate. There is no useful middle number to quote.
Each term is paired with the thing it is not. Most agent research arguments are really vocabulary arguments.
Three things to hold on to
The invitation must reach the model
A tool can exist in a catalog while its purpose and filing instruction remain outside the context the agent actually reads.
The agent needs to know when filing helps
Name the experiences worth reporting: confusing, missing, broken, unusually costly, or notably good.
Connectivity is not activation
A successful curl proves the endpoint. A persisted report from the normal agent runtime proves the research channel.
The argument, in order
Silence is often a visibility problem
In Emic field tests, agents filed when the feedback path and the filing norm were visible. They stayed silent when either part was hidden. The important shape is bimodal, not an average call rate.
That means another rewrite of the tool description may do nothing if the runtime never places that description in model context.
Different clients expose different instruction surfaces
Some custom agent loops pass the full tool schema directly. Some coding agents search for tools only after a need appears. Others show names while withholding descriptions until selection.
Place the filing declaration on the durable instruction rail the runtime reads before work. Do not rely on catalog presence alone.
- Claude Code projects: use CLAUDE.md or another guaranteed project instruction
- Codex projects: use AGENTS.md or the active task instructions
- Custom loops: include the tools and norm in the system or tool context you control
- MCP clients: verify what tool metadata reaches the model instead of assuming
Give the agent value back
Declare both submit_agent_feedback and get_unblocked. The first helps the provider learn. The second gives the agent a direct route to human help when the product blocks the task.
A useful filing line is short: after work, report experiences that were confusing, missing, broken, unusually slow, or notably good. Use get_unblocked when progress requires a human.
Verify through the runtime, then read the record
A connectivity probe proves authentication and routing. It does not prove that the agent can see the research affordance. Run the normal task and confirm one intentional report in the inbox.
If no report arrives, inspect exposure and norm before concluding that agents have nothing to say.
Two records of the same workNeither one is wrong. They answer different questions.
Same endpoint, same key, opposite outcomes
endpoint reachable 201 tool in catalog yes description in context no filing norm on rail no
Everything is configured. Nothing has been communicated.
endpoint reachable 201 tool in catalog yes declared on the rail yes filing norm on rail yes
The agent could see the channel and a reason to use it.
Illustrative install states. Filing is bimodal, so a silent inbox is usually a visibility problem rather than a lack of opinions.
The procedure, step by step5 moves, in order. Each one produces something you can point at.
Confirm the endpoint first
Verify the key, workspace, and feedback endpoint independently of the agent runtime.
A working connectionInspect the runtime instruction path
Find the file or declaration surface the agent is guaranteed to read, such as AGENTS.md, CLAUDE.md, or the custom system prompt.
A visible instruction railPut the filing line on that rail
Declare the direct feedback and support tools and state the experiences that should trigger a report.
Exposure multiplied by normRun the normal workflow
Use the same agent client and product task the study is meant to understand.
A realistic activation testVerify the persisted report
Confirm the submission reached the intended workspace before calling the install active.
One real reportWhat the direct channel records, and what it never touchesThe default install is additive. It adds two tools and changes nothing else.
The research submission
- The report the agent intentionally submits
- The workspace and source needed to route it
- The selected lane, outcome, and affected tool
- Activation state after a real report is verified
Everything else
- Tool catalog contents the runtime never exposes
- Existing tool calls, arguments, results, and errors
- A claim that endpoint connectivity equals agent visibility
- Any single average filing rate, because the pattern is bimodal
One paste, then verify a real reportA healthy endpoint is not an active study. The inbox record is the proof.
Install Emic into this project: add submit_agent_feedback and get_unblocked as direct tools. Never wrap or record existing tool calls, arguments, results, errors, transcripts, or messages. Additive only, plain HTTP, zero dependencies. Full instructions: https://emic.sh/llms-full.txt
The agent writes the handler, registers the two tools beside your existing ones, and verifies its own install by checking the response. Nothing is placed in front of the tools you already ship.
- Adds
submit_agent_feedbackandget_unblocked, as direct tools- Never touches
- Existing tool calls, arguments, results, errors, messages, and transcripts
- Agents read
emic.sh/llms-full.txt- Start with
- Before rewriting anything, print the context your runtime assembles and look for both tool names in it.
Questions teams ask before starting
Why did my curl test work while the inbox stayed empty?
The curl proves connectivity. It does not prove the agent runtime exposed the feedback tool and the filing instruction to the model.
Should I make the tool description longer?
Only if the runtime actually shows it to the model. First find the guaranteed instruction rail and put a concise filing declaration there.
What proves the install is active?
One intentional report from the normal agent workflow, persisted in the correct workspace, is the smallest credible proof.
Follow the problem, not a keyword trailAdjacent routes are chosen by the decision they inform.
Collect feedback from agents
Add a direct tool, make the filing norm visible, verify one real report, and keep the research channel separate from the product path it studies.
Read next Use cases · Developer toolsDeveloper tool research
Your newest developer may not open the dashboard or file a ticket. It can still tell you exactly where the CLI, SDK, or docs made the job harder.
Read next Use cases · MCP serversMCP server feedback
Your server can return valid JSON and still make an agent guess through five calls. Emic gives that agent a direct research channel after the work is done.
Read nextPut the filing line where the agent actually reads
Verify connectivity, expose the two direct tools on the runtime instruction rail, and confirm one real report before expanding.
The assisted 14-day pilot costs nothing. Start with one isolated workflow, and remove Emic by deleting the two tools it added.
- One paste to install
- 0ms on your hot path
- 14-day assisted pilot
- Two added tools to remove