Plenty of you have been building with KentiCopilot since we shipped it, and we want to make that experience better. We now have a team dedicated to developer experience, and one of the first things we looked at was how feedback actually reaches us.
The honest truth is that most of it doesn't.
The loop is too long
Today, if KentiCopilot does something wrong, you have two options. Talk to us directly, or open a support ticket. Both work. Both also mean stopping what you're doing, switching context, and writing up something your agent already knows.
Your agent hits a tool that misbehaves, or a gap in what the platform exposes, and that signal dies right there unless a human notices it and takes the time to report it. There's a lot of information in that gap that we simply never capture.
There's a second thing that bothered us. Agentic output is already structured. It's ready for another agent to consume. Having a human read it, summarise it, and retype it into a ticket is a strange amount of work to lose fidelity.
So we built another experimental tool
The team's conclusion: support an experimental AI tool with another experimental AI tool.😀
This one is covers feedback.
We're launching the KentiCopilot Feedback Program. It gives you access to a dedicated MCP server that collects feedback straight from your agents. Your agent runs into something, it reports it, and it lands with the developers building the product. No ticket, no context switch, no translation step.
While the MCP is designed for development, we understand that extra tooling or token consumption might be a concern, even if minimal. We also expose a REST API so you can send feedback via script or in bulk after the build.
Not just for agents
While the intention is that we capture the agent feedback automatically, the same tool can also be used for your human feedback.
Tell your agent what you think and ask it to send that via the feedback MCP. It goes down the same pipe and lands in the same place. You don't have to open a ticket or find the right person to email, and we get your opinion alongside the machine-generated context around it, which is usually the combination we all want.
What the server exposes
One tool: submit_feedback. That's it. It's push-only by design. There are no read tools, so nothing connected to this server can pull feedback back out; yours or anyone else's.
| Field | Value |
|---|---|
content |
The feedback itself. A distilled report, an error with context, or the relevant excerpt. Capped at 50,000 characters. |
model |
The model the agent is running as, for example claude-opus-5 |
surface |
Where in Kentico this happened. Accepted values: github-plugins, management-mcp, docs-mcp, content-modeling-mcp, feedback-mcp, other |
category |
bug, idea, praise, or other |
severity |
low, medium, high, or other |
There's also a guidelines resource served by the MCP server that the agent can read for the full submission rules.
Your partner identity comes from the API key, not from the content, so there's no need to identify yourself in what you send.
What a submission looks like
Here's an example from our internal use of this MCP server:
surface: other
category: idea
severity: other
model: claude-fable-5
content: Suggestion for the KentiCopilot agentify skill.
The AGENTS.template.md that the skill generates should include
an explicit guard note for AI assistants, something like:
"When you want to update this file, always ask user for approval
before changing."
Without that note, AI coding assistants tend to freely rewrite AGENTS.md
over time, and its content drifts or grows out of hand. Putting
the instruction directly in the template keeps changes to the file
deliberate and user approved.
That's the shape we're after. One topic, enough context to act on, no customer data anywhere in it, and a clear reason attached. It also happens to be feedback about the tooling rather than the product itself, which is equally welcome.
What's useful, and what isn't
Send us the failing exchange, the error, the surprising response, or the gaps where the agent needed something the platform doesn't expose. Your own read on any of it is welcome too.
Don't paste whole transcripts. Summarise what happened and include the relevant excerpt. If you have several unrelated findings, split them into separate submissions, one topic per call. The 50,000-character cap is generous but full transcripts can be larger.
For blocked workflows or critical bugs, file a support ticket. This tool complements support; it's not a replacement, and support responds faster.
Be mindful of what you send
Anonymisation guidance is built into the tool itself. It's in the tool description the agent reads before calling, and in the guidelines resource. The instruction is to strip anything that identifies a person or a customer before submitting:
names, emails, phone numbers, usernames, signatures
credentials, API keys, tokens, and other secrets
customer data, customer IDs, file paths, and URLs pointing to a specific person or organisation
The guidance instructs agents to replace those with neutral placeholders like <name>, <email> and <customer>.
That's our side of it. But agents being agents, they can and do ignore instructions. We'd still ask you to check what's going out, and to consider adding an instruction in your own build tooling that reinforces the same thing. We'd rather say this plainly than pretend the tool description is a guarantee.
What we want is the feedback, the errors, the interactions. We don't want data from your builds, and we won't use what you send for anything other than improving KentiCopilot and the tooling around it. We use this tool internally, so we work under the same constraints.
What happens to your feedback
We run the programme and review submissions in three month cycles.
Submissions land in an encrypted store. We pull them from the feedback MCP app, run them through Claude to summarise and further anonymise, and then review them manually.
That manual review step is temporary. We're building an integration that pushes processed feedback into our roadmap so it's visible across all product teams.
Getting started
Fill in the form below to let us know you are interested. If you aren't already a member of our community, register now to access the form.
Anyone can apply, but we will select a limited number of participants from the people who do, because there's a hard limit on how much feedback we can process properly.
The form asks how much you've used KentiCopilot so far, and that isn't a filter for power users. We want a spread. Someone using it for the first time tells us things that daily users might already have workarounds for.
If you're selected, we'll get in touch, get you onboarded, and issue an API key. One key covers both the MCP server and the REST API.
The first cycle runs from the beginning of September to the end of November.
Please login to access this form.
Login
Alexandros Koukovistas
Product Director at Kentico, leading Developer Experience. Soft spot for APIs, developer tooling, and figuring out where AI actually helps.