ishenwei/nexus
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update nexus: fix conflicts and sync local changes

Browse Source
This commit is contained in:
Shen Wei
2026-04-26 12:06:50 +08:00
parent 191797c01b
commit f09834b5a5
2443 changed files with 254323 additions and 255154 deletions
Download Patch File Download Diff File Expand all files Collapse all files

96
raw/Agent/agency-agents/examples/README.md
View File

@@ -1,48 +1,48 @@
# Examples
This directory contains example outputs demonstrating how the agency's agents can be orchestrated together to tackle real-world tasks.
## Why This Exists
The agency-agents repo defines dozens of specialized agents across engineering, design, marketing, product, support, spatial computing, and project management. But agent definitions alone don't show what happens when you **deploy them all at once** on a single mission.
These examples answer the question: *"What does it actually look like when the full agency collaborates?"*
## Contents
### [nexus-spatial-discovery.md](./nexus-spatial-discovery.md)
**What:** A complete product discovery exercise where 8 agents worked in parallel to evaluate a software opportunity and produce a unified plan.
**The scenario:** Web research identified an opportunity at the intersection of AI agent orchestration and spatial computing. The entire agency was then deployed simultaneously to produce:
- Market validation and competitive analysis
- Technical architecture (8-service system design with full SQL schema)
- Brand strategy and visual identity
- Go-to-market and growth plan
- Customer support operations blueprint
- UX research plan with personas and journey maps
- 35-week project execution plan with 65 sprint tickets
- Spatial interface architecture specification
**Agents used:**
| Agent | Role |
|-------|------|
| Product Trend Researcher | Market validation, competitive landscape |
| Backend Architect | System architecture, data model, API design |
| Brand Guardian | Positioning, visual identity, naming |
| Growth Hacker | GTM strategy, pricing, launch plan |
| Support Responder | Support tiers, onboarding, community |
| UX Researcher | Personas, journey maps, design principles |
| Project Shepherd | Phase plan, sprints, risk register |
| XR Interface Architect | Spatial UI specification |
**Key takeaway:** All 8 agents ran in parallel and produced coherent, cross-referencing plans without coordination overhead. The output demonstrates the agency's ability to go from "find an opportunity" to "here's the full blueprint" in a single session.
## Adding New Examples
If you run an interesting multi-agent exercise, consider adding it here. Good examples show:
- Multiple agents collaborating on a shared objective
- The breadth of the agency's capabilities
- Real-world applicability of the agent definitions
# Examples
This directory contains example outputs demonstrating how the agency's agents can be orchestrated together to tackle real-world tasks.
## Why This Exists
The agency-agents repo defines dozens of specialized agents across engineering, design, marketing, product, support, spatial computing, and project management. But agent definitions alone don't show what happens when you **deploy them all at once** on a single mission.
These examples answer the question: *"What does it actually look like when the full agency collaborates?"*
## Contents
### [nexus-spatial-discovery.md](./nexus-spatial-discovery.md)
**What:** A complete product discovery exercise where 8 agents worked in parallel to evaluate a software opportunity and produce a unified plan.
**The scenario:** Web research identified an opportunity at the intersection of AI agent orchestration and spatial computing. The entire agency was then deployed simultaneously to produce:
- Market validation and competitive analysis
- Technical architecture (8-service system design with full SQL schema)
- Brand strategy and visual identity
- Go-to-market and growth plan
- Customer support operations blueprint
- UX research plan with personas and journey maps
- 35-week project execution plan with 65 sprint tickets
- Spatial interface architecture specification
**Agents used:**
| Agent | Role |
|-------|------|
| Product Trend Researcher | Market validation, competitive landscape |
| Backend Architect | System architecture, data model, API design |
| Brand Guardian | Positioning, visual identity, naming |
| Growth Hacker | GTM strategy, pricing, launch plan |
| Support Responder | Support tiers, onboarding, community |
| UX Researcher | Personas, journey maps, design principles |
| Project Shepherd | Phase plan, sprints, risk register |
| XR Interface Architect | Spatial UI specification |
**Key takeaway:** All 8 agents ran in parallel and produced coherent, cross-referencing plans without coordination overhead. The output demonstrates the agency's ability to go from "find an opportunity" to "here's the full blueprint" in a single session.
## Adding New Examples
If you run an interesting multi-agent exercise, consider adding it here. Good examples show:
- Multiple agents collaborating on a shared objective
- The breadth of the agency's capabilities
- Real-world applicability of the agent definitions

1704
raw/Agent/agency-agents/examples/nexus-spatial-discovery.md
View File

File diff suppressed because it is too large Load Diff

110
raw/Agent/agency-agents/examples/workflow-book-chapter.md
View File

@@ -1,55 +1,55 @@
# Workflow Example: Book Chapter Development
> A focused single-agent workflow for turning rough source material into a strategic first-person chapter draft with explicit revision loops.
## When to Use This
Use this workflow when an author has voice notes, fragments, or strategic notes, but not yet a clean chapter draft. The goal is not generic ghostwriting. The goal is to produce a chapter that strengthens category positioning, preserves the author's voice, and exposes open editorial decisions clearly.
## Agent Used
| Agent | Role |
|-------|------|
| Book Co-Author | Converts source material into a versioned chapter draft with editorial notes and next-step questions |
## Example Activation
```text
Activate Book Co-Author.
Book goal: Build authority around practical AI adoption for Mittelstand companies.
Target audience: Owners and operational leaders of 20-200 person businesses.
Chapter topic: Why most AI projects fail before implementation starts.
Desired draft maturity: First substantial draft.
Raw material:
- Voice memo: "The real failure happens in expectation setting, not tooling."
- Notes: Leaders buy software before defining the operational bottleneck.
- Story fragment: We nearly rolled out the wrong automation in a cabinetmaking workflow because the actual problem was quoting delays, not production throughput.
- Positioning angle: Practical realism over hype.
Produce:
1. Chapter objective and strategic role in the book
2. Any clarification questions you need
3. Chapter 2 - Version 1 - ready for review
4. Editorial notes on assumptions and proof gaps
5. Specific next-step revision requests
```
## Expected Output Shape
The Book Co-Author should respond in five parts:
1. `Target Outcome`
2. `Chapter Draft`
3. `Editorial Notes`
4. `Feedback Loop`
5. `Next Step`
## Quality Bar
- The draft stays in first-person voice
- The chapter has one clear promise and internal logic
- Claims are tied to source material or flagged as assumptions
- Generic motivational language is removed
- The output ends with explicit revision questions, not a vague handoff
# Workflow Example: Book Chapter Development
> A focused single-agent workflow for turning rough source material into a strategic first-person chapter draft with explicit revision loops.
## When to Use This
Use this workflow when an author has voice notes, fragments, or strategic notes, but not yet a clean chapter draft. The goal is not generic ghostwriting. The goal is to produce a chapter that strengthens category positioning, preserves the author's voice, and exposes open editorial decisions clearly.
## Agent Used
| Agent | Role |
|-------|------|
| Book Co-Author | Converts source material into a versioned chapter draft with editorial notes and next-step questions |
## Example Activation
```text
Activate Book Co-Author.
Book goal: Build authority around practical AI adoption for Mittelstand companies.
Target audience: Owners and operational leaders of 20-200 person businesses.
Chapter topic: Why most AI projects fail before implementation starts.
Desired draft maturity: First substantial draft.
Raw material:
- Voice memo: "The real failure happens in expectation setting, not tooling."
- Notes: Leaders buy software before defining the operational bottleneck.
- Story fragment: We nearly rolled out the wrong automation in a cabinetmaking workflow because the actual problem was quoting delays, not production throughput.
- Positioning angle: Practical realism over hype.
Produce:
1. Chapter objective and strategic role in the book
2. Any clarification questions you need
3. Chapter 2 - Version 1 - ready for review
4. Editorial notes on assumptions and proof gaps
5. Specific next-step revision requests
```
## Expected Output Shape
The Book Co-Author should respond in five parts:
1. `Target Outcome`
2. `Chapter Draft`
3. `Editorial Notes`
4. `Feedback Loop`
5. `Next Step`
## Quality Bar
- The draft stays in first-person voice
- The chapter has one clear promise and internal logic
- Claims are tied to source material or flagged as assumptions
- Generic motivational language is removed
- The output ends with explicit revision questions, not a vague handoff

238
raw/Agent/agency-agents/examples/workflow-landing-page.md
View File

@@ -1,119 +1,119 @@
# Multi-Agent Workflow: Landing Page Sprint
> Ship a conversion-optimized landing page in one day using 4 agents.
## The Scenario
You need a landing page for a new product launch. It needs to look great, convert visitors, and be live by end of day.
## Agent Team
| Agent | Role in this workflow |
|-------|---------------------|
| Content Creator | Write the copy |
| UI Designer | Design the layout and component specs |
| Frontend Developer | Build it |
| Growth Hacker | Optimize for conversion |
## The Workflow
### Morning: Copy + Design (parallel)
**Step 1a — Activate Content Creator**
```
Activate Content Creator.
Write landing page copy for "FlowSync" — an API integration platform
that connects any two SaaS tools in under 5 minutes.
Target audience: developers and technical PMs at mid-size companies.
Tone: confident, concise, slightly playful.
Sections needed:
1. Hero (headline + subheadline + CTA)
2. Problem statement (3 pain points)
3. How it works (3 steps)
4. Social proof (placeholder testimonial format)
5. Pricing (3 tiers: Free, Pro, Enterprise)
6. Final CTA
Keep it scannable. No fluff.
```
**Step 1b — Activate UI Designer (in parallel)**
```
Activate UI Designer.
Design specs for a SaaS landing page. Product: FlowSync (API integration platform).
Style: clean, modern, dark mode option. Think Linear or Vercel aesthetic.
Deliver:
1. Layout wireframe (section order + spacing)
2. Color palette (primary, secondary, accent, background)
3. Typography (font pairing, heading sizes, body size)
4. Component specs: hero section, feature cards, pricing table, CTA buttons
5. Responsive breakpoints (mobile, tablet, desktop)
```
### Midday: Build
**Step 2 — Activate Frontend Developer**
```
Activate Frontend Developer.
Build a landing page from these specs:
Copy: [paste Content Creator output]
Design: [paste UI Designer output]
Stack: HTML, Tailwind CSS, minimal vanilla JS (no framework needed).
Requirements:
- Responsive (mobile-first)
- Fast (no heavy assets, system fonts OK)
- Accessible (proper headings, alt text, focus states)
- Include a working email signup form (action URL: /api/subscribe)
Deliver a single index.html file ready to deploy.
```
### Afternoon: Optimize
**Step 3 — Activate Growth Hacker**
```
Activate Growth Hacker.
Review this landing page for conversion optimization:
[paste the HTML or describe the current page]
Evaluate:
1. Is the CTA above the fold?
2. Is the value proposition clear in under 5 seconds?
3. Any friction in the signup flow?
4. What A/B tests would you run first?
5. SEO basics: meta tags, OG tags, structured data
Give me specific changes, not general advice.
```
## Timeline
| Time | Activity | Agent |
|------|----------|-------|
| 9:00 | Copy + design kick off (parallel) | Content Creator + UI Designer |
| 11:00 | Build starts | Frontend Developer |
| 14:00 | First version ready | — |
| 14:30 | Conversion review | Growth Hacker |
| 15:30 | Apply feedback | Frontend Developer |
| 16:30 | Ship | Deploy to Vercel/Netlify |
## Key Patterns
1. **Parallel kickoff**: Copy and design happen at the same time since they're independent
2. **Merge point**: Frontend Developer needs both outputs before starting
3. **Feedback loop**: Growth Hacker reviews, then Frontend Developer applies changes
4. **Time-boxed**: Each step has a clear timebox to prevent scope creep
# Multi-Agent Workflow: Landing Page Sprint
> Ship a conversion-optimized landing page in one day using 4 agents.
## The Scenario
You need a landing page for a new product launch. It needs to look great, convert visitors, and be live by end of day.
## Agent Team
| Agent | Role in this workflow |
|-------|---------------------|
| Content Creator | Write the copy |
| UI Designer | Design the layout and component specs |
| Frontend Developer | Build it |
| Growth Hacker | Optimize for conversion |
## The Workflow
### Morning: Copy + Design (parallel)
**Step 1a — Activate Content Creator**
```
Activate Content Creator.
Write landing page copy for "FlowSync" — an API integration platform
that connects any two SaaS tools in under 5 minutes.
Target audience: developers and technical PMs at mid-size companies.
Tone: confident, concise, slightly playful.
Sections needed:
1. Hero (headline + subheadline + CTA)
2. Problem statement (3 pain points)
3. How it works (3 steps)
4. Social proof (placeholder testimonial format)
5. Pricing (3 tiers: Free, Pro, Enterprise)
6. Final CTA
Keep it scannable. No fluff.
```
**Step 1b — Activate UI Designer (in parallel)**
```
Activate UI Designer.
Design specs for a SaaS landing page. Product: FlowSync (API integration platform).
Style: clean, modern, dark mode option. Think Linear or Vercel aesthetic.
Deliver:
1. Layout wireframe (section order + spacing)
2. Color palette (primary, secondary, accent, background)
3. Typography (font pairing, heading sizes, body size)
4. Component specs: hero section, feature cards, pricing table, CTA buttons
5. Responsive breakpoints (mobile, tablet, desktop)
```
### Midday: Build
**Step 2 — Activate Frontend Developer**
```
Activate Frontend Developer.
Build a landing page from these specs:
Copy: [paste Content Creator output]
Design: [paste UI Designer output]
Stack: HTML, Tailwind CSS, minimal vanilla JS (no framework needed).
Requirements:
- Responsive (mobile-first)
- Fast (no heavy assets, system fonts OK)
- Accessible (proper headings, alt text, focus states)
- Include a working email signup form (action URL: /api/subscribe)
Deliver a single index.html file ready to deploy.
```
### Afternoon: Optimize
**Step 3 — Activate Growth Hacker**
```
Activate Growth Hacker.
Review this landing page for conversion optimization:
[paste the HTML or describe the current page]
Evaluate:
1. Is the CTA above the fold?
2. Is the value proposition clear in under 5 seconds?
3. Any friction in the signup flow?
4. What A/B tests would you run first?
5. SEO basics: meta tags, OG tags, structured data
Give me specific changes, not general advice.
```
## Timeline
| Time | Activity | Agent |
|------|----------|-------|
| 9:00 | Copy + design kick off (parallel) | Content Creator + UI Designer |
| 11:00 | Build starts | Frontend Developer |
| 14:00 | First version ready | — |
| 14:30 | Conversion review | Growth Hacker |
| 15:30 | Apply feedback | Frontend Developer |
| 16:30 | Ship | Deploy to Vercel/Netlify |
## Key Patterns
1. **Parallel kickoff**: Copy and design happen at the same time since they're independent
2. **Merge point**: Frontend Developer needs both outputs before starting
3. **Feedback loop**: Growth Hacker reviews, then Frontend Developer applies changes
4. **Time-boxed**: Each step has a clear timebox to prevent scope creep

310
raw/Agent/agency-agents/examples/workflow-startup-mvp.md
View File

@@ -1,155 +1,155 @@
# Multi-Agent Workflow: Startup MVP
> A step-by-step example of how to coordinate multiple agents to go from idea to shipped MVP.
## The Scenario
You're building a SaaS MVP — a team retrospective tool for remote teams. You have 4 weeks to ship a working product with user signups, a core feature, and a landing page.
## Agent Team
| Agent | Role in this workflow |
|-------|---------------------|
| Sprint Prioritizer | Break the project into weekly sprints |
| UX Researcher | Validate the idea with quick user interviews |
| Backend Architect | Design the API and data model |
| Frontend Developer | Build the React app |
| Rapid Prototyper | Get the first version running fast |
| Growth Hacker | Plan launch strategy while building |
| Reality Checker | Gate each milestone before moving on |
## The Workflow
### Week 1: Discovery + Architecture
**Step 1 — Activate Sprint Prioritizer**
```
Activate Sprint Prioritizer.
Project: RetroBoard — a real-time team retrospective tool for remote teams.
Timeline: 4 weeks to MVP launch.
Core features: user auth, create retro boards, add cards, vote, action items.
Constraints: solo developer, React + Node.js stack, deploy to Vercel + Railway.
Break this into 4 weekly sprints with clear deliverables and acceptance criteria.
```
**Step 2 — Activate UX Researcher (in parallel)**
```
Activate UX Researcher.
I'm building a team retrospective tool for remote teams (5-20 people).
Competitors: EasyRetro, Retrium, Parabol.
Run a quick competitive analysis and identify:
1. What features are table stakes
2. Where competitors fall short
3. One differentiator we could own
Output a 1-page research brief.
```
**Step 3 — Hand off to Backend Architect**
```
Activate Backend Architect.
Here's our sprint plan: [paste Sprint Prioritizer output]
Here's our research brief: [paste UX Researcher output]
Design the API and database schema for RetroBoard.
Stack: Node.js, Express, PostgreSQL, Socket.io for real-time.
Deliver:
1. Database schema (SQL)
2. REST API endpoints list
3. WebSocket events for real-time board updates
4. Auth strategy recommendation
```
### Week 2: Build Core Features
**Step 4 — Activate Frontend Developer + Rapid Prototyper**
```
Activate Frontend Developer.
Here's the API spec: [paste Backend Architect output]
Build the RetroBoard React app:
- Stack: React, TypeScript, Tailwind, Socket.io-client
- Pages: Login, Dashboard, Board view
- Components: RetroCard, VoteButton, ActionItem, BoardColumn
Start with the Board view — it's the core experience.
Focus on real-time: when one user adds a card, everyone sees it.
```
**Step 5 — Reality Check at midpoint**
```
Activate Reality Checker.
We're at week 2 of a 4-week MVP build for RetroBoard.
Here's what we have so far:
- Database schema: [paste]
- API endpoints: [paste]
- Frontend components: [paste]
Evaluate:
1. Can we realistically ship in 2 more weeks?
2. What should we cut to make the deadline?
3. Any technical debt that will bite us at launch?
```
### Week 3: Polish + Landing Page
**Step 6 — Frontend Developer continues, Growth Hacker starts**
```
Activate Growth Hacker.
Product: RetroBoard — team retrospective tool, launching in 1 week.
Target: Engineering managers and scrum masters at remote-first companies.
Budget: $0 (organic launch only).
Create a launch plan:
1. Landing page copy (hero, features, CTA)
2. Launch channels (Product Hunt, Reddit, Hacker News, Twitter)
3. Day-by-day launch sequence
4. Metrics to track in week 1
```
### Week 4: Launch
**Step 7 — Final Reality Check**
```
Activate Reality Checker.
RetroBoard is ready to launch. Evaluate production readiness:
- Live URL: [url]
- Test accounts created: yes
- Error monitoring: Sentry configured
- Database backups: daily automated
Run through the launch checklist and give a GO / NO-GO decision.
Require evidence for each criterion.
```
## Key Patterns
1. **Sequential handoffs**: Each agent's output becomes the next agent's input
2. **Parallel work**: UX Researcher and Sprint Prioritizer can run simultaneously in Week 1
3. **Quality gates**: Reality Checker at midpoint and before launch prevents shipping broken code
4. **Context passing**: Always paste previous agent outputs into the next prompt — agents don't share memory
## Tips
- Copy-paste agent outputs between steps — don't summarize, use the full output
- If a Reality Checker flags an issue, loop back to the relevant specialist to fix it
- Keep the Orchestrator agent in mind for automating this flow once you're comfortable with the manual version
# Multi-Agent Workflow: Startup MVP
> A step-by-step example of how to coordinate multiple agents to go from idea to shipped MVP.
## The Scenario
You're building a SaaS MVP — a team retrospective tool for remote teams. You have 4 weeks to ship a working product with user signups, a core feature, and a landing page.
## Agent Team
| Agent | Role in this workflow |
|-------|---------------------|
| Sprint Prioritizer | Break the project into weekly sprints |
| UX Researcher | Validate the idea with quick user interviews |
| Backend Architect | Design the API and data model |
| Frontend Developer | Build the React app |
| Rapid Prototyper | Get the first version running fast |
| Growth Hacker | Plan launch strategy while building |
| Reality Checker | Gate each milestone before moving on |
## The Workflow
### Week 1: Discovery + Architecture
**Step 1 — Activate Sprint Prioritizer**
```
Activate Sprint Prioritizer.
Project: RetroBoard — a real-time team retrospective tool for remote teams.
Timeline: 4 weeks to MVP launch.
Core features: user auth, create retro boards, add cards, vote, action items.
Constraints: solo developer, React + Node.js stack, deploy to Vercel + Railway.
Break this into 4 weekly sprints with clear deliverables and acceptance criteria.
```
**Step 2 — Activate UX Researcher (in parallel)**
```
Activate UX Researcher.
I'm building a team retrospective tool for remote teams (5-20 people).
Competitors: EasyRetro, Retrium, Parabol.
Run a quick competitive analysis and identify:
1. What features are table stakes
2. Where competitors fall short
3. One differentiator we could own
Output a 1-page research brief.
```
**Step 3 — Hand off to Backend Architect**
```
Activate Backend Architect.
Here's our sprint plan: [paste Sprint Prioritizer output]
Here's our research brief: [paste UX Researcher output]
Design the API and database schema for RetroBoard.
Stack: Node.js, Express, PostgreSQL, Socket.io for real-time.
Deliver:
1. Database schema (SQL)
2. REST API endpoints list
3. WebSocket events for real-time board updates
4. Auth strategy recommendation
```
### Week 2: Build Core Features
**Step 4 — Activate Frontend Developer + Rapid Prototyper**
```
Activate Frontend Developer.
Here's the API spec: [paste Backend Architect output]
Build the RetroBoard React app:
- Stack: React, TypeScript, Tailwind, Socket.io-client
- Pages: Login, Dashboard, Board view
- Components: RetroCard, VoteButton, ActionItem, BoardColumn
Start with the Board view — it's the core experience.
Focus on real-time: when one user adds a card, everyone sees it.
```
**Step 5 — Reality Check at midpoint**
```
Activate Reality Checker.
We're at week 2 of a 4-week MVP build for RetroBoard.
Here's what we have so far:
- Database schema: [paste]
- API endpoints: [paste]
- Frontend components: [paste]
Evaluate:
1. Can we realistically ship in 2 more weeks?
2. What should we cut to make the deadline?
3. Any technical debt that will bite us at launch?
```
### Week 3: Polish + Landing Page
**Step 6 — Frontend Developer continues, Growth Hacker starts**
```
Activate Growth Hacker.
Product: RetroBoard — team retrospective tool, launching in 1 week.
Target: Engineering managers and scrum masters at remote-first companies.
Budget: $0 (organic launch only).
Create a launch plan:
1. Landing page copy (hero, features, CTA)
2. Launch channels (Product Hunt, Reddit, Hacker News, Twitter)
3. Day-by-day launch sequence
4. Metrics to track in week 1
```
### Week 4: Launch
**Step 7 — Final Reality Check**
```
Activate Reality Checker.
RetroBoard is ready to launch. Evaluate production readiness:
- Live URL: [url]
- Test accounts created: yes
- Error monitoring: Sentry configured
- Database backups: daily automated
Run through the launch checklist and give a GO / NO-GO decision.
Require evidence for each criterion.
```
## Key Patterns
1. **Sequential handoffs**: Each agent's output becomes the next agent's input
2. **Parallel work**: UX Researcher and Sprint Prioritizer can run simultaneously in Week 1
3. **Quality gates**: Reality Checker at midpoint and before launch prevents shipping broken code
4. **Context passing**: Always paste previous agent outputs into the next prompt — agents don't share memory
## Tips
- Copy-paste agent outputs between steps — don't summarize, use the full output
- If a Reality Checker flags an issue, loop back to the relevant specialist to fix it
- Keep the Orchestrator agent in mind for automating this flow once you're comfortable with the manual version

476
raw/Agent/agency-agents/examples/workflow-with-memory.md
View File

@@ -1,238 +1,238 @@
# Multi-Agent Workflow: Startup MVP with Persistent Memory
> The same startup MVP workflow from [workflow-startup-mvp.md](workflow-startup-mvp.md), but with an MCP memory server handling state between agents. No more copy-paste handoffs.
## The Problem with Manual Handoffs
In the standard workflow, every agent-to-agent transition looks like this:
```
Activate Backend Architect.
Here's our sprint plan: [paste Sprint Prioritizer output]
Here's our research brief: [paste UX Researcher output]
Design the API and database schema for RetroBoard.
...
```
You are the glue. You copy-paste outputs between agents, keep track of what's been done, and hope you don't lose context along the way. It works for small projects, but it falls apart when:
- Sessions time out and you lose the output
- Multiple agents need the same context
- QA fails and you need to rewind to a previous state
- The project spans days or weeks across many sessions
## The Fix
With an MCP memory server installed, agents store their deliverables in memory and retrieve what they need automatically. Handoffs become:
```
Activate Backend Architect.
Project: RetroBoard. Recall previous context for this project
and design the API and database schema.
```
The agent searches memory for RetroBoard context, finds the sprint plan and research brief stored by previous agents, and picks up from there.
## Setup
Install any MCP-compatible memory server that supports `remember`, `recall`, and `rollback` operations. See [integrations/mcp-memory/README.md](../integrations/mcp-memory/README.md) for setup.
## The Scenario
Same as the standard workflow: a SaaS team retrospective tool (RetroBoard), 4 weeks to MVP, solo developer.
## Agent Team
| Agent | Role in this workflow |
|-------|---------------------|
| Sprint Prioritizer | Break the project into weekly sprints |
| UX Researcher | Validate the idea with quick user interviews |
| Backend Architect | Design the API and data model |
| Frontend Developer | Build the React app |
| Rapid Prototyper | Get the first version running fast |
| Growth Hacker | Plan launch strategy while building |
| Reality Checker | Gate each milestone before moving on |
Each agent has a Memory Integration section in their prompt (see [integrations/mcp-memory/README.md](../integrations/mcp-memory/README.md) for how to add it).
## The Workflow
### Week 1: Discovery + Architecture
**Step 1 — Activate Sprint Prioritizer**
```
Activate Sprint Prioritizer.
Project: RetroBoard — a real-time team retrospective tool for remote teams.
Timeline: 4 weeks to MVP launch.
Core features: user auth, create retro boards, add cards, vote, action items.
Constraints: solo developer, React + Node.js stack, deploy to Vercel + Railway.
Break this into 4 weekly sprints with clear deliverables and acceptance criteria.
Remember your sprint plan tagged for this project when done.
```
The Sprint Prioritizer produces the sprint plan and stores it in memory tagged with `sprint-prioritizer`, `retroboard`, and `sprint-plan`.
**Step 2 — Activate UX Researcher (in parallel)**
```
Activate UX Researcher.
I'm building a team retrospective tool for remote teams (5-20 people).
Competitors: EasyRetro, Retrium, Parabol.
Run a quick competitive analysis and identify:
1. What features are table stakes
2. Where competitors fall short
3. One differentiator we could own
Output a 1-page research brief. Remember it tagged for this project when done.
```
The UX Researcher stores the research brief tagged with `ux-researcher`, `retroboard`, and `research-brief`.
**Step 3 — Hand off to Backend Architect**
```
Activate Backend Architect.
Project: RetroBoard. Recall the sprint plan and research brief from previous agents.
Stack: Node.js, Express, PostgreSQL, Socket.io for real-time.
Design:
1. Database schema (SQL)
2. REST API endpoints list
3. WebSocket events for real-time board updates
4. Auth strategy recommendation
Remember each deliverable tagged for this project and for the frontend-developer.
```
The Backend Architect recalls the sprint plan and research brief from memory automatically. No copy-paste. It stores its schema and API spec tagged with `backend-architect`, `retroboard`, `api-spec`, and `frontend-developer`.
### Week 2: Build Core Features
**Step 4 — Activate Frontend Developer + Rapid Prototyper**
```
Activate Frontend Developer.
Project: RetroBoard. Recall the API spec and schema from the Backend Architect.
Build the RetroBoard React app:
- Stack: React, TypeScript, Tailwind, Socket.io-client
- Pages: Login, Dashboard, Board view
- Components: RetroCard, VoteButton, ActionItem, BoardColumn
Start with the Board view — it's the core experience.
Focus on real-time: when one user adds a card, everyone sees it.
Remember your progress tagged for this project.
```
The Frontend Developer pulls the API spec from memory and builds against it.
**Step 5 — Reality Check at midpoint**
```
Activate Reality Checker.
Project: RetroBoard. We're at week 2 of a 4-week MVP build.
Recall all deliverables from previous agents for this project.
Evaluate:
1. Can we realistically ship in 2 more weeks?
2. What should we cut to make the deadline?
3. Any technical debt that will bite us at launch?
Remember your verdict tagged for this project.
```
The Reality Checker has full visibility into everything produced so far — the sprint plan, research brief, schema, API spec, and frontend progress — without you having to collect and paste it all.
### Week 3: Polish + Landing Page
**Step 6 — Frontend Developer continues, Growth Hacker starts**
```
Activate Growth Hacker.
Product: RetroBoard — team retrospective tool, launching in 1 week.
Target: Engineering managers and scrum masters at remote-first companies.
Budget: $0 (organic launch only).
Recall the project context and Reality Checker's verdict.
Create a launch plan:
1. Landing page copy (hero, features, CTA)
2. Launch channels (Product Hunt, Reddit, Hacker News, Twitter)
3. Day-by-day launch sequence
4. Metrics to track in week 1
Remember the launch plan tagged for this project.
```
### Week 4: Launch
**Step 7 — Final Reality Check**
```
Activate Reality Checker.
Project: RetroBoard, ready to launch.
Recall all project context, previous verdicts, and the launch plan.
Evaluate production readiness:
- Live URL: [url]
- Test accounts created: yes
- Error monitoring: Sentry configured
- Database backups: daily automated
Run through the launch checklist and give a GO / NO-GO decision.
Require evidence for each criterion.
```
### When QA Fails: Rollback
In the standard workflow, when the Reality Checker rejects a deliverable, you go back to the responsible agent and try to explain what went wrong. With memory, the recovery loop is tighter:
```
Activate Backend Architect.
Project: RetroBoard. The Reality Checker flagged issues with the API design.
Recall the Reality Checker's feedback and your previous API spec.
Roll back to your last known-good schema and address the specific issues raised.
Remember the updated deliverables when done.
```
The Backend Architect can see exactly what the Reality Checker flagged, recall its own previous work, roll back to a checkpoint, and produce a fix — all without you manually tracking versions.
## Before and After
| Aspect | Standard Workflow | With Memory |
|--------|------------------|-------------|
| **Handoffs** | Copy-paste full output between agents | Agents recall what they need automatically |
| **Context loss** | Session timeouts lose everything | Memories persist across sessions |
| **Multi-agent context** | Manually compile context from N agents | Agent searches memory for project tag |
| **QA failure recovery** | Manually describe what went wrong | Agent recalls feedback + rolls back |
| **Multi-day projects** | Re-establish context every session | Agent picks up where it left off |
| **Setup required** | None | Install an MCP memory server |
## Key Patterns
1. **Tag everything with the project name**: This is what makes recall work. Every memory gets tagged with `retroboard` (or whatever your project is).
2. **Tag deliverables for the receiving agent**: When the Backend Architect finishes an API spec, it tags the memory with `frontend-developer` so the Frontend Developer finds it on recall.
3. **Reality Checker gets full visibility**: Because all agents store their work in memory, the Reality Checker can recall everything for the project without you compiling it.
4. **Rollback replaces manual undo**: When something fails, roll back to the last checkpoint instead of trying to figure out what changed.
## Tips
- You don't need to modify every agent at once. Start by adding Memory Integration to the agents you use most and expand from there.
- The memory instructions are prompts, not code. The LLM interprets them and calls the MCP tools as needed. You can adjust the wording to match your style.
- Any MCP-compatible memory server that supports `remember`, `recall`, `rollback`, and `search` tools will work with this workflow.
# Multi-Agent Workflow: Startup MVP with Persistent Memory
> The same startup MVP workflow from [workflow-startup-mvp.md](workflow-startup-mvp.md), but with an MCP memory server handling state between agents. No more copy-paste handoffs.
## The Problem with Manual Handoffs
In the standard workflow, every agent-to-agent transition looks like this:
```
Activate Backend Architect.
Here's our sprint plan: [paste Sprint Prioritizer output]
Here's our research brief: [paste UX Researcher output]
Design the API and database schema for RetroBoard.
...
```
You are the glue. You copy-paste outputs between agents, keep track of what's been done, and hope you don't lose context along the way. It works for small projects, but it falls apart when:
- Sessions time out and you lose the output
- Multiple agents need the same context
- QA fails and you need to rewind to a previous state
- The project spans days or weeks across many sessions
## The Fix
With an MCP memory server installed, agents store their deliverables in memory and retrieve what they need automatically. Handoffs become:
```
Activate Backend Architect.
Project: RetroBoard. Recall previous context for this project
and design the API and database schema.
```
The agent searches memory for RetroBoard context, finds the sprint plan and research brief stored by previous agents, and picks up from there.
## Setup
Install any MCP-compatible memory server that supports `remember`, `recall`, and `rollback` operations. See [integrations/mcp-memory/README.md](../integrations/mcp-memory/README.md) for setup.
## The Scenario
Same as the standard workflow: a SaaS team retrospective tool (RetroBoard), 4 weeks to MVP, solo developer.
## Agent Team
| Agent | Role in this workflow |
|-------|---------------------|
| Sprint Prioritizer | Break the project into weekly sprints |
| UX Researcher | Validate the idea with quick user interviews |
| Backend Architect | Design the API and data model |
| Frontend Developer | Build the React app |
| Rapid Prototyper | Get the first version running fast |
| Growth Hacker | Plan launch strategy while building |
| Reality Checker | Gate each milestone before moving on |
Each agent has a Memory Integration section in their prompt (see [integrations/mcp-memory/README.md](../integrations/mcp-memory/README.md) for how to add it).
## The Workflow
### Week 1: Discovery + Architecture
**Step 1 — Activate Sprint Prioritizer**
```
Activate Sprint Prioritizer.
Project: RetroBoard — a real-time team retrospective tool for remote teams.
Timeline: 4 weeks to MVP launch.
Core features: user auth, create retro boards, add cards, vote, action items.
Constraints: solo developer, React + Node.js stack, deploy to Vercel + Railway.
Break this into 4 weekly sprints with clear deliverables and acceptance criteria.
Remember your sprint plan tagged for this project when done.
```
The Sprint Prioritizer produces the sprint plan and stores it in memory tagged with `sprint-prioritizer`, `retroboard`, and `sprint-plan`.
**Step 2 — Activate UX Researcher (in parallel)**
```
Activate UX Researcher.
I'm building a team retrospective tool for remote teams (5-20 people).
Competitors: EasyRetro, Retrium, Parabol.
Run a quick competitive analysis and identify:
1. What features are table stakes
2. Where competitors fall short
3. One differentiator we could own
Output a 1-page research brief. Remember it tagged for this project when done.
```
The UX Researcher stores the research brief tagged with `ux-researcher`, `retroboard`, and `research-brief`.
**Step 3 — Hand off to Backend Architect**
```
Activate Backend Architect.
Project: RetroBoard. Recall the sprint plan and research brief from previous agents.
Stack: Node.js, Express, PostgreSQL, Socket.io for real-time.
Design:
1. Database schema (SQL)
2. REST API endpoints list
3. WebSocket events for real-time board updates
4. Auth strategy recommendation
Remember each deliverable tagged for this project and for the frontend-developer.
```
The Backend Architect recalls the sprint plan and research brief from memory automatically. No copy-paste. It stores its schema and API spec tagged with `backend-architect`, `retroboard`, `api-spec`, and `frontend-developer`.
### Week 2: Build Core Features
**Step 4 — Activate Frontend Developer + Rapid Prototyper**
```
Activate Frontend Developer.
Project: RetroBoard. Recall the API spec and schema from the Backend Architect.
Build the RetroBoard React app:
- Stack: React, TypeScript, Tailwind, Socket.io-client
- Pages: Login, Dashboard, Board view
- Components: RetroCard, VoteButton, ActionItem, BoardColumn
Start with the Board view — it's the core experience.
Focus on real-time: when one user adds a card, everyone sees it.
Remember your progress tagged for this project.
```
The Frontend Developer pulls the API spec from memory and builds against it.
**Step 5 — Reality Check at midpoint**
```
Activate Reality Checker.
Project: RetroBoard. We're at week 2 of a 4-week MVP build.
Recall all deliverables from previous agents for this project.
Evaluate:
1. Can we realistically ship in 2 more weeks?
2. What should we cut to make the deadline?
3. Any technical debt that will bite us at launch?
Remember your verdict tagged for this project.
```
The Reality Checker has full visibility into everything produced so far — the sprint plan, research brief, schema, API spec, and frontend progress — without you having to collect and paste it all.
### Week 3: Polish + Landing Page
**Step 6 — Frontend Developer continues, Growth Hacker starts**
```
Activate Growth Hacker.
Product: RetroBoard — team retrospective tool, launching in 1 week.
Target: Engineering managers and scrum masters at remote-first companies.
Budget: $0 (organic launch only).
Recall the project context and Reality Checker's verdict.
Create a launch plan:
1. Landing page copy (hero, features, CTA)
2. Launch channels (Product Hunt, Reddit, Hacker News, Twitter)
3. Day-by-day launch sequence
4. Metrics to track in week 1
Remember the launch plan tagged for this project.
```
### Week 4: Launch
**Step 7 — Final Reality Check**
```
Activate Reality Checker.
Project: RetroBoard, ready to launch.
Recall all project context, previous verdicts, and the launch plan.
Evaluate production readiness:
- Live URL: [url]
- Test accounts created: yes
- Error monitoring: Sentry configured
- Database backups: daily automated
Run through the launch checklist and give a GO / NO-GO decision.
Require evidence for each criterion.
```
### When QA Fails: Rollback
In the standard workflow, when the Reality Checker rejects a deliverable, you go back to the responsible agent and try to explain what went wrong. With memory, the recovery loop is tighter:
```
Activate Backend Architect.
Project: RetroBoard. The Reality Checker flagged issues with the API design.
Recall the Reality Checker's feedback and your previous API spec.
Roll back to your last known-good schema and address the specific issues raised.
Remember the updated deliverables when done.
```
The Backend Architect can see exactly what the Reality Checker flagged, recall its own previous work, roll back to a checkpoint, and produce a fix — all without you manually tracking versions.
## Before and After
| Aspect | Standard Workflow | With Memory |
|--------|------------------|-------------|
| **Handoffs** | Copy-paste full output between agents | Agents recall what they need automatically |
| **Context loss** | Session timeouts lose everything | Memories persist across sessions |
| **Multi-agent context** | Manually compile context from N agents | Agent searches memory for project tag |
| **QA failure recovery** | Manually describe what went wrong | Agent recalls feedback + rolls back |
| **Multi-day projects** | Re-establish context every session | Agent picks up where it left off |
| **Setup required** | None | Install an MCP memory server |
## Key Patterns
1. **Tag everything with the project name**: This is what makes recall work. Every memory gets tagged with `retroboard` (or whatever your project is).
2. **Tag deliverables for the receiving agent**: When the Backend Architect finishes an API spec, it tags the memory with `frontend-developer` so the Frontend Developer finds it on recall.
3. **Reality Checker gets full visibility**: Because all agents store their work in memory, the Reality Checker can recall everything for the project without you compiling it.
4. **Rollback replaces manual undo**: When something fails, roll back to the last checkpoint instead of trying to figure out what changed.
## Tips
- You don't need to modify every agent at once. Start by adding Memory Integration to the agents you use most and expand from there.
- The memory instructions are prompts, not code. The LLM interprets them and calls the MCP tools as needed. You can adjust the wording to match your style.
- Any MCP-compatible memory server that supports `remember`, `recall`, `rollback`, and `search` tools will work with this workflow.