Introducing Suggestions: user feedback that becomes a change request
Contributors can now send features, improvements, and fixes straight to your board, and follow what happens to them. Here is how Suggestions work.
Most product teams already collect feedback. The hard part is the distance between where it arrives and where decisions are made. A customer describes a problem in one place, someone copies it into a ticket, someone else rewrites it as a requirement, and by the time a coding agent picks it up, the original request has been paraphrased several times.
Suggestions close that distance. The people who use your product can now send requests straight into your Kairo project, and follow what happens to them.
Who can send a suggestion
Suggestions come from Contributors: customers, stakeholders, or domain experts you invite to a project. A Contributor gets one simple page to suggest improvements and follow what happens to their suggestions. They don’t see your internal workspace: not your specs, not your chats, not the rest of your board.
That boundary is the point. You can open the door to the people closest to the problem without opening your roadmap.
What a suggestion contains
A suggestion has the same shape as the work it may become: a title, a description, a type, and a priority. The types are the ones your team already uses for change requests: a feature, an improvement, or a fix.
The form also tells Contributors what to expect: the project team reviews every suggestion.
Your team decides
Each suggestion arrives on your change request board, in its own column, next to the work you are already defining and building. Your team accepts or declines it.
When a suggestion overlaps with a change request that already exists, it is merged into that change request instead of becoming a duplicate. Five customers asking for the same thing add weight to one request rather than creating five.
An accepted suggestion then follows the same path as every other change request: Kairo’s AI questions the intent, a skill turns the answers into a requirements document, and your coding agents read the result over MCP.
Contributors see what happened
Each Contributor follows their own suggestions through a simple status: submitted, accepted, done, or not accepted. When a suggestion was merged, they can see that it is tracked with an existing change request, so they know it was heard even though it didn’t create a new item.
That is the list at the top of this post. Nobody has to ask whether anyone read their request.
Why it matters more with coding agents
When agents make implementation fast, the expensive part is deciding what to build. Feedback is one of the best inputs to that decision, and it is most useful when it arrives where the decision is made: next to the specs, in the same flow, in the user’s own words.
We use it ourselves
The screenshots in this post come from our own project: we build Kairo with Kairo. The dictation fix in the form above is a real suggestion, accepted and tracked with an existing change request.