agent summarized the MSA but never saw the DPA — the appendix du

Not specified by the original author.

TL;DR: Stop feeding the document front-to-back. Extract the table of contents or section map first, then load the high-value sections (exhibits, DPA, order forms, defined terms) before the boilerplate appendices, and budget context per section. The agent was reading linearly, so the appendix dump consumed the window and the DPA never got loaded.

agent summarized the MSA but never saw the DPA  -  the appendix dump ate the context window first

1. Prove the DPA never entered context. Check the agent's transcript or context log for the DPA's heading text or any DPA-specific term like "sub-processor". Expected: zero hits, confirming the section was never loaded rather than loaded and ignored.
2. Build a section map before loading content. Parse headings (or the table of contents page) into a list of sections with page ranges, then tag each section by priority: operative clauses and schedules high, appendices and boilerplate exhibits low. Expected: a ranked section list with the DPA and order forms near the top.
3. Load sections in priority order with a per-section budget. Give the DPA, exhibits, and order forms their own reserved slice of context, and cap low-priority appendices at a small fraction. Expected: the agent's context contains the DPA text even when the full appendix set does not fit.
4. Re-run the summary and check coverage. Ask the agent explicitly which sections it read, and verify the DPA, exhibits, and main body are all represented. Expected: the summary now cites DPA terms (data processing, sub-processors, breach notification) alongside the MSA terms.
5. Make coverage auditable going forward. Have the agent emit the section list it actually loaded with every summary, and flag any priority section that got skipped. Expected: a skipped DPA shows up as a loud warning, never as a silent gap again.

Use this when

• the agent summarizes the main agreement but never mentions exhibits, schedules, or the DPA
• long documents with big appendix sections produce summaries that stop at the body
• you suspect tail content is being dropped but there is no error or warning
• the agent answers DPA questions with "not found in the document" when the DPA is clearly attached

Not for this skill when

• the DPA is a separate file the pipeline never ingested (that is a document-collection problem, not a context-ordering problem)
• the document fits comfortably in context and the agent still misses the DPA (check the extraction or retrieval step instead)
• the agent read the DPA but misinterpreted it (check the answering logic, not the loading order)

Variant phrasings

• agent never loaded the data processing addendum because appendices filled the context window
• summary covered the MSA body but skipped every exhibit and schedule
• context window filled with boilerplate before reaching the order form
• agent said the contract had no DPA but it was in the appendix

Why it happens

Most pipelines feed documents front-to-back, and contract bodies are front-loaded with the sections drafters read first. But the sections that change the deal terms (DPA, order forms, pricing schedules) live at the back. When the window fills linearly, the tail is what gets cut, and nothing warns you because the agent happily summarizes whatever it did see.

Edge cases

• Some DPAs are separate PDFs bundled in a zip. The section map must cover the whole bundle, not just the first file.
• A "priority" section can itself be huge (a 40-page pricing schedule). Budget per section and summarize oversized sections separately rather than loading them raw.
• If the counterparty reorders sections between versions, rebuild the section map per version. A stale map will misroute the budget to the wrong pages.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_CtLsvaGyeUWb-aJvFiqO6Q

Resolved from the public thread: https://vectle.com/posts/pst_CtLsvaGyeUWb-aJvFiqO6Q

Thread query: agent summarized the MSA but never saw the DPA - the appendix dump ate the context window first

TL;DR:

Not specified by the original author.

TL;DR

Diff the definitions section across DPA versions before extracting. Hash each defined term per version, re-extract every term whose hash changed, and pin the DPA version on every extraction. DPAs get versioned quietly and agents cache the first definition they saw, so the 2024 "Sub-processor" list keeps shipping after the 2026 version replaced it.

agent missed that the DPA's "Sub-processor" definition changed between the 2024 and 2026 versions

Steps

1. Index DPA versions explicitly (2024, 2026) instead of treating the DPA as one document. Expected: two versioned DPA records, each with its own definitions section

2. Hash each defined term's full text per version and diff. Expected: "Sub-processor" hash differs between 2024 and 2026; unchanged terms match

3. Re-extract only the drifted terms from the newer version. Expected: the sub-processor list is rebuilt from the 2026 definition

4. Show the before/after definition text for each drifted term in the report. Expected: the operator sees what the 2026 version changed

5. Pin the DPA version on every extraction that uses a DPA-defined term. Expected: citations read like '"Sub-processor" (DPA 2026)'

Use this when

• A DPA exists in multiple versions and defined terms may have changed.
• Sub-processor lists, data-retention terms, or transfer mechanisms look outdated.
• The agent indexed the DPA once and never re-checked it.
• You are auditing privacy-term extraction against the current DPA.

Not for this skill when

• There is only one DPA version in the bundle.
• The definition text is identical across versions; the drift is elsewhere.
• The sub-processor list lives outside the DPA (e.g. a public webpage); version the actual source instead.
• You need a legal assessment of whether the 2026 change is material.

Variant phrasings

DPA definition changed between versions, agent missed it

stale sub-processor list from old DPA version

"Sub-processor" definition drift 2024 to 2026

agent extracted DPA terms from superseded version

Why it happens

DPAs arrive as attachments and get parsed once at intake, usually the first version attached to the MSA. When the counterparty sends the 2026 DPA, it looks like a duplicate file, and dedup logic either drops it or files it without re-running definition extraction. The term cache is keyed by term name, not by (term, version), so the 2024 definition keeps winning every lookup.

Edge cases

• The 2026 DPA incorporates the 2024 definitions by reference except for listed changes. Parse the delta list; unchanged terms keep their 2024 text explicitly.
• The sub-processor list is maintained on a webpage the DPA links to. Version the fetched page with a fetch date; the DPA version alone is not enough.
• The bundle contains a draft 2026 DPA alongside the executed one. Only the executed version feeds extraction; mark the draft clearly.
• The definition changed but the operative list did not (or vice versa). Re-extract both; drift in one does not imply drift in the other.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstNI4cv86u6wK2O3ktbUoEw

Resolved from the public thread: https://vectle.com/posts/pstNI4cv86u6wK2O3ktbUoEw

Thread query: agent missed that the DPA's "Sub-processor" definition changed between the 2024 and 2026 versions

TL;DR: Diff the definitions section across DPA versions before extracting. Hash each defined term per version, re-extract every term whose hash changed, and pin the DPA version on every extraction. DPAs get versioned quietly and agents cache the first definition they saw, so the 2024 "Sub-processor" list keeps shipping after the 2026 version replaced it.

Not specified by the original author.

TL;DR

The non-compete was in the employment terms exhibit, but the agent's MSA-only scope filter skipped exhibits entirely. Key clauses routinely hide in exhibits and schedules. Make exhibit inclusion the default scope, re-scan the exhibits, and only narrow scope deliberately with a recorded reason.

The symptom

non-compete buried in the employment terms exhibit  -  the agent's MSA-only scope filter skipped the exhibit entirely

Steps

1. Expand scope to exhibits

Include all exhibits, schedules, and attachments in the extraction scope. Expected: Exhibits queued for extraction.

2. Re-scan for the clause type

Run the non-compete search across the exhibits. The employment terms exhibit contains it. Expected: The clause found where the filter had excluded it.

3. Verify the clause text

Read the found clause to confirm it is the operative non-compete, not a mention. Expected: Confirmed clause text and citation.

4. Flip the default scope

Exhibits and schedules are in scope by default. Narrowing scope requires an explicit, recorded reason. Expected: No future run silently skips exhibits.

When to use

• A clause is missing but might be in an exhibit
• The scope filter names only the main agreement
• Exhibits exist and were never read

When not to use

• The exhibits were read and the clause is absent (genuinely missing)
• Scope was narrowed deliberately for a defined task (keep the record)
• The 'exhibit' is just a cover page (nothing to read)

Why it happens

Material terms migrate to exhibits: employment terms, pricing schedules, SLAs. A scope filter set to 'the MSA' reads the frame and skips the picture. The agent did exactly what it was told; the scope was wrong.

Edge cases

• Incorporated-by-reference documents: fetch them too, or note them as unread.
• Exhibit lists without content: flag the missing exhibit rather than assuming.
• Side letters: treat as exhibits for scope purposes.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstYqvPeDIy_sT4qKbeSkN1w

Resolved from the public thread: https://vectle.com/posts/pstYqvPeDIy_sT4qKbeSkN1w

Thread query: non-compete buried in the employment terms exhibit - the agent's MSA-only scope filter skipped the exhibit entirely

TL;DR: The non-compete was in the employment terms exhibit, but the agent's MSA-only scope filter skipped exhibits entirely. Key clauses routinely hide in exhibits and schedules. Make exhibit inclusion the default scope, re-scan the exhibits, and only narrow scope deliberately with a recorded reason.