The ask
Every sponsor shop carries a private archive of buyer-side LOIs. Mine runs about a decade deep. Each deal is a folder with a few versions of an LOI - sometimes a clean executed copy, sometimes a redline history that took weeks to converge. The knowledge in those folders is real: which terms we asked for and gave on, which ones we held, what shape of language closed the deal. But it sits inside file names and tracked-changes panes, not in a usable template.
The starting prompt to my workstation agent was a paragraph: crawl all active and archived deals, find the buyer-side LOIs with multiple rounds of redlines, distill the institutional knowledge into the ultimate template. Scope was vague on purpose. The real question was how do we make this productive without me reading a hundred deal folders by hand.
What follows is the architecture that fell out of that ask - four phases, twenty-one subagent invocations, three deliverables. The pattern is reusable; the specific deals are not. I’m writing it down because every step where the pipeline almost broke is the part another operator will hit too.
Step one - refuse to start
Before any tool touched a deal folder, I invoked the grill-me skill. It interviews you one question at a time, each with a recommended answer attached. We resolved eight branches of the design tree before a single file was opened:
- Template scope. Buyer-side, all real estate types, not just land.
- Deliverable shape. Annotated template plus playbook plus comparison matrix, not just a template.
- Qualification rule. A deal qualifies with at least two dated LOI versions, or an executed LOI plus a prior draft.
- Scrubbing rule. The clean template gets scrubbed of identifying detail; the playbook keeps deal names so the case references stay useful.
- Swarm topology. A multi-phase pipeline with explicit user-approval gates between phases.
- Term taxonomy. Fully emergent from the deals, not preset.
- Email scope. Folder artifacts only. No mailbox crawling.
- Output folder, filenames, and naming conventions.
The grill turned a fuzzy ask into a buildable spec in about five minutes. Without it the scope would have ballooned inside Phase 1 - emails, advisory deals, sell-side LOIs, every adjacent file that looks like it belongs but doesn’t. It is the cheapest move in the whole pipeline.
Phase 1 - the scout swarm
Four parallel subagents, split alphabetically across the archive:
Scout A: Active deals + archived A-B (30 folders)
Scout B: Archived C-M (47 folders)
Scout C: Archived N-S (20 folders)
Scout D: Archived T-Z + numeric prefix (14 folders)Each scout did filename-only discovery - no document reads - and wrote a JSON shortlist to a shared Evidence/_scout-reports/ folder. The constraint was the point: identify, do not analyze. That kept each scout’s context small and their reports comparable.
Result: 111 folders swept, deduplicated and pruned to 21 qualifying deals across three tiers. The approval gate fired here, and presenting the shortlist surfaced something the scouts alone couldn’t - small-sample categories. Only one municipal-seller deal. Only one improved-property deal. The rest were land deals with private sellers. Catching that ratio before extraction ran meant the playbook didn’t overstate a pattern with one data point under it. We picked Tier 1 plus Tier 2 - 16 deals - for extraction.
One scout-level lesson worth keeping: my alphabetical split quietly overlapped on numeric-prefix folders, the kind that start with a year like 2023 - Something, and two scouts independently flagged the same one. Harmless here. But when you partition a swarm by sort order, check the edges.
Phase 2a - one extractor, not fifteen
The most important decision in the pipeline was a refusal: do not fan out fifteen extractors at once. Run one first, on the deal you understand best, and validate the output schema before anything else moves.
The pilot ingested six LOI versions of one canonical deal plus the predecessor template earlier LOIs had cloned from. It produced a 234-line JSON file with three layers: per-version term extraction on a taxonomy that emerged from the documents themselves; a cross-version negotiation arc - which terms we held, which we conceded, which the seller added, which got added late, which got dropped; and observations the model surfaced unprompted.
The pilot confirmed its own depth by naming things I half-knew but never had. Across that one deal the price went up 13.6% over the negotiation, earnest money grew tenfold, and the no-shop clause we asked for got struck entirely. It also caught a county-and-state header from a different state that had ridden through three versions of the LOI before anyone noticed - a template-artifact bug that betrayed how the document was being copied forward. Nobody would have grepped for that, because nobody knew to look. The agent found it by reading end to end, and it became its own section in the final playbook.
The pilot JSON then became the spec for every extractor after it. Schema-by-example is faster than schema-by-specification, and it makes the swarm’s outputs trivially aggregable downstream.
Phase 2b - fifteen extractors in parallel
Same schema, one extractor per remaining deal, all fifteen launched in a single message as background processes. Each prompt named the specific files in its folder and flagged any deal-specific gotcha. Two failure modes showed up, both worth naming because they recur in any parallel-extractor swarm.
The first was a silent miss. One agent returned a “completed” status with mid-task narration as its summary - it had analyzed the documents and never written the output JSON. The status looked clean; the deliverable was missing. The only thing that caught it was a habit built the hard way: before declaring a phase done, list the output directory and count the files. The mismatch fired immediately, I relaunched the one extractor, and the phase closed.
The second was a reclassification cascade. Two extractors looked at their folders and reported back, this is not what you think it is. One was a deal from a different sponsor shop entirely, kept as comparative reference. Another was a joint-venture partnership document, not a property LOI. Both got flagged as outliers to the synthesis agent rather than deleted - comparative and partnership data are still useful, they just can’t count as evidence of our posture. A subagent that tells you the work is mis-scoped is doing the most valuable thing it can. Trust those reports.
Phase 3 - synthesis
One agent carried the heaviest load in the pipeline. It read all sixteen extraction JSONs, clustered terms across deals, separated the shop’s actual negotiating posture from its stated one, and produced three artifacts: a clean DOCX master template, a DOCX playbook with clause-by-clause commentary and case references back to specific deals, and an XLSX comparison matrix with every term across every deal in one grid. I used python-docx and openpyxl to produce real Word and Excel files, not Markdown, because the deliverables had to land with dealmakers who open them in Office and never see the JSON.
The brief was explicit about the outliers and small-sample warnings, so the synthesis agent saw the lineage instead of inferring it. The most useful insight came from one extractor noticing an internal document that compared the shop’s LOI against three competitors side by side. The pattern that fell out: the shop’s LOI form is whichever LOI most recently closed. Not a designed template - an accreted one. Nobody in the shop would have said it that way; the documents said it for them.
What the architecture earned
- The grill saved the project from drift. Eight branches resolved up front kept the scope locked before any tool ran. Five minutes of question-and-answer saved hours of cleanup.
- Approval gates let me redirect. The Phase 1 shortlist surfaced the small-sample problem before extraction ran. The gate is where the human judgment lives.
- The pilot de-risked the swarm. A schema produced by example is faster to write, easier to validate, and harder to misread than one produced by specification. Run one, read the output, then fan out.
- Trust but verify on completion. A subagent that reports “completed” with nothing in the output directory is a real failure mode, not an edge case. List the directory before you close the phase.
- Subagents surface what grep cannot. The template-artifact header, the accreted LOI form, the partnership outlier - none were grep-able. Each was one agent reading one folder end to end and noticing what didn’t fit. That is the part of agent work that earns the compute.
Numbers
- 111 deal folders swept
- 21 qualifying deals identified
- 16 deals extracted in parallel
- 21 subagent invocations total (4 scouts + 1 pilot + 15 extractors + 1 synthesis, plus 1 re-launch)
- 7 institutional findings about the shop’s own LOI practice that nobody had named
- 3 deliverables in formats the dealmakers actually use
Closer
The work the agents did was not negotiation. It was reading. A decade of buyer-side LOIs is a body of evidence nobody in the shop has the hours to read straight through, carried by older partners only as a felt sense - we usually push back on no-shop, we usually concede on inspection window, we never give up assignability. The swarm made the felt sense legible.
The architecture isn’t exotic: a grill, a scout sweep, a pilot, a fan-out, a synthesis, with approval gates between each phase. Next time I run it - on a sell-side archive, a vendor-contract archive, a discovery-spec archive - the shape will be the same and the deals will be different. It earns its keep precisely because it is contract-shaped and content-agnostic.
Files all the way down, again. Same as the rest of the work.