agentlas.cloud · Agentlas Agent Lab · agent_project_pm_soul
A project-scoped PM agent that preserves continuity, coordinates specialist agents, and keeps long-running work from losing its memory.
Long-running AI-assisted projects fail less often because a specialist agent is bad at one task, and more often because no agent owns the project memory. A deck agent may know how to build slides, a developer agent may know how to patch code, and a research agent may know how to gather sources; none of them should be forced to remember every folder, prior revision, stakeholder preference, decision, rejected option, risk, and handoff across months of work.
Project PM Soul proposes a different unit of persistence: the project folder. The PM soul is a durable project-scoped orchestrator that maintains one canonical project memory, frames ambiguous requests, decomposes work into workstreams, delegates to specialist agents with compact handoff briefs, verifies returned work, and updates memory only with durable facts and decisions. Specialist agents remain narrow and mostly stateless by default.
The hypothesis is grounded in three adjacent literatures: consulting delivery systems such as transformation offices and PMOs, project-memory research in project-based organizations, and multi-agent LLM work on orchestrator-worker architectures, handoffs, procedural memory, and hierarchical memory isolation.
Project memory, multi-agent systems, orchestrator-worker architecture, transformation office, PMO, scoped memory, procedural memory, handoff briefs, agent coordination, long-running AI workflows.
Can a project folder host a persistent PM soul that reduces repeated user context and improves specialist-agent coordination without leaking the full project history into every worker?
This repository contributes four concrete artifacts:
- A reusable agent contract in agent.md for a project-scoped PM soul.
- A research map in docs/consulting-workflow-map.md connecting consulting workflow primitives, project-memory research, and multi-agent LLM architecture.
- Two operational templates: project-soul-memory.md and handoff-brief.md.
- A design case study in docs/case-study-consulting-engagement.md that applies PM Soul to a consulting engagement spanning strategy, finance, and fact-finding work.
- An evaluation rubric in docs/evaluation.md for continuity, handoff precision, memory freshness, ownership clarity, and context minimization.
The dominant AI-agent pattern still treats memory as a conversation property. That works for short sessions, but it breaks down in consulting-like delivery work where the object is not one chat; it is a project that survives many sessions, agents, files, artifacts, decisions, and reversals.
Consulting teams solve a similar continuity problem with an engagement manager, workstream leads, steering cadence, decision logs, risk registers, and a single source of truth. Project PM Soul translates that operating model into an agent runtime contract:
| Consulting delivery primitive | Agent-system translation |
|---|---|
| Problem framing | Restate the decision, constraints, dependencies, and success criteria before routing work. |
| Workstreams | Decompose a vague request into bounded specialist tasks. |
| Transformation office / PMO | Keep cadence, ownership, risks, decisions, and synthesis in one place. |
| Single source of truth | Maintain project-soul-memory.md as the canonical current-state artifact. |
| Steering / escalation | Surface unresolved decisions to the user instead of hiding them inside worker output. |
| Lessons learned | Convert durable project learning into memory during the project, not only at closeout. |
McKinsey describes the transformation office as a central mechanism for cadence, accountability, transparency, escalation, and a single source of truth for initiative progress. Deloitte's Program and Transformation Management material similarly frames modern PMO/RMO work around intake, governance, processes, tools, program performance, and measurable outcomes rather than status reporting alone. PMI guidance on lessons learned emphasizes that learning should be captured during the project lifecycle, not only after the project ends.
Project PM Soul borrows the operating model, not the consulting theater. The goal is not to make an agent sound like a consultant. The goal is to give one project folder a durable coordination layer.
Project-memory research argues that project organizations are prone to knowledge fragmentation because teams are temporary and lessons disperse when a project ends. Kasvi et al. distinguish project memory, the knowledge from a project's history that can inform present work, from the project-memory system that realizes storage, retrieval, dissemination, and use.
More recent large-scale project research treats memory as an active practice, not merely a repository. Mariano and Awazu describe project memory as a set of ongoing co-orchestration practices that help teams align attention, discourse, and boundaries in complex implementation work.
This repository uses that distinction directly: project-soul-memory.md is not
a transcript dump. It is a curated current-state instrument.
Anthropic's multi-agent research system uses an orchestrator-worker pattern: a lead agent plans, spawns specialized subagents, and synthesizes results. OpenAI's Agents SDK documents related orchestration patterns where a manager agent can use specialists as tools or hand work off to another agent, with input filters controlling what context crosses boundaries.
Recent memory-oriented agent research sharpens the placement question. LEGOMem studies modular procedural memory for multi-agent workflow automation and reports that orchestrator memory supports decomposition and delegation, while fine-grained agent memory supports execution accuracy. AgentSys frames explicit hierarchical memory management as both a capability and safety mechanism: worker contexts stay isolated, and only schema-validated return values cross back to the main agent. Memory Matters surveys long-term memory as an open challenge for LLM agents, especially around memory types, lifecycle, and retrieval.
Project PM Soul makes one product-level claim from these threads: durable memory should live with the project owner; task specialists should receive minimal, scoped context.
User request
-> PM Soul intake
-> project memory retrieval
-> evidence inspection
-> problem framing
-> workstream decomposition
-> specialist handoff brief
-> specialist output
-> PM Soul verification and synthesis
-> memory update proposal
-> final status or next decision
The PM soul is persistent. Most specialists are ephemeral.
| Component | Owner | Purpose |
|---|---|---|
| Project charter | PM Soul | Stable purpose, scope, constraints, and success definition. |
| Current-state memory | PM Soul | What is true now about files, decisions, artifacts, and risks. |
| Decision log | PM Soul | Why choices were made and which alternatives were rejected. |
| Risk/action log | PM Soul | Open loops, blockers, owner, and escalation state. |
| Evidence index | PM Soul | File paths, source links, verification notes, and last-checked dates. |
| Handoff brief | PM Soul -> specialist | Compact task context, constraints, output contract, and acceptance checks. |
| Specialist output | Specialist -> PM Soul | Findings, artifact, risks, verification, and proposed memory updates. |
Project PM Soul follows a strict memory boundary:
- The project owns continuity.
- The PM soul curates project-wide memory.
- Specialists receive task-scoped context.
- Specialists do not need the full history of unrelated projects.
- Raw logs, credentials, private source material, and temporary speculation do not belong in public project memory.
- Memory writes should be evidence-backed and easy to deprecate when stale.
This boundary is the core design choice. Without it, every specialist agent becomes a bloated global notebook. With it, the PM soul acts as a project-level engagement manager while workers remain focused.
agent_project_pm_soul/
README.md research paper-style introduction
agent.md reusable PM Soul agent contract
docs/
case-study-consulting-engagement.md consulting workflow design case
consulting-workflow-map.md source-backed research map
repo-decisions.md public-safe repo decision log
evaluation.md evaluation rubric
research-log.md dated research notes
templates/
project-soul-memory.md canonical project memory template
handoff-brief.md specialist delegation template
assets/
project-pm-soul-workflow.svg workflow figure
agentlas-agent-lab-banner.svg shared Agentlas banner
scripts/
public_safety_check.sh public-data hygiene check
The root-level filename memory.md is intentionally ignored. In Agentlas
workflows, that name is reserved for local or project-specific memory, which can
contain private research context. Public decisions for this repo belong in
docs/repo-decisions.md; private scratch context belongs outside Git or under
.memory.local/.
Create a project memory file inside the target project:
<target-project>/
project-soul-memory.md
Start from:
templates/project-soul-memory.md
When the PM soul delegates work, create a handoff from:
templates/handoff-brief.md
The handoff should include:
- the specialist needed
- why that specialist is needed
- relevant project context
- files to inspect
- constraints and permissions
- scope boundary
- output contract
- acceptance checks
- proposed memory update format
The first experiment should compare two modes on the same long-running project:
| Mode | Description |
|---|---|
| Baseline | A general agent handles tasks with ordinary chat/project context. |
| PM Soul | A project-scoped PM soul maintains memory and routes specialists through handoff briefs. |
Measure:
- repeated-context events
- handoff brief length
- handoff precision
- memory freshness
- single-source-of-truth quality
- decision closure time
- specialist rework loops
- final artifact acceptance
The strongest early signal is not whether the PM soul sounds impressive. It is whether the user repeats less context while specialists receive smaller and cleaner task briefs.
See docs/case-study-consulting-engagement.md for a concrete consulting workflow that combines management consulting, financial consulting, and fact-finding research.
This repository is a research scaffold, not a claim that the architecture is already validated. Known risks:
- stale memory can become worse than no memory
- the PM soul may over-own work that should be delegated
- memory can become a transcript dump unless aggressively curated
- specialist handoffs can omit crucial context if the PM soul frames poorly
- public research notes must not leak private project material
Current status: local draft, public-safe scaffold.
Next milestones:
- Run a one-week field trial on one active project.
- Record repeated-context events and specialist handoff quality.
- Add examples of good and bad memory updates.
- Add a benchmark fixture with simulated project turns.
- Publish a short case study after private details are sanitized.
- McKinsey & Company. "The role of the transformation office."
https://www.mckinsey.com/capabilities/transformation/our-insights/the-role-of-the-transformation-office - McKinsey & Company. "How to master the seven-step problem-solving process."
https://www.mckinsey.com/capabilities/strategy-and-corporate-finance/our-insights/how-to-master-the-seven-step-problem-solving-process - Deloitte. "Program and Transformation Management services."
https://www.deloitte.com/us/en/services/consulting/services/program-and-transformation-management-services.html - Project Management Institute. "Lessons learned."
https://www.pmi.org/learning/library/lessons-learned-next-level-Communicating-7991 - Kasvi, J. J. J., Vartiainen, M., and Hailikari, M. "Managing knowledge and
knowledge competences in projects and project organisations." International
Journal of Project Management, 2003.
https://www.sciencedirect.com/science/article/pii/S0263786302000571 - Mariano, S., and Awazu, Y. "Managing large-scale projects: Unpacking the
role of project memory." International Journal of Project Management, 2024.
https://www.sciencedirect.com/science/article/pii/S0263786324000152 - Anthropic. "How we built our multi-agent research system."
https://www.anthropic.com/engineering/multi-agent-research-system - OpenAI Agents SDK. "Agent orchestration."
https://openai.github.io/openai-agents-python/multi_agent/ - OpenAI Agents SDK. "Handoffs."
https://openai.github.io/openai-agents-python/handoffs/ - Han, D. et al. "LEGOMem: Modular Procedural Memory for Multi-agent LLM
Systems for Workflow Automation." arXiv, 2025.
https://arxiv.org/abs/2510.04851 - Wen, R. et al. "AgentSys: Secure and Dynamic LLM Agents Through Explicit
Hierarchical Memory Management." arXiv, 2026.
https://arxiv.org/abs/2602.07398 - Hatalis, K. et al. "Memory Matters: The Need to Improve Long-Term Memory in
LLM-Agents." AAAI Spring Symposium, 2024.
https://ojs.aaai.org/index.php/AAAI-SS/article/view/27688
MIT. This repository is part of the Agentlas Agent Lab public research program.