Building AI Agents for Product Teams: A Practical Guide
How we built Milo, our AI Junior Product Manager, and what we learned about setting up agents for business workflows
Scaling Product Management Without Scaling Headcount
In high-growth, multi-product organizations, product management can hit a wall. The frameworks and processes that worked at one product and one roadmap often struggle to scale to multiple platforms, varied customer segments, and competing priorities.
As Group Product Manager at TrustFlight, I oversee a portfolio of aviation safety and compliance products used by organizations with thousands of employees. My role is equal parts strategy, execution and systems design — ensuring that our teams operate from consistent frameworks while still moving quickly.
Recently, I’ve been exploring how AI could operate inside those frameworks — acting as a working team member that applies our processes and tools exactly as designed. That exploration led to Milo, our AI-powered junior product manager.
This post is both a how-to guide and a proof point that when you get the framework right, AI can slot in easily to handle high-volume, low-complexity tasks — freeing human PMs for higher impact work.
The Problem: Product Management Doesn’t Scale
Even the best PMs get bogged down in repetitive work — release notes, “what’s on the roadmap” questions, competitive intel logs, documentation tickets. At TrustFlight, running four platforms meant routine work was crowding out strategic time.
We didn’t just need more capacity — we needed a way to scale the operating model itself. Milo was the answer: an AI agent trained not just on generic PM tasks, but on our processes, our decision criteria, and our data.
The Solution: An AI Agent With Product and Framework Context
Many companies begin by giving their teams ChatGPT access or building chatbots. Few go further to embed AI within a structured product framework. The real opportunity is when the AI operates inside a structured product management framework, with direct access to your systems, governance, and product data.
Milo isn’t just a chatbot. It can:
Defining Jira tickets.
Updating Confluence pages.
Generating release notes.
Scoring feature requests with our prioritization framework.
Maintaining competitive intelligence logs.
This works because Milo was designed for specific workflows, not just open-ended tasks.
Building a Knowledge Respository (the hard part)
The real unlock wasn’t the AI tool — it was the context we gave it to operate from. We created a dedicated Confluence repository that brought together four layers:
Governance
This defined how our product function operates — how business goals are set and cascade into product goals, which stakeholder groups are involved and the role each plays, how ownership is defined, our roadmapping cadence, and the communication patterns we use to keep stakeholders aligned. Together, this gives context for how decisions are made, by who, and on what rhythm.
Framework
We codified our mental model of product management into the repository’s structure. This layer is product-agnostic: it describes how information should be organized and how the pieces fit together. It defines the categories of information we capture — business context, market context, strategy, execution — and the relationships between them. In other words, the framework provides the map: what types of knowledge exist, how they connect, and how to navigate them.
Content
Once the framework was in place, we filled it with the actual product-specific material. This includes things like feature lists, roadmaps, value propositions, competitive positioning, and cross-functional content from marketing, sales, and customer success. The content is what makes the repository actionable and it ties high-level goals through to day-to-day execution. In a multi-product organization this doesn’t have to be completed all at once. In our case, we onboarded products gradually, as priorities and capacity allowed.
Building this repository was as valuable as building Milo itself. It gives PMs a clear way to organize how they think about product management, while providing the content they need to do their jobs. This has been especially valuable for junior or new PMs, as well as PM-adjacent roles, by making it easier to understand how the product team approaches its work and communicates decisions.
With the foundation in place, the next step was to make Milo capable of operating on that knowledge consistently.
Setting Up the AI Agent
The starting point for the AI agent was defining its project instructions that define its role, mission, and operating principles. For Milo, we set out its identity as a junior product manager, its objectives in priority order, what kinds of tasks it can take on, and the communication standards it should follow. These rules make clear what Milo is (and isn’t) responsible for, and how it should behave in different situations.
But general instructions alone weren’t enough. To make them executable and reliable, we added three supporting systems:
Function Workflows. Each core use case — feature requests, release notes, competitive intel, stakeholder Q&A, documentation, and more — has a structured playbook. These workflows define triggers, step-by-step processes, and expected outputs, so Milo isn’t improvising but following the same consistent process a human PM would.
Technical Reference. A single lookup resource consolidates schemas, mappings, and queries across Jira, Confluence, and related tools. It includes things like custom field IDs, scoring formulas, and project structures, ensuring Milo knows how to handle inputs, where to find authoritative data, and how to interpret fields consistently.
Knowledge Base Index. Finally, we created a navigation map of all key content sources. This index tells Milo where each type of information lives, which source takes precedence when conflicts arise, and how to cite it. It keeps the agent oriented across a multi-product environment.
Together, the prompt instructions plus these layers give the AI both its operating “rules” and the system it needs to act on them.
Integrating with Tooling
Milo connects to Jira and Confluence through Anthropic’s Model Context Protocol (MCP), with its actions bounded by existing system permissions and the project instructions we’ve defined. From here, we’re exploring integrations that expand in three dimensions:
Adding context — Direct integrations, or integrations that flow into the Confluence knowledge base, could give Milo access to richer information such as support or customer data.
Improving accessibility — Embedding Milo in everyday tools like Slack would make it easier for people across the business to reach it within their normal workflows.
Expanding available tools — Connecting Milo to additional systems would let it go beyond surfacing insights to acting on them, from creating documentation tickets to updating logs.
Some integrations naturally expand in more than one of these dimensions, while others are narrower in scope. Either way, the direction is clear: moving Milo from answering questions in a single interface to being broadly accessible, with the context and tools needed to perform real work across the business.
Early Results
We launched Milo last month. Early data suggests:
~75% reduction in workload for repetitive tasks (e.g., defining a ticket, answering a question).
Even higher savings on batched work (e.g., writing a feature list from completed Jira tickets).
One area where Milo has been especially effective is bulk ticket creation and prioritization, pulling directly from transcripts of customer calls and meeting minutes. As a result, features are moving from idea to delivery more quickly, documentation is staying more consistent, and product output has increased without expanding the team.
While Milo was built for product management, the underlying model — codify workflows, embed governance, and integrate AI directly into systems — applies across other functions as well. For instance:
Customer success could generate tailored onboarding guides.
Marketing could draft brand-aligned release messaging directly from product updates.
The pattern is the same: when AI operates within well-defined frameworks and a managed repository of data, organizations can scale without compromising quality.
Final Thoughts
Reflecting on this project, a few lessons stand out:
Start with knowledge, not AI. Your agent is only as good as the information it has.
Workflows matter as much as intelligence. The value comes from codifying best practices into repeatable processes.
Integration with tooling drives productivity. If your AI can’t act in your systems, it’s just an expensive search tool.
Feedback loops matter. Build mechanisms for continuous improvement from day one.
AI agents won’t replace product managers in the near term — but they will reshape the role by absorbing the operational load that slows strategic work. The opportunity is bigger than automation: it’s about creating the conditions for scale. By codifying knowledge, embedding workflows, and integrating technology directly into systems, organizations can grow faster without adding friction.
And there are benefits beyond AI. Building the tool forced us to surface and structure product information into a shared asset for the entire team, which strengthens the product function long before the AI gets involved.
