{"kind":"AgentDefinition","metadata":{"namespace":"community","name":"multi-agent-workflow-startup-mvp-with-persistent-memory","version":"0.1.0"},"spec":{"agents_md":"# Multi-Agent Workflow: Startup MVP with Persistent Memory\n\n\u003e 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.\n\n## The Problem with Manual Handoffs\n\nIn the standard workflow, every agent-to-agent transition looks like this:\n\n```\nActivate Backend Architect.\n\nHere's our sprint plan: [paste Sprint Prioritizer output]\nHere's our research brief: [paste UX Researcher output]\n\nDesign the API and database schema for RetroBoard.\n...\n```\n\nYou 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:\n\n- Sessions time out and you lose the output\n- Multiple agents need the same context\n- QA fails and you need to rewind to a previous state\n- The project spans days or weeks across many sessions\n\n## The Fix\n\nWith an MCP memory server installed, agents store their deliverables in memory and retrieve what they need automatically. Handoffs become:\n\n```\nActivate Backend Architect.\n\nProject: RetroBoard. Recall previous context for this project\nand design the API and database schema.\n```\n\nThe agent searches memory for RetroBoard context, finds the sprint plan and research brief stored by previous agents, and picks up from there.\n\n## Setup\n\nInstall 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.\n\n## The Scenario\n\nSame as the standard workflow: a SaaS team retrospective tool (RetroBoard), 4 weeks to MVP, solo developer.\n\n## Agent Team\n\n| Agent | Role in this workflow |\n|-------|---------------------|\n| Sprint Prioritizer | Break the project into weekly sprints |\n| UX Researcher | Validate the idea with quick user interviews |\n| Backend Architect | Design the API and data model |\n| Frontend Developer | Build the React app |\n| Rapid Prototyper | Get the first version running fast |\n| Growth Hacker | Plan launch strategy while building |\n| Reality Checker | Gate each milestone before moving on |\n\nEach 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).\n\n## The Workflow\n\n### Week 1: Discovery + Architecture\n\n**Step 1 — Activate Sprint Prioritizer**\n\n```\nActivate Sprint Prioritizer.\n\nProject: RetroBoard — a real-time team retrospective tool for remote teams.\nTimeline: 4 weeks to MVP launch.\nCore features: user auth, create retro boards, add cards, vote, action items.\nConstraints: solo developer, React + Node.js stack, deploy to Vercel + Railway.\n\nBreak this into 4 weekly sprints with clear deliverables and acceptance criteria.\nRemember your sprint plan tagged for this project when done.\n```\n\nThe Sprint Prioritizer produces the sprint plan and stores it in memory tagged with `sprint-prioritizer`, `retroboard`, and `sprint-plan`.\n\n**Step 2 — Activate UX Researcher (in parallel)**\n\n```\nActivate UX Researcher.\n\nI'm building a team retrospective tool for remote teams (5-20 people).\nCompetitors: EasyRetro, Retrium, Parabol.\n\nRun a quick competitive analysis and identify:\n1. What features are table stakes\n2. Where competitors fall short\n3. One differentiator we could own\n\nOutput a 1-page research brief. Remember it tagged for this project when done.\n```\n\nThe UX Researcher stores the research brief tagged with `ux-researcher`, `retroboard`, and `research-brief`.\n\n**Step 3 — Hand off to Backend Architect**\n\n```\nActivate Backend Architect.\n\nProject: RetroBoard. Recall the sprint plan and research brief from previous agents.\nStack: Node.js, Express, PostgreSQL, Socket.io for real-time.\n\nDesign:\n1. Database schema (SQL)\n2. REST API endpoints list\n3. WebSocket events for real-time board updates\n4. Auth strategy recommendation\n\nRemember each deliverable tagged for this project and for the frontend-developer.\n```\n\nThe 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`.\n\n### Week 2: Build Core Features\n\n**Step 4 — Activate Frontend Developer + Rapid Prototyper**\n\n```\nActivate Frontend Developer.\n\nProject: RetroBoard. Recall the API spec and schema from the Backend Architect.\n\nBuild the RetroBoard React app:\n- Stack: React, TypeScript, Tailwind, Socket.io-client\n- Pages: Login, Dashboard, Board view\n- Components: RetroCard, VoteButton, ActionItem, BoardColumn\n\nStart with the Board view — it's the core experience.\nFocus on real-time: when one user adds a card, everyone sees it.\nRemember your progress tagged for this project.\n```\n\nThe Frontend Developer pulls the API spec from memory and builds against it.\n\n**Step 5 — Reality Check at midpoint**\n\n```\nActivate Reality Checker.\n\nProject: RetroBoard. We're at week 2 of a 4-week MVP build.\n\nRecall all deliverables from previous agents for this project.\n\nEvaluate:\n1. Can we realistically ship in 2 more weeks?\n2. What should we cut to make the deadline?\n3. Any technical debt that will bite us at launch?\n\nRemember your verdict tagged for this project.\n```\n\nThe 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.\n\n### Week 3: Polish + Landing Page\n\n**Step 6 — Frontend Developer continues, Growth Hacker starts**\n\n```\nActivate Growth Hacker.\n\nProduct: RetroBoard — team retrospective tool, launching in 1 week.\nTarget: Engineering managers and scrum masters at remote-first companies.\nBudget: $0 (organic launch only).\n\nRecall the project context and Reality Checker's verdict.\n\nCreate a launch plan:\n1. Landing page copy (hero, features, CTA)\n2. Launch channels (Product Hunt, Reddit, Hacker News, Twitter)\n3. Day-by-day launch sequence\n4. Metrics to track in week 1\n\nRemember the launch plan tagged for this project.\n```\n\n### Week 4: Launch\n\n**Step 7 — Final Reality Check**\n\n```\nActivate Reality Checker.\n\nProject: RetroBoard, ready to launch.\n\nRecall all project context, previous verdicts, and the launch plan.\n\nEvaluate production readiness:\n- Live URL: [url]\n- Test accounts created: yes\n- Error monitoring: Sentry configured\n- Database backups: daily automated\n\nRun through the launch checklist and give a GO / NO-GO decision.\nRequire evidence for each criterion.\n```\n\n### When QA Fails: Rollback\n\nIn 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:\n\n```\nActivate Backend Architect.\n\nProject: RetroBoard. The Reality Checker flagged issues with the API design.\nRecall the Reality Checker's feedback and your previous API spec.\nRoll back to your last known-good schema and address the specific issues raised.\nRemember the updated deliverables when done.\n```\n\nThe 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.\n\n## Before and After\n\n| Aspect | Standard Workflow | With Memory |\n|--------|------------------|-------------|\n| **Handoffs** | Copy-paste full output between agents | Agents recall what they need automatically |\n| **Context loss** | Session timeouts lose everything | Memories persist across sessions |\n| **Multi-agent context** | Manually compile context from N agents | Agent searches memory for project tag |\n| **QA failure recovery** | Manually describe what went wrong | Agent recalls feedback + rolls back |\n| **Multi-day projects** | Re-establish context every session | Agent picks up where it left off |\n| **Setup required** | None | Install an MCP memory server |\n\n## Key Patterns\n\n1. **Tag everything with the project name**: This is what makes recall work. Every memory gets tagged with `retroboard` (or whatever your project is).\n2. **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.\n3. **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.\n4. **Rollback replaces manual undo**: When something fails, roll back to the last checkpoint instead of trying to figure out what changed.\n\n## Tips\n\n- 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.\n- 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.\n- Any MCP-compatible memory server that supports `remember`, `recall`, `rollback`, and `search` tools will work with this workflow.\n","description":"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.","import":{"commit_sha":"783f6a72bfd7f3135700ac273c619d92821b419a","imported_at":"2026-05-18T20:06:30Z","license_text":"","owner":"msitarzewski","repo":"msitarzewski/agency-agents","source_url":"https://github.com/msitarzewski/agency-agents/blob/783f6a72bfd7f3135700ac273c619d92821b419a/examples/workflow-with-memory.md"},"manifest":{}},"content_hash":[215,45,77,201,222,133,55,227,213,130,228,204,52,42,27,26,34,76,22,128,133,208,34,52,239,175,25,56,98,88,34,238],"trust_level":"unsigned","yanked":false}