The honest job description of a freelance consultant has two parts. There's the work the client thinks they're paying for — the strategy, the audit, the deck, the coaching call. And there's the work that actually fills your week — keeping six engagements straight, remembering what you promised whom on which call, finding last quarter's proposal so the new one mirrors it, drafting the Friday status note from a tangle of Slack and email and your own scribbles.

Most of the second part is administrative drag, and most of it is a search problem. The fix isn't a new project management tool. It's a vault where every artifact for every client lives in one place, and an agent that can read the whole thing on demand.

## The shape of a consulting practice that holds

Consulting work fails at the seams between things. Between the discovery call and the brief. Between the brief and the kickoff. Between the call you took on Tuesday and the deliverable you're supposed to send Friday. Each seam is a place where context can drop, and most of them drop because the relevant material is in a different app.

The shape that holds, across years of running a roster of clients:

- **One top-level page per client**, with sub-pages underneath for everything that pertains to them — discovery, contract, calls, deliverables, invoices, follow-ups.
- **A practice library** — your templates, frameworks, past proposals, standard contract clauses, and the playbook you keep evolving.
- **A few small tracker databases** — active engagements, invoices, promises you've made — embedded inline in pages you actually visit.
- **An agent that reads across all of it** so the daily questions ("did I commit to that?", "what's overdue?", "what did the client say about timing?") get answered from the record, not from memory.

This pairs naturally with [AI notes for client work](/guides/creatives-content/ai-notes-for-client-work/) if you want the broader version of the same setup. The current guide focuses on what's specific to the consultant — the practice library, the proposal flow, the long arc of an engagement.

## One client per page, nested as deep as the work needs

The structure that scales is dead simple. Each client gets a top-level page. Underneath, sub-pages for every kind of artifact. Page nesting has no depth cap, so a long-running engagement can grow as deep as it needs.

A typical client branch:

- **Acme Corp**
  - Discovery and brief
  - Signed contract (PDF)
  - Calls
    - 2026-02-14 kickoff
    - 2026-03-01 phase one review
  - Deliverables
    - Phase 1 audit
    - Phase 2 strategy memo
  - Pipeline (database)
  - Invoices and payments
  - Internal notes (your private observations about the relationship)

The benefit isn't visual neatness — it's that the agent can scope its work to one client by reading from one branch. "Read everything under Acme. Draft a status update for tomorrow's call covering progress, open questions, and what I need from them." The agent doesn't have to guess what's relevant; the structure tells it.

Plain markdown matters here. The pages aren't database rows with attachments hanging off — they're text files the agent can read end-to-end. That's why "summarize where this engagement stands" actually works as a prompt.

## Discovery and the first proposal

The intake on any new client is famously chaotic. A discovery call. Three follow-up emails. A shared folder of "everything we have." Someone sends a Loom that's twenty minutes long. By the time you sit down to write the proposal, you've reviewed all of it twice, taken notes in three places, and probably forgotten one important constraint.

The agent helps with the synthesis pass. Drop the discovery call recording — it transcribes with speaker labels so you know which stakeholder said what. Save the email thread as a page. Drop in any PDFs the client sent — they auto-convert to markdown via docstrange, so attachments become searchable text instead of opaque files.

Then ask: "Pull the five things the client said are non-negotiable. Pull the constraints they mentioned around budget, timeline, or team capacity. List the three areas where they contradicted themselves between the call and the email thread. Draft a proposal that mirrors the structure of my last three accepted proposals in the practice library."

You get a proposal draft that's grounded in what they actually said and the shape of what's worked before. You spend half an hour editing instead of three hours assembling. The client gets a proposal that quotes them back to themselves, which tends to land better than one written from scratch.

## The practice library — your accumulated playbook

The thing that distinguishes a five-year consultant from a five-month one is the playbook. The frameworks you reach for. The diagnostic questions that get to the truth fast. The proposal structure that closes. The phrases you've decided don't work with senior buyers. Most consultants carry that playbook in their head and slowly forget the parts they don't use weekly.

A "Practice library" section in the vault makes it explicit. Pages for templates — discovery brief, proposal, kickoff agenda, status note, end-of-engagement memo. Pages for frameworks — the diagnostics you actually run, organized by what they're for. A "phrases" page for openers and closers that have worked. A "lessons learned" log where you write down what you'd do differently next time after each engagement wraps.

When you ask the agent to draft a proposal or a status note, it reads the relevant template page first. The output respects your specific approach, not a generic one. As the playbook evolves, you update the page. The next draft reflects the new thinking. The drafting flow itself is covered in more depth in [drafting emails, proposals, and newsletters inside your notes app](/guides/creatives-content/draft-emails-proposals-in-notes/).

For the templates you reach for less often — the QBR deck outline, the workshop facilitation guide, the contract amendment language — they're a search away. You don't have to remember which Drive folder you put them in three years ago.

## Calls and the speaker-label dividend

The single biggest improvement to consulting work with many meetings is letting something else handle verbatim capture.

The pattern: you record the call (with the client's knowledge), drop the audio onto the relevant call page in the client's branch, and the transcription runs with speaker labels. You're free during the call to actually be present — listening, asking the second-order question, watching for what's not being said. Afterward, you skim the transcript instead of straining to remember.

The transcript is searchable, which matters more than people expect. Three months later when the client asks "what did we say about the rollout?", you ask the agent: "Find every time we discussed the rollout across calls with this client. Pull the relevant exchanges with who said what." You get the moments back, with speaker labels, in plain text. No more "I think we said early Q3?"

For consulting specifically, the speaker labels do more work than they do in most contexts. You want to know what the CEO committed to versus what the operations manager committed to versus what you committed to. A wall of dialogue without attribution is just dialogue.

## Cross-client trackers and the version question

Consulting deliverables go through revisions. The first draft. The version after their notes. The version after your second pass. Most consultants manage this in a folder of files with increasingly desperate naming conventions.

In a markdown vault, every revision is its own page under a "Deliverables" sub-page, with the date in the title. The agent can compare them on demand: "Show me what changed between Draft 2 and Draft 3 of the strategy memo, in plain English." That question is hard to answer fast in a folder of Word files.

For deliverables with structured information — recommendation matrices, prioritized backlogs, audit findings — an inline database via the `:::database:::` directive works better than a static table. Across many clients, you also need a few small databases the agent can read alongside everything else. A project tracker with rows per active engagement: client, current phase, next deliverable, due date, status, hours logged this month. An invoices database. A "promises" database for things you've committed to that aren't formal deliverables. The agent can answer "what's overdue across all my active projects?" in one query. See [pricing](/pricing/) for storage and upload limits if your vault holds a lot of large recordings.

## A calmer way to run the practice

Once a week, scan the running databases. Anything finished gets marked done. Anything that slipped gets a new date. To shorten the review, ask the agent: "What did I commit to this week across all clients? What's overdue? What invoices are unpaid past 30 days?" You get a focused short list in seconds. Ten minutes — not the hour-long reckoning Friday tends to become.

A useful boundary, learned the hard way: don't let email be the system of record. Email is transport, not storage. When something important lands, paste the relevant chunk into the right client's page with a date. Now it's findable, quotable, and indexed by the same agent that reads everything else. The same commitment-capture pattern is the spine of [how to capture action items so they actually get done](/guides/meetings-people/action-items-actually-get-done/).


A consulting practice doesn't have to feel like spinning plates. The plates are real, but most of what makes them feel precarious is the search-and-reassembly cost between them. Put everything for each client in one nested branch. Keep your playbook explicit in a practice library. Let the agent handle the boring searches and the structural drafts.

Try Docapybara free — [sign up](/accounts/signup/), pick one active client, drop in their brief, the contract, and your last two call recordings, then ask the agent for a one-page status summary you could send tomorrow. See whether the shape fits the way you actually work.