If you're running three projects, three businesses, or three roles, the standard advice is to keep them in three apps so the contexts don't bleed. The standard advice is wrong. Three apps means switching tools eight times a day, re-learning each one's quirks, and re-typing the same kinds of notes in three slightly different formats. The contexts don't bleed because they're walled off; they also don't compound because they can't see each other.
The shape that actually works is one app with internally separated workspaces — top-level pages per project, sharp boundaries on what crosses, and an agent that can search across all of it on demand when you want it to and stay scoped when you don't. The same insight underwrites AI notes for fractional executives managing multiple engagements and managing a side business alongside your day job — both built on the premise that the consolidation is the upgrade, not the danger.
A vault shaped around all your projects, not just one
The shape that holds up across project counts is roughly: one top-level page per project, business, or role. Inside each, the structure that matches that project — sub-pages for clients, decisions, meetings, references, whatever the project demands. A separate top-level page for the "across-projects" layer: your weekly review, your goals, your shared learnings, the patterns you're noticing across the work.
Capy supports unlimited page nesting, so each project's internal structure can be as deep or as shallow as that project requires. A heavy consulting engagement might fan out across ten sub-pages; a side project might be one. The whole vault is plain markdown. That matters because when you ask the agent "what's open across all my projects this week," it reads across every page in one query and writes a unified status — not three separate statuses you have to mentally merge.
Per-project context the agent stays scoped to
The fear about consolidating projects is usually that the contexts will bleed in unhelpful ways — the agent will start drafting a client deliverable that uses framing from a different client, or a strategy memo for one business will leak into the operating notes for another. The fix is to be explicit about scope when it matters.
A working flow: when you ask the agent to draft something, name the project page in the prompt. "Read the running notes on the Client A page and draft a project update for them." The agent stays scoped to that page tree. When you want cross-project intelligence, ask differently. "Read across all my client pages and surface any patterns in the kinds of feedback I'm getting." The agent reads broadly. The scoping is intentional, not architectural.
This is the inverse of the apps-as-walls model: instead of paying a switching cost every day to enforce separation, you scope the agent each time you want it. (The same scoping pattern is the spine of how agency owners take on more work without hiring — different setting, same principle.)
Weekly review that actually runs across the whole portfolio
Most people running multiple projects skip the weekly review because it's structurally hard. Looking back across three projects in three apps means three reviews stacked on top of each other, which is a thing nobody actually does on a Friday afternoon.
A working flow: every Friday, ask the agent to read across all your project pages from the past week — the meeting recaps, the decisions logged, the followups closed and slipped — and draft a one-page review with four sections per project: what shipped, what slipped, what you learned, what's open for next week. The review takes twenty minutes instead of two hours, and it actually gets done.
The compounding effect is real. By the third month, you have a primary-source archive of how each project has evolved week by week, separate from the project's own internal artifacts. The patterns across projects start to surface — the kind of client work that consistently slips, the kind of decision that consistently turns out to be wrong, the kind of meeting that consistently runs over. You can act on those patterns instead of feeling them vaguely. (The weekly-review-from-vault habit is the same one underwriting annual planning and goal setting at a longer horizon.)
Decisions logged once per project, surfaced across all
Each project produces decisions with rationales. Most people running multiple projects keep those rationales in their head per project, which means the same kind of decision gets re-litigated independently in each context. You decided to pass on a partnership in Project A; six months later, you make a similar call in Project B without recognizing the pattern.
A working setup: each project page has an inline decisions database via the :::database::: directive — rows for date, decision, rationale, project, area affected. The database lives directly in the page, not in a separate tab. Same structure across every project, so the rationale fields are comparable.
When a similar decision comes up in a new context, ask the agent to search across decision databases for any prior decisions that share the same kind of trigger or rationale. The agent finds the prior calls and quotes them with their rationale. You're not deciding from blank; you're deciding from your own track record. (The same compounding decisions discipline is the spine of contract negotiation with AI notes.)
The "across-projects" page that holds the meta-work
The work that's about you specifically — your goals across projects, your learnings, your weekly review, the patterns you're noticing — doesn't belong on any one project page. A separate top-level "personal" or "across-projects" page holds it. The agent can read this page when it's drafting personal-level outputs (the year-end retrospective, the goals review, the personal newsletter to friends about what you've been up to) and stay scoped to project-level pages otherwise.
This is the layer where multi-project work actually pays off. The single-project version of you doesn't notice that you're consistently underestimating implementation timelines across all three contexts. The cross-project version, with the agent reading across pages, surfaces the pattern.
PDFs and cross-project conversations the agent threads together
You'll accumulate PDFs that are relevant to more than one project — a regulatory letter that affects two of your businesses, a partnership agreement that touches three different relationships, a financial document that matters across your entire portfolio. Most people store these in one project's folder and forget that they're relevant to the others.
Drop the PDF on the project where it primarily belongs. It auto-converts to markdown via docstrange, which means the agent can read it as searchable text. When you ask the agent a question across projects, it reads the PDF too — even if you stored it on a specific project page. The relevance crosses naturally, as long as the agent can see it.
This is what makes multi-project work actually compound: not just shared notes, but shared documents that cross-cut your portfolio.
Cross-project conversations work the same way. The catch-up with a peer who advises you on multiple things, the coaching conversation that touches your whole life — record in Capy and the transcript comes back with speaker diarization (labels like "Speaker 1: …") so you can tell who said what. Ask the agent to draft a recap with sections mapped to the relevant projects: what we discussed about Project A, what about Project B, what about the personal layer. The recap auto-distributes the meeting's value across the relevant project pages without you having to copy-paste between them.
What this isn't
Capy isn't a project-management tool. The structured side of each project — tickets, sprints, dashboards, billing — still lives in whatever tool that project uses. Capy is for the unstructured side: the writing, the rationale, the meeting recaps, the connective tissue across projects. That's the part that's currently sprawled across three apps and would benefit most from being in one place.
It's also single-user by design. One person, one vault, holding the connective layer for all your projects. If your work involves multi-person teams across each project where everyone needs to edit the same artifacts with role-based permissions, that isn't this product. The shape that fits is the principal — the founder running multiple businesses, the consultant with multiple engagements, the operator wearing multiple hats — running the personal connective layer alongside whatever team tools each project uses. Pricing tiers are on the pricing page.
A small first test
Pick the two projects you context-switch between most. Drop the last week of notes from each — meeting recaps, open followups, decisions you've logged — into separate top-level pages in Capy. Ask the agent to draft a unified weekly review across both. If the review surfaces a pattern you'd otherwise have missed by treating them as separate streams, that's the agent doing the connective work that justifies the consolidation.
Try Docapybara free. Load two projects' last week and see what falls out across both.