Multiple Projects Management
When you work on several projects at once, context bleeding and ambiguous prompts become your biggest problems. Here is how to structure your workspace and communicate clearly across projects.
If you juggle multiple projects, you know the context switch tax. Each project has its own stack, conventions, decisions, and current state. When you come back to one after a week away, you need to reorient. The same thing happens with AI agents, except you can manage it.
OpenClaw's workspace structure supports multiple projects cleanly if you set it up right.
TL;DR: Use explicit context in prompts when working across projects. Keep project-specific files in their own directories. Update memory to reflect which project you are in and what matters about it. Ambiguous prompts produce ambiguous results.
Workspace Directory Structure
The workspace root is at /root/.openclaw/workspace. Under it, each project gets its own subdirectory.
/workspace /project-a /project-b /shared-tools
Shared utilities, scripts, or configs that apply across projects live at the workspace root or in a dedicated shared folder. Project-specific files live inside each project directory.
When you work on project-a, the agent has context about project-a. When you switch to project-b, you should be explicit about the switch. The agent reads from whatever directory you are referencing, so "fix the auth bug" in project-b is different from "fix the auth bug" in project-a.
This sounds obvious but it is the root of most multi-project confusion. Explicit beats implicit.
Explicit vs Implicit Context
OpenClaw has good implicit context from workspace files and memory. It knows your name, your timezone, your conventions. But when you are working across multiple projects, implicit context is not enough.
Explicit context is when you tell the agent exactly which project, which file, which issue you are referring to. "In project-a, add user registration" is explicit. "Add user registration" is ambiguous when you have three projects.
The pattern for unambiguous prompts: specify the project or file you are referring to. If you want something done in a specific codebase, name it. If you want the agent to switch context, say so. "Switching to project-b. We are working on the checkout flow this week."
Over time, the agent builds memory about each project through your prompts and memory files. But the buildup is faster when you are explicit upfront.
Project Memory Files
Each project should have a memory anchor. This could be a README.md, a project-notes.md, or just entries in MEMORY.md that describe the project state.
At minimum, each project should capture: the tech stack, what the project does, the current development focus, and any outstanding decisions. A few bullet points in the daily log or a project README is enough.
When you finish a project or archive it, document that in the project notes. You do not want to come back in six months and wonder what state it was left in.
Project Switching
When you switch projects in a session, the agent does not automatically know unless you tell it. You can set context by referencing the project directory or explicitly stating the switch.
In practice, most sessions are project-specific. You message the agent about project-a, you are in project-a context. But if you ask about two different projects in the same session, be explicit about which one each request belongs to.
The agent can track multiple contexts in one session, but it needs you to label them. "For project-a: fix the login bug. For project-b: add the export feature." Clear labels produce clear results.
How to Give Unambiguous Prompts
The structure of a good multi-project prompt has three parts: context, instruction, and scope.
Context is what project, file, or area you are referring to. Instruction is what you want done. Scope is how much or how little of the change you want.
Example ambiguous prompt: "Update the API to use the new auth."
Example unambiguous prompt: "In project-a/src/auth/service.ts, refactor the token validation to use RS256 instead of HS256. Keep the existing interface intact, only change the algorithm."
The unambiguous version tells the agent exactly where to work, what to change, and what constraints to follow. It is not longer, it is just specific.
When in doubt, add one more detail. Name the project. Name the file. State the constraint. The agent will not mind the extra detail.
Avoiding Context Bleeding
Context bleeding happens when information from one project leaks into another. You mention a variable name from project-a, the agent uses it in project-b where it does not exist. Or you reference a bug fix from project-a when working on project-b.
The fix is simple: reset context when switching. Not literally, but mentally. When you move from one project to another, be deliberate about it. End the previous task before starting the next one. Close the loop on what you were working on.
OpenClaw sessions carry context, but you control that context by what you include in your messages. If you keep mixing projects in the same message, the agent will try to handle both, which often means it handles neither well.
Give each project its own space in the conversation. It makes everything cleaner.
Sources: OpenClaw Workspace Docs