How I Set Up My Project Agent — Making AI Actually Work for PM Work
Most PMs I know use AI the same way: open ChatGPT, paste something in, get something out, copy it back. It’s useful, but it’s disconnected — the AI has no idea what your project is, who your stakeholders are, or what happened in yesterday’s meeting. Every conversation starts from zero. I spent the last few months building something different. Not a chatbot I talk to, but a project agent — an AI copilot that lives inside my actual work context, knows my project cold, and can operate across Slack, Email, and Teams without me being the middleman for every piece of context.
The result: I went from spending 2+ hours a day on triage, status tracking, and document synthesis to having a system that does the first pass for me. I open my laptop, say “scan my project,” and within minutes I have a prioritized action board waiting.
Here’s how I built it. Three pillars: Project Context, System Prompt, and Skills.
Pillar 1: Project Context — Give AI Your Brain Dump
The single most impactful thing I did was feeding the agent my actual project materials — not a summary, not a prompt, but the real documents I work with every day.
What Goes Into the Knowledge Base
My agent’s knowledge base is a folder of ~30 files that represent everything I know about my project. I’m a PM working on an AI-powered consumer feature at a large tech company — the kind of project with multiple workstreams, cross-functional stakeholders, and a heavy compliance footprint.
Here’s what I loaded:
| Category | Examples | Why It Matters |
|---|---|---|
| Product Specs | PRDs, one-pagers for each workstream | The agent needs to know what we’re building — feature requirements, user flows, edge cases |
| Privacy & Legal | Privacy whitepapers, legal consultation notes, guardrail failure cases | PM work in big tech is 30% compliance. The agent needs to know our commitments cold |
| Research | UXR memos, retention analysis, user feedback summaries | Ground decisions in actual user data, not vibes |
| Technical | Quality evaluation plans, prompt engineering docs, architecture overviews | So the agent can reason about technical trade-offs without hallucinating implementation details |
| Living Documents | Consolidated product summary, feedback digests, lessons learned | These evolve — the agent updates them over time |
The Consolidated Summary: One Doc to Rule Them All
Early on I realized the agent would drown in 30 documents without a map. So I had it generate a Consolidated Product Summary from all source documents — a single markdown file that covers:
- Product vision and problem statement
- Current shipped status and key metrics
- Feature architecture across all workstreams
- Stakeholder map and decision history
This becomes the agent’s “working memory.” When I ask “what’s the current state of workstream X?”, it doesn’t search through 13 PDFs — it goes straight to the summary.
Lessons Learned: Institutional Memory That Persists
One of the most underrated files in my knowledge base is lessons-learned.md. After every significant stakeholder interaction — a compliance review that went sideways, feedback from my skip manager, a process correction from a cross-functional partner — I tell the agent: “记下这个lesson” (record this lesson).
The agent reconstructs the full story from our conversation: what I was doing, what feedback I got, and the actionable takeaway. For example:
Lesson: Cross-Functional Engagement Process
- Don’t reinvent the wheel — look at what’s already shipped in your product as precedent before chasing other teams for their approach.
- Know your escalation path — understand which team is the first filter before involving legal or senior leadership.
- Focus on the delta — map existing patterns to your new feature, then only flag what’s truly incremental.
These lessons compound. Six months in, the agent doesn’t just help me write docs — it knows the political landscape of how to navigate my org.
Project Config: The People Graph
The most critical piece of context isn’t a document — it’s the people configuration. My project config defines:
- My leadership chain — messages from these people auto-escalate to P0
- Key stakeholders — with roles, scopes, and contact info (tech leads, legal counsel, privacy reviewers, designers, marketing partners…)
- Triage rules — what signals are P0 (leadership asks, deadlines, “action required”), P1 (direct asks from stakeholders, @mentions), P2 (FYI, CC’d updates), and noise (bot messages, calendar accepts)
This is what transforms the agent from “a smart chatbot” to “a PM who knows the org chart.”
Pillar 2: System Prompt — Teaching AI to Think Like a PM
Context gives the agent what to know. The system prompt tells it how to think.
Most people treat system prompts as a one-liner: “You are a helpful assistant.” That’s leaving 90% of the value on the table. My system prompt is a PM operating manual — it defines the agent’s role, its workflows, its constraints, and even its personality.
The Role Definition
My agent’s identity is sharp:
You are a Senior PM AI Co-pilot. Your core objective is to help the user free up their time, efficiently handle complex document writing tasks, and serve as a strategic sparring partner to manage project progress.
Not “a helpful assistant.” Not “an AI that can do anything.” A PM copilot with a specific job: save me time, write documents, and challenge my thinking.
Four Core Workflows Built Into the Prompt
Instead of hoping the AI figures out what I need, I defined four explicit workflows:
1. Backlog & Prioritization
When I give the agent meeting notes, it automatically extracts action items, TBDs, and risks — then maps them to milestones and prioritizes using RICE or Eisenhower. The output format is rigid on purpose:
[P0] Task Description - Owner - DDL - (Linked Milestone)
[P1] ...
No ambiguity. No prose. I can copy this directly into a Slack message or a work item.
2. Documentation & Standardization
When I need a PRD, one-pager, or compliance document, the agent follows the templates from my knowledge base. Missing information gets marked as [Requires Confirmation: Specific Question] instead of being hallucinated. This single rule has saved me from shipping fabricated details more times than I can count.
3. User-Centric Thinking
Every feature discussion, every brainstorming session, every document — the agent is trained to anchor back to the user. I baked this into the prompt as a non-negotiable reflex:
Always ask: “What core user pain point does this solve?”
It sounds simple, but in practice, PM conversations drift toward technical feasibility, org politics, or competitive pressure. Having an agent that consistently pulls the conversation back to “but what does the user actually need?” is like having a UX researcher sitting in every meeting. When I’m drafting a spec, the agent will flag: “This section describes the implementation, but doesn’t explain why the user would care. What user problem does this solve?” That friction is the point.
4. Strategy & Brainstorming
This is where the prompt gets opinionated. I explicitly told the agent:
Do not simply agree. Play the “Challenger” role — highlight potential loopholes, edge cases, or market competition risks.
I don’t need a yes-man. I need a sparring partner who pushes back. When I’m excited about a feature idea at 11 PM, the agent’s job is to ask the uncomfortable questions before I take it to my team.
The Constraints That Matter Most
Two constraints in my system prompt prevent the most common AI failures:
-
Always Grounded in Context — The agent bases its work on provided materials. It doesn’t fabricate features or hallucinate based on external knowledge unless I explicitly ask for divergent thinking.
-
Privacy First — It automatically checks for compliance with our privacy commitments when processing any document. In my world, shipping a feature that violates privacy requirements isn’t a bug — it’s a ship-stopper. The agent knows this.
Tone and Style
This sounds trivial but it matters enormously for adoption:
- Professional & Direct — no fluff, no “Great question!” filler
- Structured — every output is Markdown with headings, bold, and lists
- Proactive — at the end of each response, it suggests the next step: “Based on this new PRD, would you like me to draft the corresponding work item descriptions?”
That last one — proactive follow-up — turns a reactive tool into a workflow partner. I’m never left wondering “now what?”
Pillar 3: Skills — Giving AI Hands and Feet
Context is the brain. The system prompt is the personality. Skills are the hands and feet — modular capabilities that let the agent actually do things in the real world.
A skill isn’t just a prompt template. It’s a self-contained package: instructions, scripts, configuration, and sometimes its own authentication. Think of skills like apps on your phone — each one does one thing well, and they compose together for complex workflows.
Here are the three skills that transformed my daily work the most:
Project Radar — My Morning Briefing
This is the skill I’m most proud of. Project Radar scans three communication channels simultaneously — Slack, Email, and Teams — and produces a prioritized action board.
Here’s what happens when I type “scan my project”:
1. Load Config → Who are my stakeholders? What channels matter?
2. Load State → What was open from last scan?
3. Collect → Pull messages from Slack, Email, Teams
4. Triage → Classify each signal as P0/P1/P2/Noise
5. Deduplicate → Merge cross-channel duplicates
6. Update Board → Write to action-board.md
7. Output Brief → Show me what needs attention
The triage logic is the magic. It uses the people graph from my project config to make judgment calls: a message from my VP saying “action required” → automatic P0. A status update from a tech lead → P1. A calendar accept notification → noise, filtered out.
The output is a persistent action board — a markdown file in my knowledge base that tracks every open item with age, source, and recommended action:
## 🔴 P0 — Needs Immediate Action
1. [radar-001] Reschedule compliance review — legal counsel has time conflict ⏰ 14 days open
2. [radar-002] Review overdue privacy assessment ⏰ 14 days open
## 🟡 P1 — Action Required
3. [radar-009] Designer asking about sprint plans — respond via Teams
4. [radar-008] Manager's weekly update — metrics down, need action plan
No more inbox archaeology. No more “did I miss something in that Slack channel?” The radar catches it, triages it, and tracks it until I close it.
Thread Digest — Turning Messy Chats Into Well-Organized Context
PM communication is messy. A single decision might span a 47-message Teams thread over three days, with tangents, pleasantries, and out-of-order replies. And the worst part? When you need to reference that decision two weeks later, you’re scrolling through noise trying to find the one message that mattered.
Thread Digest solves this by transforming raw communication threads into structured documents organized by workstream, not chronology. Its design philosophy:
A thread is a noisy river of messages. A digest is a map of the terrain after the river has passed — what’s settled, what’s still moving, what’s blocked.
The key principles that make this work:
- Organize by topic, not time — stitch together messages from Day 1 and Day 7 if they’re about the same workstream
- Preserve proposals and exact feedback — when someone proposes specific language and receives specific pushback, keep both verbatim. This is the #1 reason people go back to raw threads.
- Preserve the “why” — decisions without reasoning get re-litigated. Always capture the considerations that led to alignment.
- Kill noise, not substance — drop “NTD” and logistics, keep every message with actual content
The digest becomes the authoritative record. If a reader needs to go back to the raw chat to find exact wording, the digest has failed.
Why this matters beyond convenience: these digests become new knowledge base entries. The agent processes a messy 50-message compliance review thread, produces a clean digest, and now it permanently knows what was decided, who pushed back on what, and why the final approach was chosen. The context compounds.
Lesson Logger — Building Institutional Memory
This is the quiet workhorse. Every time I learn something from a stakeholder interaction — a process correction, a political insight, a hard-won lesson about how things actually work in my org — I tell the agent to record it.
The agent doesn’t just take notes. It reconstructs the full story from our conversation:
- Context — What was I working on? What was the situation?
- What happened — What approach did I take?
- Feedback — What pushback or correction did I receive?
- Key takeaways — What should I do differently next time?
Each entry gets categorized — stakeholder communication, product strategy, cross-team collaboration, personal effectiveness — and appended to a persistent lessons-learned.md in the knowledge base.
The compounding effect is real. After six months of logging, the agent has internalized dozens of lessons about how my org works. When I’m drafting a new proposal, it doesn’t just check for technical correctness — it flags patterns it’s seen before: “Last time you approached this team directly without going through your privacy partner first. Based on the lesson from March, consider looping them in earlier.”
This is the closest thing I’ve found to giving an AI organizational wisdom — not just knowledge of what to build, but knowledge of how to get things done in a specific environment.
What Changed After Setting This Up
Let me be concrete about the before and after:
| Task | Before (Manual) | After (Agent-Assisted) |
|---|---|---|
| Morning triage (Slack + Email + Teams) | 45-60 min | 5 min (one “scan” command) |
| Writing a one-pager | 3-4 hours | 45 min (agent drafts, I edit) |
| Digesting a 50-message thread | 30 min reading + 20 min writing summary | 5 min (thread-digest skill) |
| Answering “what’s the status of X?” from my manager | 20 min searching + compiling | Instant (consolidated summary + action board) |
| Compliance check on a new feature | 1 hour cross-referencing docs | 10 min (agent knows the requirements) |
The biggest shift isn’t time savings on individual tasks — it’s the elimination of context switching. Instead of bouncing between Slack, Outlook, Teams, and work tracking tools to piece together what’s happening, I have one interface that synthesizes it all.
Lessons From Building This
1. Start with context, not skills. The smartest skills in the world are useless without project context. Load your documents first. The agent needs to know what you’re building before it can help you build it.
2. The people graph is everything. AI can’t triage messages without knowing who matters. Investing time in defining your leadership chain, key stakeholders, and their scopes pays off on every single scan.
3. Lessons learned is the compounding asset. Every lesson you record makes the agent slightly smarter about your org’s dynamics. Six months of accumulated lessons is worth more than any prompt engineering trick.
4. Structured output > smart output. I’d rather have a correctly formatted [P0] Task - Owner - DDL than a beautifully written paragraph I need to parse. The system prompt’s output format rules save more time than any other feature.
5. Skills should be composable. Project Radar doesn’t do one big thing — it orchestrates multiple underlying tools into a pipeline. Each skill works independently but shines when combined.
6. Read-only first, write later. I started with skills that only read information (search email, scan messages). Once I trusted the agent’s judgment, I added write capabilities (create work items, draft documents). This gradual trust-building is important.
The Meta Lesson
The real insight isn’t about AI tools or prompt engineering. It’s this:
Your AI copilot is only as good as the system you build around it.
ChatGPT is a brilliant intern with amnesia. Every conversation starts over. What I built is closer to a junior PM who’s been on the project for six months — one who knows the stakeholders, remembers the lessons, understands the compliance constraints, and can go check Slack without being asked.
The setup cost was real — maybe 20-30 hours over a few months to build the knowledge base, refine the prompt, and develop the skills. But the daily return is compounding. Every lesson logged, every document added, every skill refined makes the system slightly better.
If you’re a PM staring at 200 unread messages across four channels, wondering how to keep track of it all — this is the answer. Not a smarter chatbot. A system that knows your project, thinks like your team, and operates in your real work environment.
Build the context. Write the prompt. Add the skills. Then let the agent do the first pass while you do the thinking that actually matters.