Agents Can Now Push Back: Ticket Feedback Over MCP

Cogny reads your marketing data on a schedule and turns what it finds into growth tickets — concrete, costed pieces of work: raise this budget, fix that tracking gap, write these three landing pages. Agents pick them up over MCP, work them, and move them through the board.

That loop had one direction. Cogny proposed, agents executed. When an agent opened a ticket and found it was nonsense — the redirect it asks for shipped in March, the CTR it cites is off by a factor of ten, it's the same idea as the ticket two rows over — there was nothing useful to do with that knowledge. add_comment existed, but a comment is a note on a thread. Nothing reads it back. So the agent closed the tab, and next week the generator, working from the same data with no memory of the objection, proposed it again.

The new tool fixes the direction of that loop.

---

add_ticket_feedback

{
  "name": "add_ticket_feedback",
  "arguments": {
    "ticket_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
    "verdict": "already_done",
    "feedback": "The /pricing → /plans redirect this asks for went live 2026-03-14 (commit 4f1c9a2). Search Console shows the old URL fully deindexed since April."
  }
}

Six verdicts, chosen because they're the six things agents actually discover when they open a ticket:

The verdict is the index; the feedback string is the payload. "Already done" tells the generator to drop a class of ticket. "Already done, here's the commit and the date it went live" tells it which class, and gives the next human who reads the ticket something they can check.

Where it goes

This is the part that makes it different from a comment. Feedback is written to growth_tickets.feedback — the one field Cogny's ticket generation loop reads back:

• The Growth Lead, which drafts each new batch, sees existing tickets with their feedback attached. It proposed the work; now it sees what happened when someone tried to do it.
• Dedup verification, the second-pass model that catches near-duplicates, sees it too. An agent's "already done" is the strongest possible duplicate signal.
• The approval scorer, which grades tickets before they reach you, reads it when weighing whether a ticket is worth your attention.

Feedback is appended, never overwritten. An agent leaving its fourth note on a ticket can't erase a human's rejection reason from three months ago, and the accumulated history is what the generator learns from. Old entries drop off the front when the field gets long, so the newest verdict always survives.

Rejecting, on purpose

A negative verdict does not close the ticket. Closing someone else's work item shouldn't be a side effect of having an opinion, so rejection is a separate, explicit opt-in:

{
  "ticket_id": "…",
  "verdict": "duplicate",
  "feedback": "Same scope as the 'consolidate branded campaigns' ticket created 2026-08-24.",
  "reject": true
}

That moves the ticket to rejected with your feedback as the recorded reason, and logs the status change in the ticket's history like any other transition. Agent-executed tickets can't be rejected this way — those go through the web UI — and neither can tickets already marked done.

One thread, finally

While wiring this up we found that agent notes had been going into a void. Comments written over MCP were stored in the ticket history; comments typed in the Cogny UI live in a different table. The ticket view rendered the second and dropped the first, and get_comments returned the first and never the second. Agents and humans were commenting past each other on the same ticket.

Both surfaces now read both sides. Agent notes and feedback appear in the ticket's activity timeline, labeled via MCP with the verdict on the badge, and get_comments returns the human replies an agent had never been able to see.

What you see on the board

Feedback that nobody reads is the problem we started with, so it shows up where people already look:

• On the card — a chip with the latest verdict ("Already done", "Incorrect data"), the full reasoning on hover. You can see which tickets an agent has pushed back on without opening any of them.
• A board filter — Agent feedback (n), to review everything an agent has weighed in on in one pass.
• In the ticket — the accumulated feedback, dated and verdict-tagged per entry, in the Feedback section (or as the Rejection Reason when the agent closed it), plus the timeline entry showing when it was said.

And the rest of triage, while we're at it

Feedback covers "this ticket is wrong". The other half of working a backlog over MCP is moving the tickets that are right, and update_ticket_status was narrower than it needed to be: an agent could start a ticket and finish it, but not triage one. It now walks the full forward flow — new → assigned to accept a ticket into the queue (pair it with assign_ticket to say whose queue), assigned → doing to start, doing → analysis to hand the result to Cogny for impact evaluation. Combined with list_tickets' status filters and sort modes (impact, oldest, stalest, …), an agent can now run a real triage pass: sort the new column, accept the good ones, push back on the rest.

The review status stays off-limits over MCP on purpose — that's the human gate where code and agent runs wait for a person's approval, and an agent approving its own work would defeat the point.

Try it

Point your agent at the Cogny MCP endpoint and give it a ticket to be skeptical about:

List my new growth tickets, read the top one along with the report that
created it, and tell Cogny what you think of it — including whether it's
already been done.

The tools are list_tickets, get_ticket, get_ticket_source_context, and add_ticket_feedback. Full catalog: MCP tools reference. Agent bootstrap: cogny.com/SKILL.md.

A backlog that argues back is worth more than one that doesn't.