How to Build a Multi-Agent System That Works While You Think
Day #12 of AI for PMs: One Day at a Time
A note before we start: this one is longer than usual. The reason is simple — the LinkedIn post promised to walk you through building this for yourself, step by step. A promise like that either gets kept properly, or it doesn’t get kept at all. This article is complete. It has the design principles, the full protocol you can copy, the folder architecture, and the adaptation guide for different meeting types. Read it once to understand. Keep it to build from.
The shift from using AI to working with AI
There is a meaningful difference between these two things, and most people never cross it.
When you use AI, you are the orchestrator. You read from one tool, bring the output into Claude, ask a question, take the answer, go to another tool, bring that output in, ask another question. The intelligence is Claude’s. The workflow is yours. You are in every step of it — reading, copying, pasting, prompting, interpreting.
When you work with AI, Claude is the orchestrator. You define the goal and the starting context. Claude decides what to read, what to search, what to connect, and in what sequence. It autonomously switches between tools, builds a picture from multiple sources simultaneously, and delivers a finished output. You are at the beginning and the end. The middle runs without you.
That shift is what a multi-agent system actually is. Not a clever prompt. Not a single tool call. A goal-directed workflow that uses multiple connected tools in sequence — each step informing the next — to produce something finished rather than something raw.
The tasks that consume the most time for anyone who leads — product managers, team leads, senior contributors, anyone who synthesizes information before making decisions or running meetings — are rarely the ones that require the most judgment. They are the ones that require the most information gathering. Reading across multiple sources, synthesizing what’s relevant, discarding what isn’t, producing a coherent picture before the real thinking can begin. That gathering is almost entirely automatable. It doesn’t require your judgment. It requires your goal.
The design principle: Goal-Sources-Constraints
Before building any agent, answer three questions — in this order.
What is the goal? Not the task — the finished output you need, stated precisely enough that you would know if Claude achieved it. “Search the knowledge base for documents about the Q2 review” is a task. “Prepare me for the Q2 review meeting with a clear picture of what’s unresolved and what to push on” is a goal. The difference is that a goal requires Claude to decide what to do. A task just tells it what to execute.
What are the sources? Which tools, files, or systems contain the information needed to achieve that goal? Be specific — not “search for information” but “search the knowledge base for documents related to this topic, then check project management tickets, then read the last 20 messages in the relevant channel.” The sequence matters. The most important source should come first.
What are the constraints? What should Claude not do? What should it flag rather than decide? What requires your judgment before proceeding? This question is the most commonly skipped and the most important. An agent without constraints makes decisions you didn’t authorize. Defining what requires human judgment before the agent runs is what keeps you in the right parts of the loop — not every step, but the steps that matter.
These three questions — Goal, Sources, Constraints — are the architecture of every multi-agent system one chooses to build. The specific tools change. The MCP connections change. The protocol changes. The architecture doesn’t.
If this framework feels familiar, it should. In Day #2, we introduced Role-Goal-Constraint as the three-question framework for writing a single prompt. The parallel is deliberate. Role-Goal-Constraint governs what one AI does in one session. Goal-Sources-Constraints govern what a system of connected AI agents does across multiple tools. The constraint layer is present in both — because without it, both produce decisions you didn’t authorize. Same design thinking. Different scale.
What I built and what it produced
The system is a pre-meeting intelligence agent. Before any significant meeting, it searches for the meeting notes document first, then reads the relevant Slack channel, then checks open project management tickets, then searches the enterprise knowledge base — in that sequence, each step informing the next — and produces a brief structured around what the meeting actually requires.
Different meetings need different outputs. I built the agent to adapt based on the framing you provide:
An Inform meeting needs a context summary — what’s happened since we last discussed this, what’s changed, and what’s the current state.
A Decision meeting needs the open items and the one question to push on — what’s blocked, what needs to be resolved in the room, and what will move if the right person commits.
A Discussion meeting needs the signals worth raising — what new intelligence or external context should shape the conversation, what the team may not have seen yet.
For an upcoming cross-functional meeting, the agent surfaced something worth naming. A public 2026 threat intelligence report showed that AI agents are being actively weaponized against travel and accommodation platforms — automating attacks that legacy detection systems weren’t built to catch. Cross-referencing that with internal signals produced a sharper picture than either source alone.
But the most useful thing the system did wasn’t finding that. It was flagging what it missed.
On the first run, it couldn’t locate the meeting notes document. It told me exactly why — wrong search terms — and what it should have done differently. I provided the document. The brief changed materially. The question to push on shifted entirely.
That’s the human-in-the-loop moment working correctly. Not approving every search query. Not supervising every step. Reading the output, recognizing what’s missing, and deciding what to add.
The agent handles the mechanical middle. You handle the goal and the judgment. The intelligence isn’t in the tools. It’s in the goal you set and the judgment you apply to what comes back.
The file you can copy and use today
This is the exact CLAUDE.md file that powers the meeting agent. Create a folder called meeting-agent in your workspace, paste this inside a CLAUDE.md file, and the agent is ready.
# Pre-Meeting Intelligence Agent
## Purpose: Prepare a concise, actionable pre-meeting brief by searching across connected tools and synthesizing what’s unresolved, what’s in flight, and what to push on.
## Protocol — Execute Every Time in This Sequence
### Step 1 — Find the Meeting Notes Document First Search using the exact meeting title provided. If a recurring notes document exists, read it fully before proceeding. This is the most important source — do not skip it or substitute keyword searches when the document title is known.
### Step 2 — Search Your Communication Tool: Find the most relevant channel for this meeting. Read the last 20 messages. Identify unresolved action items, open questions, and recent changes that haven’t been confirmed.
### Step 3 — Search Your Project Management Tool Search for tickets relevant to the teams and topics in this meeting. Identify blocked items, items without documented blockers, and patterns across tickets owned by the same person.
### Step 4 — Search Your Knowledge Base Search for recent strategy documents, assessments, risk registers, or reports relevant to the meeting topic. Note the date of each document — recency matters.
### Step 5 — Synthesise Into a Brief Produce a structured brief with: - Source Transparency: what you found, what you couldn’t find, and why - What Was Unresolved From the Last Session - Open Items Most Likely to Be Discussed or Escalated - New Signals or External Intelligence Worth Raising - The Output This Meeting Needs: for an informed meeting, a context summary; for a decision meeting, the open items and the question to push on; for a discussion meeting, the signals worth raising
## Output Principles - Never fabricate. If a source returns nothing, say so explicitly. - Flag gaps — tell me what you couldn’t find and what that means. - Flag anything requiring human judgment rather than deciding it yourself. - The brief should be readable in 3 minutes. Insight over completeness.
## How to Use This Agent Start a Claude Code session in this folder and provide: “Prepare a pre-meeting brief for [meeting name] happening [date]. Meeting type: [informed / decision/discussion]. Teams involved: [list]. Key topics if known: [list].”
## Who I Am Read ~/ai-workspace/CLAUDE.md and ~/ai-workspace/DECISIONS.md before beginning. Frame findings through my role, domain expertise, and current priorities.Setting it up
Create the folder:
mkdir -p ~/ai-workspace/meeting-agent
Create the CLAUDE.md file inside it with the protocol above. Then start a session:
cd ~/ai-workspace/meeting-agent && claude
Provide your meeting details. The agent runs the five-step protocol automatically every time.
The agent uses whatever MCP connections are available in your Claude Code setup. The filesystem MCP from Day #11 gives it access to your local files. For your communication tool, project management system, or knowledge base, each has an MCP server you can add with claude mcp add. The agent flags when a source isn’t accessible rather than fabricating.
For users of other AI tools: The Goal-Sources-Constraints framework works in any agentic AI environment. The five-step protocol is a research design principle, not a Claude Code feature. Adapt it to whatever tools you have connected — ChatGPT with plugins, Gemini with extensions, or any tool-calling framework. The sequence matters more than the specific implementation.
The principle that makes this generalizable
The meeting agent is one example. The design principle behind it applies to any task in which you currently act as the intermediary between multiple information sources and the finished output.
Ask yourself: what do I do regularly that follows this pattern — read from source A, bring it somewhere, read from source B, bring it somewhere, synthesize, produce output? Every task that follows that pattern is a candidate for a multi-agent workflow.
You define the goal. You specify the sources. You set the constraints. The agent handles the middle.
The intelligence isn’t in the tools. It’s in the goal you set and the judgment you apply to the output.
Day #13 lands Tuesday, 14 April — 8:00 AM CET.
— Vaibhav
Product Manager Stories is free. Always. If this was useful, share it with one person who would find it valuable too.