You probably have a stack for work and a stack for life that don't talk to each other. The work side might be Linear or Jira plus a shared doc, plus the standup notes that live in someone's Slack DM. The life side is some combination of Apple Notes, a sticky on the fridge, the half-list in your phone, and the texts you send yourself. Two systems, two places to forget things, two memories of what you were going to do this week.

The pitch most productivity tools make is that you should formalize one of those sides — usually the life side, into the same project-management tool you use at work. That doesn't really work, because grocery lists aren't sprints and dinner plans aren't tickets. The other pitch is that you should keep them separate forever, which is what most people do, accepting the tax of two memories.

There's a third option: one vault that holds both, structured the way each actually wants to be structured, with an agent that searches across them. That's what we built Docapybara to be. Here's how it actually plays out.

## Sprint planning shaped like a sprint, grocery shaped like a list

The reason most "one app for everything" approaches fail is that they force one shape on both worlds. Trello-shaped grocery lists are silly. Notes-app-shaped sprints lose track of what's done.

In Docapybara, each thing keeps its native shape. Sprint planning lives on a *Sprints* page tree — one parent page, one child per sprint, structured the way your team actually plans. Grocery lives on a *Grocery* page or as items in an inline database via the `:::database:::` directive. The vault doesn't insist on one structure. The agent searches across whatever structure each piece wants.

If you're already running standups out of your notes, [Run a Daily Standup From Your Notes App](/guides/field-service-ops/daily-standup-from-notes/) extends this — the same vault that holds the grocery list can run the team's day-of.

## What changes when both live in the same vault

Three things change, none of them flashy, all of them useful day to day.

**Capture stops being situational.** Right now, when an idea comes up at 7 a.m. while you're making coffee — *"oh I need to follow up with [colleague] about the design review"* — you face the choice of opening Slack, Linear, your work-Notes app, or just hoping you remember it later. With one vault, the answer is always the same: drop it on whatever page is open, or in the *Inbox* page. The agent can move it to the right place later.

**The agent searches across both.** This is the move that's invisible until you've used it. *"What did I commit to for this sprint, and what's left to wrap up before Friday?"* — answered. *"What's on the grocery list and what's on the side-project list for Saturday?"* — answered. Same agent, same query syntax, no app-switching. (The fuller version of this case is at [Why Your Notes App Should Be the Same App for Work and Life](/guides/personal-life/same-app-work-and-life/) — the *same-app* argument made at length.)

**The mental tax drops.** You stop mentally tracking which app each kind of thought goes in. There's one place. Open it, drop the thing, close it.

## The work side — the sprint, the standup, and the carry-over

The work side of the vault is fairly conventional. A *Work* parent page, with child pages for *Sprints* (one per sprint), *Projects*, *Standups* (dated), *Decisions*, and *People*. The structure mostly mirrors how your team thinks about work.

The sprint child page holds the goals, the commits, the daily updates, the blockers, the carry-over to next sprint. Voice works for the daily standup — tap record, talk for thirty seconds about *yesterday / today / blockers*. Audio recording in-app gives you a transcript with speaker labels (useful when there's a co-worker on the call). The transcript lands on the standup page; the agent can summarize across the week: *"What did I commit to on Monday and Tuesday, and what's slipping?"*

For decisions you make during sprints (which approach to take, which tool to evaluate, which trade-off to accept), an *Architecture decisions* sub-page captures them. The shape's the same as in [Architecture Decision Records, Kept Where Your Agent Can Read Them](/guides/developers-builders/architecture-decision-records-ai-notes/) — same vault, same agent, but lighter for non-engineering work.

## The life side — the grocery list, the meal plan, the weekend

The life side is messier because life is messier. A *Life* parent page (or just spread out across category pages) holds the practical stuff. *Grocery* (inline database with item, store, status, notes). *Meals* (this week's plan, what we have, what we need). *Errands* (running list with status). *Household* (the slow-running stuff — the leak in the bathroom, the appliance that's making a noise, the overdue oil change).

The agent handles the cross-cutting questions: *"What do I need from Trader Joe's tomorrow, and is there anything for the household projects I should pick up while I'm out?"* Comes back with the consolidated list.

For meal planning specifically, the *Meals* page can pull from your *Recipes* page (the [Documenting Recipes and Cooking Experiments Without Losing the Plot](/guides/personal-life/document-recipes-cooking-experiments/) shape applies cleanly) and generate the shopping list: *"For the meals I planned for this week, what do I need to buy that we don't already have?"*

## What the agent does when both sides are in one place

The agent (Capy) is the move that makes the *one app* idea actually work. It has 27 tools and reads across the whole vault. So queries like:

- *"What do I have on my plate today between work and life?"*
- *"What's the plan for Saturday — any work follow-up I owe, what's the meal plan, who's coming over?"*
- *"Generate a daily plan for tomorrow that includes the sprint commits, the errands, and the dinner I said I'd cook."*

…work without switching apps. The agent doesn't care that the sprint commits live in a *Sprints* child page and the meal plan lives in a *Meals* child page. It searches both.

The same agent can act on the documents — adding rows, drafting messages, updating the grocery list — not just answer questions about them. *"Add the grout sealer to the hardware-store list, and remind me of the plumber's number when I'm next searching for that."* Both happen.

## What you give up by using one app

Honest about the trade-offs. You give up some specialization. The work side won't have the team-specific ticket workflow your engineering team has in Linear. The life side won't have the prettier-looking habit-tracker views of dedicated habit apps. Docapybara is single-user by design — if your team needs to share boards, you're using your team's tool for that part of work and the vault for your private thinking. (For the broader honest comparison to other tools, [Looking for a Notion alternative? Here's when Docapybara fits — and when it doesn't](/blog/vs-notion/) covers when the trade-off makes sense and when it doesn't.)

What you gain is the friction reduction. One app to open. One agent to ask. One memory of where you wrote things down. For most of what most people do, that trade is worth it.

## When sprint thinking helps the life side, and vice versa

The unexpected payoff is the cross-pollination. The discipline of sprint planning at work — what's the goal, what are the commits, what's the carry-over — applies surprisingly well to life. The looseness of how you keep a grocery list at home — open page, drop item, no ceremony — is also how the most senior engineers actually work, regardless of what their tools force them into.

A *Personal sprint* page that holds the two or three things you're trying to make progress on this week — the home repair, the side project, the conversation you've been postponing — gives the life side some of the focus the work side has. The agent can summarize: *"What was on my personal sprint this week, and what got done?"*

And a looser *Project capture* page on the work side gives you somewhere to drop the half-formed thoughts that don't yet belong in a ticket. The agent can promote them later: *"Look at the project-capture page from this week — which items are ready to become real tickets, and which are still half-thoughts?"*

## A starter shape

One honest constraint up front: Docapybara is single-user by design. The vault is yours; nobody else is in it. That means the *team* side of work happens in your team's tool (Linear, Jira, Slack, Notion). The vault holds *your* working memory of work — your sprint commits, your standup notes, your decisions, your action items — alongside the rest of your life. For most knowledge workers, that turns out to be the right split. The team has its own brain; you have your own. The vault is the one that follows you across jobs, projects, and the rest of your life. (For the team-side question specifically, [AI for Knowledge Workers Who Aren't Developers](/blog/ai-for-knowledge-workers/) covers what we built the vault to handle and what stays in team tools.)

If you're moving from two systems to one, this is what we'd suggest:

- **Work** — sprints, projects, standups, decisions, people
- **Life** — grocery, meals, errands, household
- **Inbox** — daily voice and text capture, sort weekly
- **Personal sprint** — the two or three life things you're working on this week

That's it. Don't try to import everything at once. Start with this week's sprint and this week's grocery list. The vault grows the way your week grows. The agent handles the searching, drafting, and updating across both halves.

The point isn't to formalize life. It's to stop maintaining two memories. One vault, one agent, both halves of the day.

[Try Docapybara free](/accounts/signup/) — drop this Friday's grocery list and Monday's standup on the same vault, and see how the friction shifts.