How to Prioritize Feature Requests With an AI Agent (a Real Run)

To prioritize feature requests with an AI agent, write your scoring rubric into the prompt, connect the agent to the place your requests and tasks live, and let it count who asked, score each task and change only the priorities the rubric disagrees with, leaving a comment that explains each change. You review the comments and keep the decisions that need you.

I ran exactly that on 17 October 2026, from Claude Code connected to the LotsTeam MCP server, on a demo project. Below are the rubric, the prompt, the real tool output (trimmed), the scoring table and a prompt you can copy. In LotsTeam a "post" means a piece of product feedback: a feature request, a bug report or a question. A task is the work you plan to do about it, and posts link to tasks.

What I prioritized

The project is "Demo App", a demo project I keep for runs like this one, for a made-up appointment booking app. The feedback is sample feedback I wrote, so no real customer is in it. Six days earlier I'd had an agent triage the same project: it read 14 posts, grouped the duplicates and created tasks with a first-guess priority each.

That first guess is where most backlogs stop. Priorities set during triage are set one post at a time, before anyone compares the tasks against each other. So this run starts from the board as it was:

• six open tasks: Outlook and Microsoft 365 calendar sync (high), time zones in confirmation emails (high), SMS reminders (medium), a buffer-time bug (medium), a self-serve reschedule link (medium) and CSV export (low)
• each task linked to the posts that asked for it, plus comments such as "+1. I lose about two appointments a week to no-shows."
• zero votes anywhere, so the agent had to count people from posts and comments, not from a vote total

The urgent booking-page bug from the triage run was already done, and two leftover test tasks were done too, so none of those were scored.

The rubric

I kept it small enough to fit in a prompt and to check by eye. Four factors, small whole numbers:

Score = reach + pain + revenue − effort. 4 or more is high, 2 or 3 is medium, 1 or less is low. Urgent is never set by the rubric: it means users are blocked right now, and that's a call I make myself.

The effort guess is the weakest number, because the agent is reading a request, not your codebase. That's why every change comes with a comment showing the four scores: if the effort guess is wrong, you can see it and overrule it in one glance.

The prompt I used

Prioritize the open tasks in my LotsTeam project "Demo App".

1. List the tasks with status todo. For each one, read its linked posts
   (list_linked_posts) and the comments on those posts, and read the task's
   own comments for duplicate posts that point at it.
2. Score each task:
   - Reach (1-3): people who asked. Count each post author, each +1 comment
     and each vote once. 1 = one person, 2 = two or three, 3 = four or more.
   - Pain (1-3): 1 = nice to have, 2 = recurring manual work or a bug with a
     workaround, 3 = their clients get a wrong result or can't use it.
   - Revenue signal (0-2): 0 = none, 1 = lost money is implied,
     2 = someone says it blocks buying or switching, or they'd pay.
   - Effort guess (1-3): 1 = a day or two, 2 = a few days, 3 = a week or more.
   Score = reach + pain + revenue - effort.
   4 or more = high, 2 or 3 = medium, 1 or less = low. Never set urgent.
3. Where the score disagrees with the current priority, change it with
   update_task and add one task comment: old -> new, the four scores and
   the evidence. Change nothing else.
4. Don't edit posts, don't assign anyone, don't put anything on the public
   roadmap, don't publish a changelog and don't reply to anyone.
5. Finish with a table: task, reach, pain, revenue, effort, score, old and
   new priority. Then list what needs a decision from me.

Rule 3 is the important one. Without "change nothing else", an agent that has just read every post will helpfully retag them, reword task titles and answer questions on the portal. Rule 4 keeps the run invisible to customers.

What the agent did, step by step

1. Read the tasks and who asked for each

It called list_tasks on the project (nine tasks, six of them todo), then list_linked_posts on each task. The calendar task came back with three posts, from Priya, Dana and Marco. The SMS task came back with one, trimmed:

{
  "posts": [{
    "id": "f3281ec0-fab3-475b-a634-5f0bc28e5fa7",
    "title": "SMS reminders before appointments",
    "upvotes_count": 0,
    "comments_count": 1,
    "user_name": "Lucas (sample)",
    "priority": "medium"
  }]
}

2. Read the comments for the people the links miss

Linked posts aren't the whole picture. list_post_comments on Lucas's post returned a +1 from another user, and list_task_comments on the SMS task returned the triage note pointing to a second post asking for the same thing:

list_post_comments(f3281ec0)
{"content": "+1. I lose about two appointments a week to no-shows.", "is_admin": false}

list_task_comments(6939dc95)
{"content": "Triage: duplicate of the linked post (SMS reminders before appointments,
f3281ec0): \"Text clients a reminder the day before\" (b14bfa15). Plus a +1 comment
on the main post. Three people in total."}

That second post is Aisha's, and it says "I'd pay extra for it". So the SMS task has three people behind it, not one, and a direct revenue signal. A count based only on linked posts or votes would have scored it as a single request.

3. Scored all six tasks

Four of six already matched. Two didn't.

4. Changed the two priorities that disagreed

Two update_task calls, each sending only task_id and priority. Trimmed results:

{"id": "6939dc95-2ead-47a9-9c57-2064d614ab62", "title": "SMS reminders before appointments",
 "priority": "high", "is_roadmap": false, "assignee_id": null,
 "updated_at": "2026-10-17T04:23:28.416491+00:00"}

{"id": "fc3433e8-3c9a-4ada-95f6-87d15b6cfbc2", "title": "Add a reschedule link to confirmation emails",
 "priority": "low", "is_roadmap": false, "assignee_id": null,
 "updated_at": "2026-10-17T04:23:31.583611+00:00"}

5. Explained each change in a task comment

Two create_task_comment calls, with the author label "Prioritisation agent" so the board shows who made the change. Exactly as posted:

• On SMS reminders: "Priority medium -> high. Score 4 (reach 2, pain 2, revenue 2, effort 2): three people asked (Lucas, Aisha, plus a +1 on Lucas's post), all citing no-shows; one loses about two appointments a week and Aisha says she'd pay extra. Before building: decide how SMS cost is charged. Also: Aisha's post "Text clients a reminder the day before" (b14bfa15) isn't linked to this task, so she won't get the shipped email unless it's linked."
• On the reschedule link: "Priority medium -> low. Score 1 (reach 1, pain 2, revenue 0, effort 2): one person (Grace) asked, no votes or +1s, and no money at stake. The pain is real (weekly manual rescheduling) but a self-serve link needs a reschedule flow that respects availability, so it's a few days of work. Revisit if a second person asks."

Task comments in LotsTeam are internal to your organization, and changing a task's priority sends no email, so none of this reached a customer.

6. Read the board back

A final list_tasks with sort: priority returned the new order, trimmed to titles and priorities:

"total": 6
high    SMS reminders before appointments
high    Show times in the client's time zone in confirmation emails
high    Add Outlook and Microsoft 365 calendar sync
medium  Fix buffer time not applied on short-hours days
low     Export bookings to CSV
low     Add a reschedule link to confirmation emails

The two writes landed three seconds apart, and the reads before them took a few minutes. Nothing else on the board changed: no assignee, no roadmap flag, no edited post.

What the agent handed back to me

The scoring is the easy part. The useful part of the run was the list of things it couldn't decide:

1. SMS cost. The task is high now, but SMS costs money per message. Charge for it, include it in a plan, or cap it? That's a pricing decision, and the agent wrote it into the comment instead of guessing.
2. Aisha's post isn't linked to the SMS task. In the triage run she was pointed to the main post with a comment, but her post was never linked to the task. When SMS reminders ship and I publish a changelog entry that notifies the people who asked, only the authors of linked posts are emailed, so she'd miss it. One link_post_to_task call fixes it; I left it for my own review, as the prompt said.
3. Outlook sync is high on everything, including effort. It scores 4 because four people asked and two say it blocks them from switching, but it's also the largest job on the board. Whether a smaller first step (checking Microsoft busy times before a booking, without full two-way sync) ships sooner is a product call.

Four posts have no task yet (group bookings, dark mode, a vague "the app is confusing" and a payments question). They stay out of scoring until someone decides they're worth building; that's triage's job, not prioritization's.

How this relates to RICE and ICE

RICE comes from Sean McBride at Intercom (RICE: Simple prioritization for product managers, 2018): Reach × Impact × Confidence ÷ Effort, with reach as people affected in a period and effort in person-months. ICE is the lighter version many teams use: score impact, confidence and ease, then combine them.

My rubric borrows the same idea (value against effort) and changes three things for a small team with a few dozen requests:

• Reach is counted, not estimated. The agent counts the people behind each task from linked posts, duplicates, +1 comments and votes. With small numbers, a 1 to 3 band is more honest than "800 customers per quarter".
• Revenue signal replaces confidence. On a small product, "I'd pay for this" or "we can't switch until" is the strongest evidence you get, and it's in the words of the request.
• Addition instead of multiplication. With whole numbers from 0 to 3, multiplying lets one factor swamp the rest. Adding keeps every score explainable in one comment.

If you already use RICE, swap it into step 2 of the prompt. The pattern stays the same: the agent gathers the evidence, applies your formula, changes only what disagrees and shows its working.

A prompt you can copy

Change the project name, the bands and the factors to fit your product:

Prioritize the open tasks in my LotsTeam project "<Project name>".

For each task with status todo, read its linked posts, the comments on those
posts and the task's own comments. Count the people who asked: each post
author, each +1 comment, each vote, and any duplicate post pointed at the task,
each person once.

Score each task:
- Reach (1-3): 1 = one person, 2 = two or three, 3 = four or more.
- Pain (1-3): 1 = nice to have, 2 = recurring manual work or a bug with a
  workaround, 3 = users get a wrong result or can't use the product.
- Revenue signal (0-2): 0 = none, 1 = lost money implied, 2 = blocks buying
  or switching, or they'd pay.
- Effort guess (1-3): 1 = a day or two, 2 = a few days, 3 = a week or more.
Score = reach + pain + revenue - effort.
4+ = high, 2-3 = medium, 1 or less = low. Never set urgent.

Where the score disagrees with the current priority, change only the priority
and add one task comment: old -> new, the four scores and the evidence.
Don't edit posts, assign anyone, touch the public roadmap, publish a changelog
or reply to anyone.

Finish with the scoring table, then list what needs a decision from me,
including duplicate posts that aren't linked to their task.

Run it after each triage pass, or once a week. The comments build a record of why each priority is what it is, which is the thing that usually lives only in someone's head.

Run your own

Give your agent this and let it set itself up:

Read https://lots.team/skill.md and help me connect LotsTeam for you.

LotsTeam is $9 per project a month, or $24 a month for 3 projects, with unlimited team members and the MCP server and REST API on every plan. New accounts get 10,000 free credits, valid 90 days, no card. See pricing. If your requests and your tasks live in different tools today, The Best Tools to Link Feedback to Tasks compares how each one connects them, which is what makes counting reach possible at all.

Common questions

Can an AI agent prioritize feature requests?

Yes, if it can read where your requests and tasks live and you give it the rubric. In this run the agent read six tasks, their linked posts and comments, scored each on reach, pain, revenue signal and effort, and changed two priorities with a comment explaining each. It can't know your strategy unless the prompt states it, so the rubric is where your judgment goes.

Should the agent change priorities on its own?

Let it change what the rubric clearly decides and explain every change, then review the comments. Keep urgent, pricing calls and scope decisions for yourself. If you'd rather approve first, ask for the scoring table only and make the changes after reading it.

How is this different from RICE or ICE scoring?

It's the same idea, value against effort, sized for a small team. RICE multiplies reach, impact and confidence and divides by effort; ICE scores impact, confidence and ease. This rubric counts reach from real posts and comments, uses a revenue signal instead of confidence, and adds small whole numbers so each score fits in one comment.

How does the agent count votes and duplicates?

It counts people, not posts. Each linked post's author, each +1 comment, each vote and each duplicate post pointed at the task counts once. In this run that turned the SMS task from one linked post into three people, and it caught a duplicate that wasn't linked to its task.

Does changing a priority notify my users?

No. In LotsTeam, changing a task's priority and adding a task comment send no email, and task comments are internal to your organization. Users are emailed only when you send a support reply or publish a changelog entry with "notify the people who asked" turned on.

Run on 17 October 2026 from Claude Code connected to the LotsTeam MCP server, on a demo project with sample feedback written for these articles. RICE definition from Intercom's RICE article; prices from lots.team/pricing, checked the same day.