An architectural practice runs on documents that don't talk to each other. The drawings are in CAD. The specs are in PDF. The client emails are in your inbox. The site-meeting notes are in a notebook or somebody's phone. The decision log — if it exists — is in a Google Doc nobody's opened in three months. When the contractor calls and asks why the spec calls for one type of glazing in the south elevation and another in the east, the answer lives across four of those silos and you have to assemble it on the fly.
AI notes won't replace your CAD or your specs. What they can do is hold the connective tissue — meeting notes, decision logs, client correspondence, design rationale, code research — in one place where the agent can read across all of it. That's the part of the practice that's actually constant context-switching and high-cost recall. Adjacent project-led professions like construction project managers and event planners juggling vendors and timelines hit the same shape — the structured tools handle one slice, the vault holds the rest.
A project vault that mirrors how a project actually moves
The shape that holds up across project size is roughly: one top-level page per project, with sub-pages for client brief, schedule of accommodation, design-decision log, meeting recaps, code research, and consultant correspondence. Capy supports unlimited page nesting, so larger projects can fan out into per-phase pages, per-elevation pages, per-consultant pages — without you having to commit to a depth in advance.
The whole vault is plain markdown notes. That matters because the agent can read across every page in one query. When the contractor calls about the glazing question, you ask: pull the design rationale entries that touch on glazing, the manufacturer correspondence on the south elevation, and the relevant code research, and tell me what I decided and why. The agent reads the vault and writes the answer in the time it takes to make coffee.
Site meetings that don't disappear
Site meetings produce the most valuable and most-lost information in the practice. The structural engineer mentions a beam-depth concern that affects ceiling heights two rooms away. The client looks at the model and asks for an opening that wasn't on the drawings. Three subcontractors agree verbally on a sequencing change. By Friday, half of those decisions exist only in somebody's memory. (The same recording-with-speaker-labels habit underwrites board-of-directors meeting notes — different room, same loss pattern.)
Record the meeting in Capy. The transcript comes back with speaker diarization — labels like "Speaker 1: …" so you can tell who said what, not just a wall of unattributed text. Park the recording on the project's meeting-recaps page. Ask the agent: pull the action items, list every decision that affects the drawings, flag anything the consultants said that contradicts something in the existing decision log. You get a recap that's actually useful for the team and a structured list of follow-ups that can be promoted into your action database.
The next time somebody asks "wait, when did we decide to lower the ceiling in zone three," you can search the vault and find the moment in the transcript where it was said, with the speaker labeled.
PDFs the consultants send, finally readable
A typical project drowns in PDFs from consultants. Structural reports, MEP narratives, geotechnical investigations, manufacturer cut-sheets, building-code amendments. Most of those PDFs are skimmed once and then sit in a folder.
Drop the PDF on a Capy page. It auto-converts to markdown via docstrange, which means the agent can read the whole document — not just keywords — and treat it as searchable text the same as any other note. Ask the agent to summarize a sixty-page geotechnical report in plain English with the recommendations called out separately. Or to find every reference in a manufacturer cut-sheet to the assembly type you're specifying. The conversion runs once per upload and the document stays searchable from then on.
This is what makes "chat with the spec PDF" actually work, instead of being a parlor trick. The agent isn't running OCR on every query; it's reading text it already has.
A decision log the agent helps you keep
Design decisions get made in conversation and lost in conversation. The reason the entry sequence rotated ninety degrees from the schematic phase. The reason the fenestration rhythm shifted on the east elevation. The reason the cladding spec changed in DD. Six months later, someone — the client, the contractor, your future self — will ask why, and the answer is in nobody's head.
A decision log is the cheap fix, but only if it actually gets kept. The friction of opening a separate doc and writing a paragraph is enough to make most architects skip it.
A working setup: have an inline database called "design decisions" inside your project page, with rows for date, area affected, decision, rationale, and what triggered it. The database lives directly in the page via the :::database::: directive — you don't switch to a separate tab. After a meeting or a working session, ask the agent to read the recap and propose entries for the log. You confirm or edit; the agent writes them in. The log gets kept because the cost of keeping it is now closer to zero. The same decisions-log mechanic shows up in our writeup of contract negotiation with AI notes — different artifact, same compounding habit.
Code research that doesn't restart from zero
Building code research is the kind of work that compounds badly across projects. You looked up the egress-stair requirements for a similar building type two years ago and you'll look them up again next month, because the answer lives in a folder you've forgotten the name of.
Tell the agent: search across all my project vaults for any decision-log entries or research notes that touch on egress stairs in mid-rise residential, and summarize the patterns. The agent finds the prior research and you build on it instead of starting blank. If the relevant code section has updated, you check the current version against your old notes — and the agent's web_search tool can pull the current published code text into the same page with a source URL, so you're not toggling between a browser and your notes to compare.
This isn't a substitute for actual code review or for a code consultant. It's a way to stop losing your own past research between projects.
Drafting the next client deliverable from your past ones
A lot of client-facing deliverables are structurally similar to deliverables you've already produced. The schematic-design narrative, the materials-and-finishes brief, the bid-package overview. Each one is bespoke in its content and almost identical in its shape.
Drop the client brief on a fresh page. Tell Capy: read my last three SD narratives in this building type, identify the structure they share, draft a v1 narrative for this project using that structure, pull the language about sustainability tradeoffs from the one the client praised most. You get a draft that sounds like your narratives. You spend the saved time on the parts that genuinely are new — this client's specific brief and the parts of the design that don't have a precedent in your past work.
What this isn't
Capy doesn't replace CAD, it doesn't generate drawings, and it doesn't model. The structured-data side of an architectural practice still lives in the tools that handle structured data. Capy is for the unstructured side — the writing, the meeting notes, the rationale, the correspondence, the research — which is the part that's currently sprawled across email and Drive and a notebook.
It's also single-user by design. One architect, one vault. If your practice needs a multi-user team workspace where every project member shares files with role-based permissions, that isn't this product. The shape that fits the principal or sole practitioner is a personal vault that holds the connective tissue and lets you draft fast from it.
A small first test
The cheap way to see whether this fits your practice is to take one active project, load the client brief, the last two meeting recaps, and a consultant report, and ask Capy to write a one-page status summary. If the summary catches a tension between two of those documents that you hadn't surfaced explicitly yet, you've got a sense of what the agent is doing for you across the rest of the project — and across the rest of your book.
Try Docapybara free. Load one project's last month of notes and see what the agent does with them.