You're standing on the second floor of a half-framed house in the rain. The drywall sub is asking when the rough-in inspection cleared. The electrician is asking why nobody told him the breaker panel moved. Your foreman wants to know if the homeowner agreed to the change order on the kitchen island. You think the inspection passed Wednesday. You think the breaker panel discussion happened on a Tuesday call. You think the homeowner said yes by text. You're on three sites today and your notes from the last week are split across a notebook in the truck, the project management app on your phone, two text threads, and your head.
Most construction PMs don't have a project-management problem. They have a working-memory problem. Schedules and budgets are fine — those live in the PM software and get attention. What lives nowhere is the conversational and decision context that drives the actual work — the side calls, the texts, the offhand commitments, the punch-list items somebody mentioned and nobody wrote down.
This post is about putting that working memory in one place so it's actually findable when you're standing in the rain on Tuesday morning.
What construction PMs need from a notes system
Before getting into the mechanics, the workflow shape matters. A working PM needs notes that do five things:
- Per-site continuity — what happened last visit, what's owed, what's blocked, what to check tomorrow
- Per-sub coordination — running threads with each trade about scheduling, scope, RFIs, payments
- Decision context — what the homeowner agreed to, when, and the conversation around it
- Change-order trails — what changed, why, when, signed off by whom, cost impact
- Operational memory — supplier accounts, equipment service, the running warranty list, the new-PM onboarding packet
Plus it has to work in the field — meaning you can open a phone, find the site, add a note, and get back to walking the job without fighting the software. Adjacent operational shapes are in Run a Daily Standup From Your Notes App and AI Notes for Customer Onboarding Documentation.
A page per site, a page per sub, organized by job
In Docapybara, every active site gets a markdown page. Every active subcontractor gets one too. The structure that works for most PMs:
Jobs → Active → Williams Residence with sub-pages for Daily Log, Change Orders, Inspections, Punch List, PhotosJobs → Subcontractors → Diaz Electric with the running thread of work, payments, and coordination across all sitesJobs → Suppliers with one page per supplier (account, terms, contact, reliability notes)Jobs → Operations for the cross-job operational stuff (the truck inventory, the safety meeting log, the new-PM onboarding)
Page nesting goes as deep as you want. Plain markdown means the pages are searchable, copyable, and exportable. When the homeowner asks for a copy of the daily log, you copy out the page as text. When you switch to a different PM software next year, your years of working notes come with you as text files.
A live database of change orders that doesn't get out of sync
A :::database::: directive embeds a live database directly inside any markdown page. The most useful place to put one in construction PM work: the change-order page for an active job, with columns for CO number, description, requested by, status (Proposed, Approved, Rejected, In Progress, Complete), cost impact, schedule impact, signed-off date, notes.
Six column types are available, which covers what you'd want for change tracking. The table sits next to the written context of the job — the running log of what happened on site that triggered each change.
When you tell the assistant "add a change order for the kitchen island upgrade, mark it as proposed, $4,200 cost, two-day schedule impact, and put a note that the homeowner verbally agreed by text Tuesday morning", it adds the row. When you ask "which change orders on the Williams job are still waiting for signed approval?", it reads the database and tells you.
For a PM running five active jobs, a master change-order page can roll up across all sites — the assistant aggregates the per-job databases on request. "Show me every change order across all my active jobs that's been proposed but not approved in the last two weeks" — one query, complete answer.
The agent reads across every site and every sub
Capy, the assistant inside Docapybara, has 27 tools and reads across your entire vault when you ask. The kinds of questions that become answerable in seconds:
- "What did the framer commit to on the Williams job at last week's site meeting?" The agent finds the daily log entry, locates the relevant note, and quotes it back.
- "Pull every site where the rough-in inspection has been scheduled but not yet passed." It scans the job pages, returns a list with the relevant inspection notes.
- "Have I had any RFIs with Diaz Electric on similar panel reroutes in the last year? Pull what worked." Cross-job, cross-sub retrieval, in one query.
- "On the Henderson job, what was the original spec for the master bath tile and how does it compare to what the homeowner is now asking for?" It reads the original scope page and the recent change request page side by side.
This isn't AI making construction decisions. It's retrieval — getting the working memory of a busy PM workload back in front of you in seconds instead of fifteen minutes of digging through three apps. The agent-acts-on-docs differentiator is described in Claude Code for Documents.
Recording the homeowner walkthrough so commitments don't drift
The most legally important detail in a construction job is often the conversation, not the line items. The homeowner says they're fine with the substitution. They mention they want the lighting to look "warm but not yellow." They agree to a schedule extension. Six weeks later, none of that is documented unless someone wrote it down at the time.
Docapybara records audio inside the workspace and transcribes with speaker labels — so when you walk the site with the homeowner, the conversation is captured with who said what. For pre-construction walkthroughs, mid-job change discussions, and any contested punch-list conversation, having the audio + transcript on the job page is a different level of context than what fits in a daily log entry.
The transcript drops onto the job page. When the homeowner asks four months later why a change was made, you can find the moment in the transcript where they asked for it.
PDFs of plans, specs, contracts — and trackers for inspections and punch lists
Most construction jobs come with a stack of PDFs — architectural plans, the spec book, the signed contract, vendor cut sheets, the soils report, the permit set. They're useful when findable and frustrating when you're trying to grep them on your phone in the rain. Drop the PDFs into Docapybara and the conversion pipeline turns each one into searchable markdown. The agent can now read across them. So when you ask "what does the spec book say about the exterior paint system on the Williams job?", the agent pulls the relevant section as text. When you ask "what does the contract say about change-order approval procedures?", it finds the clause. The original PDF stays one click away when you need to actually look at the plan.
For active sites, two more inline databases pay for themselves quickly. An inspection log with columns for date, type (rough framing, electrical rough, plumbing rough, final), inspector, status (passed, failed, conditional), notes, and next-step. Sort by date for the inspection timeline; filter by status for what's outstanding. A punch list with columns for area (kitchen, master bath, exterior), item, sub responsible, status (open, in progress, complete), priority, and notes. Sort by area for the punch walk; filter by sub for the trade-coordination call. When you tell the assistant "add three punch items to the Williams job — touch-up paint in the master bedroom, replace the cracked switch plate in the kitchen, and reseat the hardwood transition at the dining room threshold", it adds the rows. When the painter asks at end of week "what punch items are still open for me?", the answer is one query away.
Operational notes — supplier accounts, equipment, training
A PM runs more than active jobs. Supplier accounts, truck inventory, equipment service intervals, the safety meeting log, the new-PM onboarding packet — all of that lives somewhere, and in most companies it's a folder of Word docs nobody updates.
In Docapybara, those operational notes are nested markdown pages. A common layout:
Operations → Suppliers with one page per supplier (account, terms, contact, return policy notes, reliability log)Operations → Equipment → Truck Inventory Log (database tracking what's in each truck, last inventoried, missing items)Operations → Safety → Weekly Safety Meeting Log (database tracking topic, attendees, date, notes)Operations → Hiring → New PM Onboarding (the written process, plus pages for each new PM)Operations → Warranty → active warranty work tracker (database)
When you onboard a new PM or assistant, you point them at one nested folder and they have everything — written process, live trackers, the conventions the company uses for site notes. When you ask the assistant "what's outstanding with our concrete supplier from last week's quality issue?", it finds the relevant note. The SOP layer specifically is covered in Standard Operating Procedures, Without the Wiki Maintenance Tax.
Try Docapybara free
The fastest test: open Docapybara, create a page for tomorrow morning's first three site visits, paste in whatever working notes you've got on each (the change orders, the open inspections, the running text thread with the homeowner), and ask the assistant for a one-paragraph briefing for each visit. Five minutes of setup, and you'll know whether having the working memory next to you instead of split across four apps changes the morning.
Try Docapybara free — bring your messiest active-job notes, last week's homeowner texts, and one site where the change-order trail has gotten out of hand. See how the workspace handles them.