A system,
not another
tool.
Diana runs a four-person boutique real estate team in Austin. Sixty to eighty transactions a year. Everything lives in her head and three Google Docs. She doesn't want software. She wants a system her newest hire can pick up in a day.
Diana's test was simple. Operational in a day.
When a lead comes in, who responds first depends on who saw the notification. When property research goes out, the agent doing it rebuilds the wheel every time. When a deal moves into contract, the newest agent slacks Diana at 11pm asking which document needs to go where.
Diana has tried AI tools. Either too generic to be useful or too complicated to teach. She doesn't want another platform. She wants an architecture — a way her team works that doesn't depend on remembering which Google Doc holds the truth.
Five specialists. One shared substrate.
Every active lead, tour, deal, and post-close conversation lives in its own folder under _cases/. Two files per case: a card (canonical facts) and a log (append-only timeline). The five specialists read from and write to the case folder. The folder is the handoff.
The case folder is the handoff.
Other systems pass typed JSON envelopes between specialists. Others pass ephemeral markdown briefings on Slack. Diana's problem isn't message-passing. It's that state lives in her head and three Google Docs.
So the substrate is the answer. Every active lead, tour, and deal lives in its own folder. The folder has two files: a card (the facts) and a log (the timeline). Specialists read the folder, do their work, and write to the folder. There is no "handoff packet." There is no envelope. There is only the case.
This means: if Marcus is at a closing and a question comes in, Sara can open the case folder and answer it. If Diana wakes up at 6am wondering about the Hendersons, she opens _cases/active/2026-04-22_henderson_seller/ and she's caught up in 90 seconds.
The folder is the system of record. Always.
How a referral becomes a closed deal.
The Smiths come in as a Tuesday referral. Eleven days later they're under contract on a Springdale Road bungalow. Here's the flow.
Monday, 9am. The new hire opens her laptop.
Diana's test is the bar. A new agent should be operational in a day. Here's exactly what she reads, in order, with timestamps.
Read the root README.md
What the system is, who the team is, the one rule (status before action), and the map of where everything lives. Don't try to memorize. Just notice the shape.
Read _diana/about-diana.md and _diana/voice-profiles.md
This is who you're working for and how the team sounds. Diana, Sara, Marcus, Jamie — each agent has their own voice. The comms specialist will draft in your voice eventually, but it starts with Diana reviewing every Jamie draft.
Read _diana/decision-playbook.md front-to-back
Diana's eight years of judgment, written down. War stories, the "Pick Three" rule on inspection responses, when to walk a deal, how she thinks about a stressed seller. This is the quality ceiling. Come back to it constantly.
Read one closed case end-to-end
Open _cases/closed/2026-04-02_johnson_seller/. Read the card, then read every entry in the log in order. This is one whole deal — first contact through close — in two files. By the end you'll understand the rhythm.
Read each specialist's identity.md and handoff.md
Five folders. For each one, two files. You're not memorizing — you're learning what each specialist owns and what it produces. Pay closest attention to the handoff files. The specialists' bounce-back patterns are the whole game.
Lunch.
Don't read anything. Let it land.
Shadow a live case
Open _cases/active/, pick the case with the most recent log activity, read everything. Watch how the orchestrator routed. Watch what the comms specialist drafted vs. what the agent sent. Watch what the TC flagged.
Run a practice request through the orchestrator
Take a real (or hypothetical) inbound message. Send it to the orchestrator. Watch it route. Watch the qualifier write the card. Read what it produced. Compare to what Diana would have done. Note the gaps.
Read examples.md for each specialist
Two or three scenarios per specialist, showing the file in action with real text. By now you've seen the shape — these are the textbook plays.
Sit with Diana for 30 minutes
Bring three questions. Diana will answer them, and her answers will go into the playbook so the next person doesn't have to ask.
You're operational.
You won't be senior. You'll still need to learn the local market, the lender contacts, the title-company quirks. But by 5pm Monday, when a lead comes in, you know what to do with it. That was Diana's test. The system is the answer.
Five decisions, written down. So the next builder can disagree.
The case folder is the substrate, not the message.
Other systems pass JSON envelopes or ephemeral briefings. This one writes to disk. Persistent state means any human or any new Claude session can pick a case up cold and be useful in two minutes. It is the answer to "everything lives in my head and three Google Docs." This is the central decision; every other decision follows from it.
_diana/ loaded by every specialist, every run.
About-Diana, voice profiles, decision playbook. These three files are the quality ceiling. Generic input produces generic output. Diana's willingness to write down her actual thinking — including the war stories and the "Pick Three" rule and what makes her walk a deal — is what makes the system sound like her team, not like an LLM.
Bounce-back is first-class, not an exception.
Real deals don't move forward in a clean line. The comms specialist gets a reply and needs the TC to check feasibility. The TC finds an easement and needs research to investigate. Every handoff.md documents return paths, not just forward paths. Diana's team works in reality, not in a flowchart.
Voice profiles for every human, not just the principal.
Marcus, Sara, and Jamie each get their own voice profile. Jamie (six months in) gets her own — she's allowed to sound like herself, not like Diana. Until her voice profile is mature, comms drafts for Jamie always route through Diana for review. The system grows up with her.
The orchestrator asks one question first: does a case exist?
The single rule that keeps the system coherent across a forty-deal-in-flight Tuesday afternoon. If a case exists, the work happens inside that folder. If not, the qualifier opens one. There is no scenario where work happens "around" the case folder. State is the source of truth, always.
Five folders.
One case substrate.
One repo.
Drop the repo into Claude Code (or any agent runtime that reads the filesystem) and the system is operational. Setup is two steps: clone the repo, point Claude at the root. The folder structure is the system.
The repo includes a working example case (smith_buyer, mid-flow) and a complete closed case (johnson_seller, full lifecycle) so a new hire's "read one closed case end-to-end" step on their first day has something real to read.