AI Agents for Product Teams
What I did: Designed and built AI agents on AWS Bedrock AgentCore that draft stakeholder updates, summarise sprints and gather evidence from the team's Jira and Confluence records.
Result: Status updates and sprint summaries are drafted automatically from the team's own tools, ready for a person to review before they go out.
Summary
A set of AI agents and automations I designed and built to take repetitive work off product and risk teams: stakeholder updates, sprint write-ups, evidence gathering and design-to-ticket handoff. The aim is for people to spend their time on decisions rather than admin.
Context
A lot of a product team's week follows the same pattern: pull updates from Jira and Confluence, turn them into something each audience can read, and move designs into tickets. It's necessary work, but it's predictable, and it competes for time with discovery and prioritisation.
Problem
Off-the-shelf AI chat tools could help with the writing, but they didn't connect to the systems where the work lives, and company data couldn't be pasted into tools outside our controlled environment. The opportunity was agents that sit inside our own cloud, read from our own tools, and hand people a draft to review.
Constraints & Principles
- Data stays in our environment: agents run in company AWS, not third-party chat tools.
- Agents draft, people decide: every output is reviewable before it reaches a stakeholder.
- Meet people where they work: Jira, Confluence, Slack and Figma, not a new app to learn.
- Small and incremental: built alongside the day job, one useful agent at a time.
My Role
I identified the use cases from my own team's workflows, designed the agent suite, and built the agents myself in C#/.NET and Python on AWS Bedrock AgentCore. Before building, I researched AgentCore's Runtime, Memory and Gateway patterns so the agents could share one foundation instead of each being a one-off.
What I Built
- Stakeholder comms agent: drafts status updates for different audiences from delivery data.
- Sprint synthesiser: turns sprint data into a readable summary of what shipped and what moved.
- Appraisal evidence collector: gathers delivered work from across tools as evidence against goals.
- Figma-to-Jira plugin: turns design frames into tickets ready for refinement.
- Confidence-scoring agent: scores the reliability of incoming player availability information (Python, Strands).
- In progress: a junior PO assistant connected to Jira, Confluence and GitHub via MCP, and a risk-team Slack bot.
Architecture
I designed a suite of six agents on shared AgentCore foundations: one runtime pattern, shared memory, and a common gateway to team tools. Each new agent reuses the same integration layer rather than starting from scratch.
Off the Clock
The same instinct shows up in my own projects. SME Hub is a local, privacy-first knowledge assistant that runs on Ollama with AES-256-GCM encryption, so nothing leaves the machine.
What It Shows
- Spotting automation opportunities in real workflows, not looking for places to use AI.
- Taking an idea from use case to a working agent without waiting for an engineering slot.
- Designing for privacy, governance and human review from the start.
- Thinking in platforms: shared foundations that make the next build cheaper.
Where this applies
None of these agents depend on sports data. The same pattern fits anywhere teams lose time to predictable admin:
- Status and stakeholder reporting: any product, engineering or programme management function
- Sprint and delivery summaries: agile teams in any industry
- Design-to-ticket handoff: any team that designs in Figma and plans in Jira
- AI that stays inside your own environment: regulated or data-sensitive businesses: financial services, healthcare, legal, public sector