Operations RunbookRelationship Intelligence Pipeline · v1.0

How the intelligence gets made.

From Dropbox audit to AI-queryable artifact — the full operational breakdown of the Windfield Relationship Intelligence pipeline. Every phase, every prompt, every output artifact, every MCP surface. This is the runbook a new operator could use to re-produce the report from scratch.

Generates
Relationship Intelligence Report
Source
Dropbox · Brokerage Transactions
Owner
Tommy Saunders · IO
Runtime
~45 min end-to-end
Workflow Phases
6
Enumerate → Extract → Normalize → Reconcile → Classify → Assemble
Prompts
10
Phase-decomposed · single-responsibility chain
Output Formats
3
CSV ledger · Markdown narrative · HTML landing
MCP Tools Used
8
Dropbox read + write + search + share surface
01
Context & Problem Statement

Why this workflow exists.

Windfield's eight-year transaction archive lives in Dropbox as 250+ individual deals spread across year-folders, each containing listing agreements, contracts, commission statements, lease agreements, and offering memoranda — all in varied formats, with inconsistent entity naming, and no master index. The insights that would tell Andrew Danner who his Tier 1 clients are, which patterns generate the most commission, and where to prospect next — those insights exist in the data, but they're buried across hundreds of PDFs.

Historically, surfacing these insights required days of broker time — reading contracts, cross-referencing LLCs, building pivot tables, manually spotting patterns. This workflow replaces that with an agentic pipeline that reads every document, normalizes every entity, classifies every client, and publishes three synchronized outputs in about 45 minutes. And critically — once instrumented, it re-runs on demand.

The insights were always in the data. The workflow's only job is to make them visible — in a form a broker can act on, and in a form another AI agent can query.

Operating principle \u00b7 IO platform
What this workflow replaces
A recurring 3-day analyst engagement producing a static PowerPoint, run maybe once a year. Now: an on-demand pipeline producing three synchronized artifacts (CSV, Markdown, HTML), queryable by AI agents, auto-refreshable on every major deal close.
02
Architecture Overview

Four stages. End-to-end pipeline.

Data flows through four clearly-scoped stages. Each stage has its own tooling, its own outputs, and its own quality gates. Drift in any stage is caught before it contaminates the next.

Stage 01
Input
Dropbox
Source of truth for all transaction evidence: contracts, commission statements, listing agreements, master logs.
250+ transactions · 8 years
Stage 02
Processing
Claude Code + MCP
Six-phase agentic pipeline. 10 prompts. Entity normalization, source reconciliation, tiering, pattern detection.
8 MCP tools · ~45 min
Stage 03
Artifacts
Three Formats
CSV master ledger (row-level source of truth). Markdown narrative (portable, git-friendly). HTML landing page (branded, shareable).
Synchronized · versioned
Stage 04
Distribution
MCP Server
Artifacts published back to Dropbox and exposed via MCP server — queryable by external AI agents, AEO-ready.
6 endpoints exposed
Why the separation matters
Stage boundaries are audit points. After Stage 2 processing, the raw extraction is checkpointed to Dropbox — meaning if Stage 3 assembly has a bug, we don't re-read every PDF. The pipeline is idempotent at stage boundaries. This is the single most important architectural decision in the workflow.
03
The Source Layer \u00b7 Dropbox

Eight year folders. Hundreds of documents.

The pipeline reads from a single known location in Dropbox. Folder structure is semi-consistent across years; naming conventions vary enough that the enumeration phase cannot skip any folder.

Directory tree/Tommy Saunders/Brokerage Transactions/
# Source root
/Tommy Saunders/Brokerage Transactions/
├── 2018/
├── 2019/
├── 2020/
│   ├── Master Transaction Log 2020.xlsx
│   ├── Listing Agreements/
│   ├── Contracts/
│   ├── Commission Statements/
│   └── Lease Agreements/
├── 2021/  # same structure
├── 2022/
├── 2023/
├── 2024/
├── 2025/
├── 2026/  # active / in-progress
└── _Reports/  # output destination (created by pipeline)
    ├── RPT_windfield_master_transaction_ledger_2026-04-22.csv
    ├── RPT_windfield_relationship_intelligence_2026-04-22.md
    └── RPT_windfield_relationship_intelligence_2026-04-22.html

Inside each year folder the pipeline expects:

  • A master transaction log — typically XLSX, one row per deal, fields vary year-to-year but always include property, parties, price, commission, status.
  • Listing agreements — PDFs naming the property, the seller/landlord, and the listing terms. Used to verify who Windfield represented.
  • Purchase contracts — PDFs with buyer/seller, price, earnest money, close date, contingencies. Contract price and parties take precedence over master-log values.
  • Commission statements — PDFs with agent split, co-broker split, final commission. Commission statement is source of truth for the commission column in the final ledger.
  • Lease agreements — PDFs with tenant, landlord, rent, term. Used for lease-transaction rows and landlord-rep tracking.

File naming is non-standardized across years. A purchase contract for 8331 N Green Hills might live under any of: Contract_8331NGreenHills.pdf, 8331 Green Hills - Executed Contract.pdf, NSA Purchase Agreement - Signed.pdf, or PSA_8331_Danner_NSA.pdf. The pipeline's search phase uses fuzzy-match against property addresses and party names rather than filename conventions.

04
MCP Toolkit & Confirmation Protocol

Eight tools. Three confirmation tiers.

The pipeline operates through the Dropbox MCP server. Every tool is tagged by confirmation tier — read-only tools auto-execute, mutations require explicit user confirmation, share operations require confirmation plus an explicit warning.

mcp__dropbox__list_folderT1 · Read
Enumerate contents of a folder. Cursor-based pagination for folders over 200 entries. Used in the Enumeration phase to map every year folder.
args: path, recursive?, cursor?
mcp__dropbox__searchT1 · Read
Full-text and filename search across Dropbox. Used to find contracts and commission statements by address and party name, not filename — since filenames are non-standardized.
args: query, path?, max_results?
mcp__dropbox__get_file_contentT1 · Read
Extract content from PDF, DOCX, XLSX, TXT. 5MB extraction ceiling per call — larger files must be chunked or streamed by page. This is the core extraction tool.
args: path, as_text?
mcp__dropbox__get_file_metadataT1 · Read
File size, modified date, content hash. Used to decide whether a file has changed since last pipeline run (incremental refresh).
args: path
mcp__dropbox__get_usage_and_quotaT1 · Read
Account quota and usage. Monitored to ensure the workflow stays well under Dropbox limits during full re-runs.
args: (none)
mcp__dropbox__create_folderT2 · Mutate
Creates the _Reports/ destination folder if it doesn't exist. Tier 2 — requires user confirmation before execution.
args: path, autorename?
mcp__dropbox__create_fileT2 · Mutate
Writes the three output artifacts — CSV, MD, HTML — to _Reports/. Tier 2. Pipeline pauses for human confirmation before each file write.
args: path, content, mode (add|overwrite)
mcp__dropbox__create_shared_linkT3 · Share
Generates a shareable Dropbox link for the report. Tier 3 — highest caution. Requires explicit confirmation and a warning about external exposure. Never auto-run.
args: path, visibility, password?

The three confirmation tiers

Tier 1 · Read-Only
Auto-execute. No confirmation required.
  • Listing folders, reading files, fetching metadata, searching
  • Cannot modify or share anything
  • Fail-safe by definition — worst case, stale read
  • Applies to: list_folder, search, get_file_content, get_file_metadata, get_usage_and_quota
Tier 2 · Mutations
Confirm before action.
  • Any write, create, or modification
  • Pipeline pauses, surfaces the intended change, waits for approval
  • one confirmation per file write — never batched
  • Applies to: create_folder, create_file
Tier 3 · Sharing
Confirm plus warning.
  • Any operation that exposes data externally
  • Explicit warning shown: This will create a link accessible outside Windfield
  • Never auto-run after a file write — even if the user is in a sharing flow
  • Applies to: create_shared_link
05
Phases 1 & 2

Enumerate, then extract.

The first two phases turn the Dropbox folder tree into a structured in-memory representation of every transaction. No interpretation happens here — just reading and parsing.

01
Phase 01The Enumeration~3 minutes

Map the entire Dropbox folder tree before extracting anything. The output is a manifest: every folder, every file, its type, its size, its last-modified date. This manifest is the contract every downstream phase operates against.

Tools Used
list_folder with cursor pagination
Inputs
Root path /Tommy Saunders/Brokerage Transactions/
Outputs
JSON manifest: 8 year folders, 200+ sub-files, all metadata
Quality Gate
All 8 year folders present (2018–2026), no broken pagination cursors
Promptphase-01-enumerate.prompt
# Phase 01 — Enumerate the Brokerage Transactions archive

You are Claude operating via the Dropbox MCP server. Your job is to map the
entire /Tommy Saunders/Brokerage Transactions/ folder tree.

Instructions:
1. Start at the root path.
2. Call mcp__dropbox__list_folder recursively.
3. Follow cursor pagination on every folder over 200 entries.
4. Build a JSON manifest with: path, type, size, modified, year_bucket.
5. Do NOT extract any file content in this phase.
6. Return the manifest as a Tier 1 read-only output.

Expected output schema:
{
  "year": "2024",
  "files": [
    { "path": "...Master Transaction Log 2024.xlsx", "type": "xlsx", "size": 45021 },
    { "path": "...Listing Agreements/...", "type": "pdf", ... }
  ]
}

Quality check before ending phase:
- All year folders 2018 through 2026 must appear in the manifest.
- If any folder is missing, HALT and surface to the operator.
02
Phase 02The Extraction~15 minutes

For each file identified in the manifest, pull the content and parse it into structured records. This is the longest phase by runtime — it's the only phase that touches every PDF.

Extraction is conservative: if a field is ambiguous (e.g., price appears in three places with three different numbers), all three are captured and flagged for Phase 4 reconciliation. Don't resolve ambiguity during extraction — preserve it for the reconciliation phase which has the cross-document context to resolve correctly.

Tools Used
get_file_content, search (for cross-referencing related docs)
Inputs
The manifest from Phase 01
Outputs
Raw transaction records: one per deal, all fields preserved with source attribution
Quality Gate
Every transaction has at least one source document. Commission records match master log ± 5% tolerance (anything outside flagged for Phase 04).
Promptphase-02-extract.prompt
# Phase 02 — Extract transaction records per year folder

Input: Manifest from Phase 01.

For each year folder:

1. Master log extraction:
   - Call get_file_content on the master transaction log XLSX
   - Parse rows. For each row, build a base transaction record with:
     property, parties, price, commission, status, date
   - Tag source: master_log

2. Contract extraction (for each property in master log):
   - Call search with property address as query, path scoped to year/Contracts
   - For each match: get_file_content
   - Extract: buyer, seller, price, earnest money, close date
   - Tag source: contract

3. Commission statement extraction:
   - Same search pattern, scoped to year/Commission Statements
   - Extract: agent split, co-broker split, net commission
   - Tag source: commission_statement

4. Listing agreement extraction:
   - Scoped to year/Listing Agreements
   - Extract: seller, listing terms, exclusivity
   - Tag source: listing_agreement

5. Lease agreement extraction (for lease transactions):
   - Scoped to year/Lease Agreements
   - Extract: tenant, landlord, rent, term
   - Tag source: lease_agreement

CRITICAL: Preserve all source values even when they disagree. Do NOT
resolve discrepancies in this phase. Output records with multi-valued fields
marked {{conflict}} for Phase 04 to handle.

Skip conditions:
- Files over 5MB: chunk by page, combine extracts
- Scanned PDFs with no OCR: surface to operator, skip rather than guess
06
Phase 3 \u00b7 Entity Normalization

One real relationship. Many LLCs.

Shane Crees doesn't buy properties — Kansas City Properties and Investments LLC does. Sandy Knoernschild doesn't sell — CKC Holdings LLC does. Andrew Danner himself buys through dozens of single-purpose LLCs. Without normalization, the data shows hundreds of distinct counterparties. With normalization, it shows a dozen real relationships.

03
Phase 03The Normalization~6 minutes

Apply a canonical entity ID to every party in every transaction. This is the phase that turns the data from a transaction log into a relationship graph.

The normalization rules

Each rule maps any of a family of observed entity names to a single canonical key. Order matters — Danner-interest rule runs last, after the named-principal rules, to avoid mis-tagging passive investment vehicles.

KCPI · Kansas City Properties and Investments LLC · K.C. PropertiesAny LLC managed by Shane Crees
Shane Crees (KCPI)Canonical entity ID
CKC Holdings LLC · CKC LLC · various “CKC” entitiesAny LLC managed by Sandy Knoernschild
Sandy Knoernschild (CKC)
Parkville Development 38/140 LLC · Parkville Development 50 · Parkville Development VV1Any "Parkville Development N" entity
Brian Mertz (Parkville Development)
Kuehl Capital LLC · Diversified Building entitiesAny LLC where Adam Reth is managing member
Adam Reth (Kuehl Capital)
Island Time Group LLC · Tiki Taco LLC · EK entitiesAny LLC managed by Eric Knott
Eric Knott (Tiki Taco)
Walker LaBrunerie Trust · Barry Road Nominee Realty TrustTrust entities associated with Claire LaBrunerie
Claire LaBrunerie (Walker Trust)
SSQ LLC · NAPT LLC · SDRE LLC · any other Shane-Danner-managed LLCPassive investment LLCs managed by Shane Danner
Shane Danner (Principal Investment)
Any LLC where Andrew Danner is a listed manager or memberCatch-all — runs last, after specific rules above
Danner Entity (Principal Interest)Triggers the "Principal Interest" tag
Promptphase-03-normalize.prompt
# Phase 03 — Entity normalization

Input: Raw transaction records from Phase 02.

For every party in every transaction:

1. Apply the following rules in order (first match wins, except the
   Danner catch-all which runs last):

   Rule 1 — Shane Crees / KCPI
     IF party matches /KCPI|Kansas City Properties.*Investments|K\.?C\.? Properties/i
     THEN canonical_entity = "shane_crees_kcpi"

   Rule 2 — Sandy Knoernschild / CKC
     IF party matches /CKC/i AND listed manager is Knoernschild
     THEN canonical_entity = "sandy_knoernschild_ckc"

   Rule 3 — Parkville Development group
     IF party matches /Parkville Development (38\/140|50|VV1|\d+)/i
     THEN canonical_entity = "brian_mertz_parkville"

   Rule 4 — Adam Reth / Kuehl Capital
     IF party matches /Kuehl Capital|Diversified (Building|Investment)/i
     THEN canonical_entity = "adam_reth_kuehl"

   Rule 5 — Eric Knott / Tiki Taco
     IF party matches /Island Time|Tiki Taco|EK (Holdings|Restaurants)/i
     THEN canonical_entity = "eric_knott_tikitaco"

   Rule 6 — Shane Danner passive LLCs
     IF party is one of [SSQ LLC, NAPT LLC, SDRE LLC, ...]
     THEN canonical_entity = "shane_danner_principal"

   Rule 7 — Danner catch-all (runs LAST)
     IF party is an LLC AND Andrew Danner is a listed manager or member
     THEN canonical_entity = "danner_entity_principal"
     AND add_tag "principal_interest"

2. If no rule matches, record the literal party name as the canonical entity.
   # These are the "long tail" — one-off buyers and sellers.

3. Output: the transaction records enriched with canonical_buyer_entity,
   canonical_seller_entity, and any applied tags.

Do NOT reassign individuals (people) to entities. Keep Shane Crees as Shane Crees
even if he appears in the broker column; tag separately from KCPI.
Why Rule 7 runs last
Andrew Danner is a managing member of a long list of passive investment LLCs — some of which have other, more specific owners (like the Shane Danner LLCs in Rule 6). If the Danner catch-all ran first, it would over-attribute deals to Andrew personally when the real economic interest sits with a different family member or investment vehicle. Rule ordering preserves attribution fidelity.
07
Phase 4 \u00b7 Source Reconciliation

When three sources disagree, which one wins?

The master log says the price was $1.5M. The contract says $1.65M. The commission statement implies $1.6M. Reconciliation resolves these disagreements using an explicit source-priority rule set — not majority vote, not heuristic.

04
Phase 04The Reconciliation~4 minutes

The pipeline applies three reconciliation rules, in priority order. Each rule resolves a specific class of field.

Rule 1 — Price & parties
Contract wins. The executed purchase contract is the legal source of truth for who paid what to whom. Master-log discrepancies are noted in the ledger but not surfaced in the narrative.
Rule 2 — Transaction ID
Master log wins. Internal transaction numbering follows the master log's sequence. Contracts rarely have transaction IDs, commission statements sometimes have their own.
Rule 3 — Commission amount
Commission statement wins. Supersedes both contract-implied and master-log-stated commission. If no commission statement exists, use price × blended_gci_rate as a computed estimate and flag with ‎⚠ estimated.
Rule 4 — Unresolvable
If a source conflict can't be resolved (e.g., two contracts with different prices for the same property), the row is flagged NEEDS_HUMAN_REVIEW and the pipeline continues. Never guess.
The $200K pattern
A recurring class of master-log discrepancy: the log shows the listed price (what Windfield put on market), the contract shows the executed price (what the buyer actually paid). On average these diverge by $100-300K downward in the Windfield data. The reconciliation rule correctly privileges the contract because it captures what actually happened — but this is the reason the final Total Volume numbers may look slightly lower than Andrew's internal tracking.
08
Phase 5 \u00b7 Tiering & Pattern Recognition

From transactions to strategic structure.

With clean, reconciled, entity-normalized data, the pipeline can finally answer strategic questions. Phase 5 produces the client tiers and identifies the four repeating patterns that define how Windfield actually makes money.

05
Phase 05The Classification~5 minutes

Two classifications run in parallel: client tiering (who are the inner-circle relationships?) and pattern recognition (what are the repeating deal structures?).

Tier 1 criteria
5+ transactions across any role (buyer, seller, landlord, tenant). The inner circle.
Tier 2 criteria
3–4 transactions. The second ring — highest-leverage conversion opportunities into Tier 1.
Tier 3 criteria
Single transaction, but $1.5M+ in volume. Notable whales. Always flagged because each is a future-Tier-1 candidate.
Patterns scanned
Subdivide-and-Sell · Relationship Recycler · Personal Interest Multiplier · Anchor Tenant Play — each with specific structural fingerprints
Promptphase-05-classify.prompt
# Phase 05 — Tiering and pattern recognition

Input: Normalized, reconciled transaction records.

Part A — Tiering

For each unique canonical_entity, count transactions (all roles combined):
  - Tier 1: count >= 5
  - Tier 2: count 3-4
  - Tier 3: count == 1 AND max(price) >= 1_500_000
  - Long tail: everything else (not surfaced in the narrative)

For each Tier 1 and Tier 2 entity, produce a client card with:
  name, contact_person, total_volume, transaction_count, roles, key_properties

Part B — Pattern detection

Scan each canonical_entity's transaction history for these structural patterns:

  Pattern 1 — Subdivide-and-Sell:
    Entity acquires large tract → subdivides into pad sites → Windfield lists
    individual pads → sold to different buyers within 24 months of acquisition.
    Fingerprint: one buy transaction followed by 3+ related sales, same root parcel.

  Pattern 2 — Relationship Recycler:
    Entity appears as buyer, then as landlord (lease transactions for same property),
    then as seller. All through Windfield.
    Fingerprint: buy → lease_series → sell, same property, same canonical_entity.

  Pattern 3 — Personal Interest Multiplier:
    Same as Pattern 2 but the entity is tagged "principal_interest".
    Fingerprint: Pattern 2 fingerprint + principal_interest tag.

  Pattern 4 — Anchor Tenant Play:
    Vacant ground listing transitions to sale shortly after national tenant commits.
    Fingerprint: listing_type="vacant_ground" + national_tenant_identified + sale
    close date within 6 months of listing.

For each detected pattern, produce a pattern card with:
  pattern_name, canonical_examples (up to 3), fingerprint_match_count
09
Phase 6 \u00b7 ICP Generation

Three Ideal Customer Profiles, derived from the data.

The ICPs aren't invented — they're extracted. Each one is the common-trait synthesis of a cluster of existing Windfield clients, plus explicit match signals and an actionable prospecting step.

06
Phase 06The ICP Synthesis~5 minutes

Three profiles are generated — one per customer cluster observed in the data:

  • ICP 1 — Local Owner-Operator: derived from the Tier 1 client cohort. Common traits: 3–10 property portfolio, LLC structure, full-lifecycle transactions through Windfield, Barry Rd / Green Hills / Smithville corridor concentration.
  • ICP 2 — National / Regional Tenant: derived from the pad-site buyer cohort. Common traits: chain expansion in KC metro, 0.5–3 acre site needs, $300K–$2M per-pad budgets, shovel-ready preference.
  • ICP 3 — Emerging Concept / Franchise: derived from the recurring lease-tenant cohort. Common traits: 1–3 existing KC locations, expansion-mode, 1,000–3,000 SF footprint, $15–$25/SF NNN budget.

For each ICP, the prompt produces: a profile, a list of match signals, a catalog of current examples from existing Windfield clients, and a specific prospecting action.

10
Output Artifacts

Three formats. Same truth.

Every pipeline run produces three synchronized outputs — the same underlying data expressed three different ways for three different consumers. Written to /Tommy Saunders/Brokerage Transactions/_Reports/.

CSV
RPT_windfield_master_transaction_ledger_YYYY-MM-DD.csv
The row-level source of truth
15 columns · one row per transaction · every claim in the report traceable back to a specific row here. For finance, audit, and pivot-table analysis. Opens in Excel.
15 columns · 250+ rows · ~60 KB
MARKDOWN
RPT_windfield_relationship_intelligence_YYYY-MM-DD.md
The portable narrative
Same content as the HTML report, rendered as plain markdown. Git-friendly, AI-native, diffable. Editable in any text editor. The canonical source for re-rendering into any other format.
19 sections · ~45 KB
HTML
RPT_windfield_relationship_intelligence_YYYY-MM-DD.html
The branded landing page
Single-file, self-contained, mobile responsive. Windfield brand system. What gets shared with Andrew. Opens in any browser, prints to PDF cleanly.
Standalone · ~121 KB · print-ready

The CSV ledger schema

CSVRPT_windfield_master_transaction_ledger_YYYY-MM-DD.csv \u00b7 15 columns
Property Name, Property Address, Transaction Date, Transaction Type,
Status, Price, WRE Agent, Corresponding Broker,
Corresponding Brokerage, Seller/Landlord, Buyer/Tenant,
Commission, Dropbox Reference Folder, Contract Link, Notes

# Notes field flags:
#   PRINCIPAL_INTEREST  — Danner entity on at least one side
#   ESTIMATED_COMMISSION — commission computed from price × GCI rate
#   NEEDS_HUMAN_REVIEW  — reconciliation conflict not resolvable
#   T1_CLIENT / T2_CLIENT / T3_WHALE — tier assignment
#   PATTERN_{1-4}       — pattern match (one deal may match multiple)

The Markdown artifact — sample section

The Markdown version is byte-identical to the HTML in content — only the presentation differs. Here's what Section 03 (Tier 1 Clients) looks like as raw markdown:

MarkdownRPT_windfield_relationship_intelligence_2026-04-22.md \u00b7 excerpt
## Section 03 · The Inner Circle — Tier 1 Clients

**Six relationships run the revenue engine.**

Clients with five or more transactions. Together they represent the
brokerage's core commission base and the highest-leverage relationship
investments going forward.

### KCPI — Kansas City Properties & Investments LLC

- **Contact:** C. Shane Crees
- **Role:** Buyer AND Seller
- **Volume:** $12M+
- **Transactions:** 10+
- **Key properties:** Buckners · 1501 S 169 · Richardson Plaza ·
  Fairview North · Shoppes of Smithville · 1705 Johnson Industrial ·
  Stewart Commercial Park

### CKC Holdings LLC

- **Contact:** Sandy Knoernschild
- **Role:** Buyer AND Seller
- **Volume:** $15M+
- **Transactions:** 8+
- **Key properties:** GH14 Lot 4 ($3.06M) · Kelly Crossing ($2.15M) ·
  Creekside ($2.5M) · Hwy N Storage ($2.1M) · 7600 Roanridge ($3.1M) ·
  North Brighton ($1.04M) · Staley Storage ($2M pending)

# ... continues for all 6 Tier 1 entities ...
Why three formats
Each format serves a different consumer. Andrew opens the HTML — it's what he sees in his browser and what he'll email externally. Tommy edits the Markdown — it's git-trackable, diffable, and the source for any future re-rendering. The bookkeeper pivots the CSV — because commission analysis is still a spreadsheet problem. Three formats mean zero format-driven information loss.
11
The MCP Server Surface

The report as a queryable API.

The artifacts sit in Dropbox, but a Windfield-hosted MCP server exposes them as structured endpoints — meaning external AI agents (Andrew's own Claude, partners running their own agents, AEO-ready search crawlers) can query specific facets of the report directly.

Instead of asking another AI to download and parse a PDF, the MCP server lets an agent call get_tier_1_clients() and receive structured JSON. Instead of web-scraping the HTML to find the LTV:CAC ratio, an agent calls get_kpi(name="ltv_cac"). This is what AEO-ready actually means operationally.

The server manifest

JSONwindfield-intelligence-mcp.manifest.json
{
  "name": "windfield-intelligence",
  "version": "1.0.0",
  "description": "Windfield Real Estate relationship intelligence — queryable.",
  "source": {
    "type": "dropbox",
    "path": "/Tommy Saunders/Brokerage Transactions/_Reports/",
    "refresh_cadence": "monthly"
  },
  "tools": [
    {
      "name": "get_tier_1_clients",
      "description": "Returns the six Tier 1 client cards.",
      "input_schema": {},
      "output_schema": "TierClientCard[]"
    },
    {
      "name": "get_tier_2_clients",
      "description": "Returns Tier 2 client cards (3-4 transactions).",
      "input_schema": {},
      "output_schema": "TierClientCard[]"
    },
    {
      "name": "search_transactions",
      "description": "Full-text search across the master ledger.",
      "input_schema": { "query": "string", "limit": "number" },
      "output_schema": "TransactionRow[]"
    },
    {
      "name": "get_pattern",
      "description": "Get detailed pattern description and examples.",
      "input_schema": { "name": "'subdivide'|'recycler'|'principal'|'anchor'" },
      "output_schema": "Pattern"
    },
    {
      "name": "get_icp",
      "description": "Get an Ideal Customer Profile by id (1, 2, or 3).",
      "input_schema": { "id": "number" },
      "output_schema": "ICPProfile"
    },
    {
      "name": "get_kpi_scorecard",
      "description": "Current KPIs with baselines and 2027 targets.",
      "input_schema": {},
      "output_schema": "KPIScorecard"
    }
  ]
}

Exposed endpoints

get_tier_1_clients()
Returns six client cards — KCPI, CKC, Danner Entities, Walker LaBrunerie, Barry Plaza Shoppes, Kuehl Capital. Each with volume, count, role, key properties.
Read
get_tier_2_clients()
Returns 10 recurring client cards. Second-ring relationships with 3-4 transactions each.
Read
search_transactions(query, limit)
Full-text search across the master ledger. Example: search_transactions("Tiki Taco", 10) returns all Eric Knott deals with source document links.
Search
get_pattern(name)
Returns structured description and up to 3 canonical examples for one of the four Windfield patterns. Use to explain the commission model.
Read
get_icp(id)
Returns ICP profile by ID (1=Local Owner-Operator, 2=National Tenant, 3=Emerging Concept). Includes profile, signals, current examples, prospecting action.
Read
get_kpi_scorecard()
Returns the 7-metric current-vs-target scorecard: annual volume, repeat rate, avg commission, lease count, co-broker count, outside-Northland %, new-client acquisition.
Read
Why this matters strategically
When Andrew's personal Claude is asked what are Windfield's top clients?, it doesn't guess — it calls get_tier_1_clients() and returns accurate, audited data. When a partner broker's Claude wants to know if Windfield has pad sites available for a national QSR client, it calls get_pattern("anchor") and gets the current inventory framing. The report stops being a PDF and starts being infrastructure.
12
Quality Gates & Refresh Cadence

Ten checks. Every run. No exceptions.

Before any artifact is written to Dropbox, the pipeline runs a 10-point completion checklist. A single failure halts the pipeline and surfaces the issue to the operator.

01
All 8 year folders enumerated (2018–2026). No pagination cursors left unresolved.
02
All transactions reconciled — no unflagged source discrepancies in the ledger.
03
Entity normalization applied consistently — a spot-check sample of 20 random rows confirms canonical IDs match the rule set.
04
All Tier 1 clients have ≥5 verified transactions each. No entity promoted with under-documented deals.
05
Commission amounts cross-checked against commission statements where available. Estimated commissions clearly flagged.
06
Principal Interest tag applied to all Danner-controlled transactions. No Danner-entity deal untagged.
07
Geographic concentration computed correctly. Sum of market shares equals 100% ± 0.5% rounding.
08
Co-brokerage partner list complete — all distinct corresponding brokerages represented, not just the largest.
09
Markdown and HTML outputs both render without errors — HTML validates, MD passes linter, no broken internal links.
10
Markdown and HTML are content-synced — same data, different presentation. Same version number. Same timestamp.

Refresh cadence

Monthly
Full re-run
First business day of each month · catches all deals closed in the prior month · committed to git with version bump
Event-driven
On $1M+ close
Any deal closed at $1M+ triggers an incremental refresh within 48 hours — especially for whale deals that move the annual totals
Quarterly
Deep audit
Full re-run plus manual spot-check of 10 random transactions against source PDFs · confirms pipeline hasn’t drifted
Versioning
Semver · v1.2.3
Major = prompt structural change · Minor = data refresh · Patch = bug fix or clarification edit
13
Operations & Contacts

Who owns what.

Pipeline Owner
Tommy Saunders
Intelligent Operations AI · designs, runs, maintains the workflow · tommy@intelligentoperations.ai
Output Reviewer
Andrew Danner
Broker/Owner · reviews each refresh before external distribution · Andrew@windfieldrealestate.com
Monthly SLA
3 biz days
First business day of month → artifacts published to Dropbox by end of third business day
Escalation
Halt & flag
Pipeline never auto-continues on a quality-gate failure · operator reviews before any manual override

Related documents

Master Prompt
TPL_windfield_5yr_brokerage_analysis_master_prompt.md
The full 441-line master prompt used by Claude Code to run the pipeline end-to-end. All phase prompts above are sections of this master.
Intelligence Report
RPT_windfield_relationship_intelligence_2026-04-22.html
The latest output artifact — the branded HTML landing page produced by this workflow. What gets shared externally.
Economic Impact Model
RPT_windfield_economic_impact_2026-04-22.html
Paired deliverable — prices the cost of building and running the full Windfield IO platform (of which this workflow is one module).
Dropbox Operations Guide
IO_Dropbox_Operations_Guide.md
Folder structure conventions and naming prefixes (PRJ_, RPT_, TPL_, etc.) that this pipeline adheres to.

Methodology notes

The pipeline is prompt-decomposed, not monolithic — each phase has its own single-responsibility prompt with its own quality gate. This is the same pattern the IO Article Library uses for generating long-form content: a weak Phase 5 output doesn't contaminate Phase 6 because Phase 6 receives only the Phase 5 output plus its own brief, not the cumulative conversation.

All extraction is evidence-first. Every field in the ledger traces back to a specific source document via the Dropbox Reference Folder and Contract Link columns. The narrative report (HTML and MD) never states a number that doesn't appear verbatim in at least one source document. If the model wants to claim a pattern or trend that isn't directly evidenced, it's downgraded to a framed observation in the narrative rather than a factual claim.

The pipeline is designed to be re-runnable indefinitely. Nothing about the current run is hardcoded except paths and the six canonical-entity rules — those are the only pieces of prior knowledge the workflow needs. Everything else is derived from the source data at runtime. If Windfield's relationship map shifts (new Tier 1 emerges, existing one fades), the next run captures it automatically. The workflow is built to last longer than any specific insight it produces.