Product request triage, inside Microsoft Teams
Stakeholders describe a problem in a Teams channel. An AI intake agent checks whether it's already planned or shipped, asks questions, and files a structured request that a domain expert triages. The outcome goes back to the same thread.
- Context
- B2B marketplace platform
- My role
- Designer & hands-on builder
- When
- 2026
- duplicates & shipped work checked before any question
- Search first
- Jira tickets created until a human converts the request
- 0
- Teams bot, agent, API and triage UI, built in about a week
- 4 repos
The challenge
Feature requests came in through chats, calls and DMs. Many were duplicates, or things we had already shipped. The rest arrived without the basics: who is affected, why it matters, how urgent it is. Product builders spent their time chasing context. Stakeholders never knew what happened to their idea.
Our AI delivery agent didn’t help here either. Every way into it created a full work package and a Jira ticket, which is right for work someone has decided to do and wrong for “I noticed a problem”.
What I built
A request is not a task. That idea is the core of the design. A request is a candidate: it owns no ticket, no sprint slot and no agent lanes until a human decides it should.
- Teams as the front door. A stakeholder writes in a request channel, in their own words, with screenshots or documents attached. A thin bot built on the Microsoft 365 Agents SDK turns the thread into an intake session.
- Search before asking. A small, locked-down intake agent first searches open and already released work packages (semantic search over Pinecone), the Jira board and other pending requests. If something likely matches, it offers it straight away: “this shipped last month, here’s how it works”. The best request is the one nobody has to build.
- Questions. The agent asks clarification questions, proposes severity, then files a structured request record.
- A real triage queue. Domain experts get a new thread in their triage channel with a deep link, and decide in an internal dashboard: convert, duplicate or reject. Converting pre-fills the work package with everything intake learned.
- Closing the loop. The decision is posted back into the stakeholder’s original Teams thread.
Guardrails
Stakeholder text is untrusted input, so the intake agent is the most restricted agent in the system: it can’t touch repositories, shell tools or other agents.
Why it matters
Most “AI for product” demos write specs. The bigger win is earlier in the process: making sure the right requests reach the team in the first place, already deduplicated and with the context included, and that the people who asked actually hear back.