Chapter 3.1 Multi-Context AI Systems

In Chapter 2.5, the Build Prompt node assembles the advisory prompt from the current intake submission alone. Every contact is assessed in isolation without knowledge of prior assessments, peer contact patterns, or external market signals. That isolation is the single-call limit identified in 3.0.2 Structural Limits of Part II.

This chapter resolves the first layer of that limit: adding a retrieval step before the AI call so the prompt is assembled from a richer context than the current payload alone. The three-node AI pattern is unchanged. What changes is what the Build Prompt node builds from.

Learning Objectives

After completing this chapter, you will be able to:

  • Explain the single-context ceiling: why an AI call that assesses each record in isolation produces miscalibrated recommendations even when the model performs correctly.
  • Implement the retrieval-augmented advisory pattern: Retrieve → Normalize Context → Build Prompt as a three-stage pre-processing sequence before the AI call.
  • Design a context assembly schema that encodes peer contact data, historical signals, and market context into a structured, token-efficient format the AI prompt can consume.
  • Apply context window discipline: select and normalize only the signals most predictive for the assessment task, rather than injecting raw CRM records into the prompt.
  • Evaluate the trade-off between context richness (more signals, higher accuracy) and context cost (more tokens, higher latency, higher cost per call) for a given use case.
  • Troubleshoot a multi-context retrieval workflow where peer context records are not appearing in the AI prompt, by tracing the retrieval query, normalization logic, and context assembly step.

3.1.1 The Single-Context Ceiling

The Single-Context Ceiling

In Part I and Part II, the Build Prompt node receives one input: the current execution’s data. The prompt reflects that data precisely. It also reflects nothing else.

This is correct when assessment dimensions are truly independent across contacts. It becomes a ceiling when two conditions hold simultaneously:

  1. The assessment quality improves with reference context. Scoring a contact’s suitability is more calibrated when you know the distribution of scores among similar contacts the reference frame that peer context provides.
  2. The reference context is structured and bounded. Context the AI cannot reliably locate or interpret adds noise, not signal. Raw contact records are not context; a normalized summary of peer scoring distributions is.

When both conditions hold, the retrieval-augmented advisory pattern is the correct architectural response.

Structured, bounded context produces more calibrated recommendations; raw unstructured context produces inconsistent ones.

TipDesign Practice

The single-call limit is not about AI capability a single-call AI can be highly accurate. It is about calibration. An assessor with no reference frame cannot tell whether a given score is high or low relative to the population. Peer context provides that reference frame.

3.1.2 The Retrieval-Augmented Advisory Pattern

Retrieval-Augmented Advisory Pattern

The retrieval-augmented advisory pattern extends the Part I three-node AI triplet (Section 1.3) with a retrieval stage before prompt assembly.

Part II single-context:

Build Prompt → HTTP Request (LLM) → Parse Response

Part III.1 multi-context:

Retrieve → Normalize Context → Build Prompt (enriched) → HTTP Request (LLM) → Parse Response

The Retrieve stage calls the HubSpot Contacts Search API to fetch a bounded set of recently assessed contacts. The Normalize Context stage transforms their raw property values into a compact, schema-defined peer_context object. The Build Prompt stage injects peer_context as a named field alongside the current submission data.

The HTTP Request and Parse Response nodes are unchanged. The output contract is unchanged. The only structural addition is two nodes before Build Prompt.

TipDesign Practice

Retrieval before the AI call is an architectural extension of Section 1.3, not a redesign. The three-node triplet still does exactly what it did. Retrieval is a data preparation step that makes the input richer not a change to how the AI call is structured or governed.

3.1.3 Context Assembly: From HubSpot to Prompt Field

Context assembly has three requirements: retrieve, normalize, and inject in that order.

Context assembly has three requirements: retrieve, normalize, and inject. Each step has a defined input and output. Skipping normalization and injecting raw records directly produces prompts that are difficult to trace and produce inconsistent outputs. The discipline is the same as output contract design: define the schema first, then build to it.

Retrieve

The HubSpot Contacts Search API (POST /crm/v3/objects/contacts/search) returns contacts matching filter criteria. For peer context, filter on contacts that have already been assessed (the presence of vap_combined_score), sorted by most recent assessment timestamp, limited to five.

{
  "filterGroups": [{
    "filters": [{
      "propertyName": "vap_combined_score",
      "operator": "HAS_PROPERTY"
    }]
  }],
  "sorts": [{ "propertyName": "vap_score_timestamp", "direction": "DESCENDING" }],
  "properties": ["vap_combined_score", "vap_advisory_path", "vap_ai_confidence", "vap_priority_label"],
  "limit": 5
}

Normalize

The five retrieved contacts are not injected as-is. The Normalize step distills them into a single summary object with a fixed schema:

{
  "peer_count": 5,
  "score_range": { "min": 11, "max": 28 },
  "advisory_path_distribution": {
    "standard_review": 3,
    "expedited_review": 1,
    "decline": 1
  },
  "mean_confidence": 0.74,
  "modal_priority_label": "Warm"
}

This object is small, schema-defined, and purpose-built for the assessment prompt. The AI locates every field by its name.

Inject

The normalized peer_context object is injected as a named block in the Build Prompt system message:

PEER CONTEXT (last 5 assessed contacts):
{{ JSON.stringify(peer_context, null, 2) }}

Use this as a calibration reference. Do not let peer context override
independent analysis of the current submission.
CautionProduction Risk

Do not inject raw contact records into the prompt. A block of 40 HubSpot fields per contact adds tokens without adding interpretable signal. The AI will parse it, but it will not reliably locate vap_combined_score across five differently-structured records. Normalize to a purpose-built schema first.

3.1.4 Context Window Discipline

Context Window Discipline

Every LLM has a context window the maximum number of tokens it can process in a single call. Adding retrieval context consumes tokens. The context window is a budget to spend deliberately, not a space to fill.

Context Component Approximate Tokens Notes
System prompt (advisory instructions) 300–500 Fixed per prompt version
Current submission data 150–300 Varies by form length
Peer context (normalized, 5 contacts) 100–150 Bounded by normalization
Output format instruction 50–100 Fixed
Total 600–1,050 Well within GPT-4o-mini 128k limit

The risk is not running out of space; it is injecting context that costs tokens without improving assessment quality.

TipDesign Practice

Normalized peer context for five contacts costs approximately 100–150 additional input tokens per call. At GPT-4o-mini pricing, this is under $0.001 per execution effectively zero marginal cost. Context discipline is about quality, not token budget.

3.1.5 Context Quality

Context Quality

More context is not better context. Quality is determined by three criteria:

Criterion Passing Failing
Schema-defined Named fields with predictable types Raw JSON, free text, variably-structured records
Purpose-specific Only signals the AI can use in the assessment General contact history, email logs, note fields
Bounded Fixed maximum size regardless of data volume Unbounded lists that grow with contact history

Context types suited to advisory assessment: - Peer score distributions (normalized, bounded) - Engagement type base rates from the current pipeline - Firmographic signals in structured schema (Chapter 3.2)

Context types not suited to advisory assessment: - Raw contact property dumps - Free-text note fields - Email interaction history

CautionProduction Risk

Injecting unstructured context into a structured advisory prompt produces outputs that are difficult to trace. If the AI’s advisory path shifts after adding context, you must be able to determine whether the shift was caused by the new context or by output variance. Schema-constrained context makes this traceable; unstructured context does not.

Reference Diagrams

Figure 3.1.1 Single-Call vs. Multi-Context Call Pattern

Figure 33.1 shows the structural difference between the Part II single-context call and the Part III.1 multi-context call. The three-node AI triplet is identical in both; only the input to Build Prompt changes.

%%{init:{"theme":"base","themeVariables":{"primaryColor":"#eef2ff","primaryTextColor":"#1e1b4b","primaryBorderColor":"#6366f1","lineColor":"#6366f1","clusterBkg":"#f8f9ff","clusterBorder":"#6366f1","titleColor":"#1e1b4b","edgeLabelBackground":"#f6f4ef","fontFamily":"system-ui,sans-serif","fontSize":"13px"}}}%%

flowchart LR
    subgraph P2["Phase 5 Single-Context"]
        direction TB
        A1["Webhook Trigger"]:::trigger --> B1["Build Prompt (current data only)"]:::process
        B1 --> C1["HTTP Request (LLM)"]:::process
        C1 --> D1["Parse Response"]:::process
    end

    subgraph P3["Phase 6.1 Multi-Context"]
        direction TB
        A2["Webhook Trigger"]:::trigger --> R["Retrieve HubSpot Search API"]:::process
        R --> N["Normalize Context → peer_context schema"]:::process
        N --> B2["Build Prompt current data + peer_context"]:::process
        B2 --> C2["HTTP Request (LLM)"]:::process
        C2 --> D2["Parse Response"]:::process
    end

    classDef shared fill:#2d6a9f,color:#fff,stroke:#1a4f7a
    classDef trigger  fill:#dcfce7,stroke:#16a34a,color:#14532d,font-weight:600
    classDef process  fill:#eef2ff,stroke:#6366f1,color:#1e1b4b
    classDef decision fill:#fef9c3,stroke:#ca8a04,color:#78350f,font-weight:600
    classDef success  fill:#d1fae5,stroke:#059669,color:#064e3b,font-weight:700
    classDef fallback fill:#fee2e2,stroke:#dc2626,color:#7f1d1d
Figure 33.1: Single-Call vs. Multi-Context Call Pattern. Single-Call vs. Multi-Context Call Pattern. Left: Part II pattern raw submission payload enters Build Prompt directly. Right: Part III.1 pattern Retrieve and Normalize Context nodes run before Build Prompt, adding a peer_context field. HTTP Request and Parse Response are identical in both.

Practical Exercise 3.1 Retrieval-Augmented Advisory Call

Business Scenario

Vantage Advisory Partners has completed its first quarter on the Part II platform. The advisors have noticed that contacts with similar intake forms are sometimes scored differently depending on who submitted them. The assessment has no frame of reference each contact is evaluated in isolation. Before extending the platform further, the assessment call needs access to what the system already knows.

The Problem

Every advisory AI call assembles its prompt from the current submission alone. The model cannot see whether this contact’s score is high or low relative to the last five contacts it assessed. Recommendations that are locally correct may be systematically miscalibrated across the population.

The Architectural Solution

Add a retrieval stage before Build Prompt. The Retrieve node calls the HubSpot Contacts Search API and fetches the five most recently scored contacts. The Normalize Context node distills those five records into a fixed-schema peer_context object. Build Prompt injects that object alongside the current submission.

Updated Workflow

Figure 33.2 shows the updated seven-stage workflow with the Retrieve and Normalize Context nodes inserted before Build Prompt.

%%{init:{"theme":"base","themeVariables":{"primaryColor":"#eef2ff","primaryTextColor":"#1e1b4b","primaryBorderColor":"#6366f1","lineColor":"#6366f1","clusterBkg":"#f8f9ff","clusterBorder":"#6366f1","titleColor":"#1e1b4b","edgeLabelBackground":"#f6f4ef","fontFamily":"system-ui,sans-serif","fontSize":"13px"}}}%%

flowchart TD
    A["Webhook Trigger (raw payload)"]:::trigger --> B["Retrieve Peer Contacts (HubSpot Search API)"]:::process
    B --> C["Normalize Context (→ peer_context schema)"]:::process
    C --> D["Build Prompt (current data + peer_context)"]:::process
    D --> E["HTTP Request (LLM)"]:::process
    E --> F["Parse Response"]:::process
    F --> G["Route + Store (write p6_ properties)"]:::process
    classDef trigger  fill:#dcfce7,stroke:#16a34a,color:#14532d,font-weight:600
    classDef process  fill:#eef2ff,stroke:#6366f1,color:#1e1b4b
    classDef decision fill:#fef9c3,stroke:#ca8a04,color:#78350f,font-weight:600
    classDef success  fill:#d1fae5,stroke:#059669,color:#064e3b,font-weight:700
    classDef fallback fill:#fee2e2,stroke:#dc2626,color:#7f1d1d
Figure 33.2: Retrieval-Augmented Seven-Stage Workflow. Seven-stage retrieval-augmented workflow for Chapter 3.1. Retrieve Peer Contacts and Normalize Context run before Build Prompt, injecting a peer_context object alongside the current submission so the AI call has cross-contact reference during scoring.

Step 1 Add the Retrieve Node

Purpose

The Retrieve node is the first stage of the multi-context pattern. It fetches a bounded, recently-assessed peer set from HubSpot before the prompt is assembled. Without this node, the AI call operates in isolation it knows nothing about how similar contacts have been evaluated. This step is what transforms a single-context advisory call into a retrieval-augmented one.

Operation Summary

Property Value
Node Type HTTP Request
Method POST
Endpoint /crm/v3/objects/contacts/search
Primary Function Fetch the five most recently assessed peer contacts
Output Array of up to five contact records with scoring properties

Request Payload

{
  "filterGroups": [{
    "filters": [{
      "propertyName": "vap_combined_score",
      "operator": "HAS_PROPERTY"
    }]
  }],
  "sorts": [{ "propertyName": "vap_score_timestamp", "direction": "DESCENDING" }],
  "properties": ["vap_combined_score", "vap_advisory_path", "vap_ai_confidence", "vap_priority_label"],
  "limit": 5
}

The filter HAS_PROPERTY on vap_combined_score restricts results to contacts that have already been through at least one AI assessment. The DESCENDING sort on vap_score_timestamp ensures you retrieve the most recently assessed contacts the ones most representative of current scoring behavior. Requesting only four properties keeps the response payload small; the normalization step in Step 2 distills these four fields into the compact peer_context object.

Response Processing

const results = $json.results; // Array of up to 5 contact objects
// Each result has: { id, properties: { vap_combined_score, vap_advisory_path, vap_ai_confidence, vap_priority_label } }

The response results array is consumed directly by the Normalize Context node in Step 2. If results is empty because no contacts have been assessed yet the normalization guard must handle this gracefully. Do not attempt to access results[0] before checking results.length.

Output Table

Output Description
results Array of contact objects, each with a properties sub-object
total Total count of contacts matching the filter (not limited to 5)
paging Cursor for next page (not used; limit is fixed at 5)

Engineering Rationale

NoteEngineering Rationale

Position this node immediately after the Webhook trigger and before Build Prompt. Any other position including after Build Prompt defeats the purpose: the prompt must be assembled with the peer context present, not after it. If HubSpot returns a 429 (rate limit) or 503 (service degradation) response, add an On Error path that sets peer_context: { peer_count: 0 } and allows the pipeline to continue with reduced context rather than halting. This fallback path is required before production deployment; see the Production Consideration note at the end of Practical 3.1.

Step 2 Add the Normalize Context Node

Purpose

Raw HubSpot contact records cannot be injected into a prompt directly. Five records at 40 properties each add hundreds of tokens and produce an uninterpretable blob the AI cannot reliably reason over. The Normalize Context node distills five raw records into a single schema-defined peer_context object the compact, purpose-built summary the Build Prompt node in Step 3 requires.

Operation Summary

Property Value
Node Type Code (JavaScript)
Primary Function Aggregate five raw peer contact records into peer_context
Input $json.results array from Step 1
Output peer_context object with five computed fields

Implementation Logic

const results = $input.first().json.results;

// Guard: handle empty results before any access
if (!results || results.length === 0) {
  return [{ json: { peer_context: { peer_count: 0 } } }];
}

const scores = results.map(r => parseFloat(r.properties.vap_combined_score)).filter(s => !isNaN(s));
const paths = results.map(r => r.properties.vap_advisory_path).filter(Boolean);
const confidences = results.map(r => parseFloat(r.properties.vap_ai_confidence)).filter(c => !isNaN(c));
const priorityLabels = results.map(r => r.properties.vap_priority_label).filter(Boolean);

// Modal priority label: most frequently occurring value
const labelCounts = priorityLabels.reduce((acc, l) => { acc[l] = (acc[l] || 0) + 1; return acc; }, {});
const modalLabel = Object.entries(labelCounts).sort((a, b) => b[1] - a[1])[0]?.[0] ?? null;

// Path distribution: count by advisory path value
const pathDistribution = paths.reduce((acc, p) => { acc[p] = (acc[p] || 0) + 1; return acc; }, {});

return [{
  json: {
    peer_context: {
      peer_count: results.length,
      score_range: { min: Math.min(...scores), max: Math.max(...scores) },
      advisory_path_distribution: pathDistribution,
      mean_confidence: confidences.length > 0
        ? Math.round((confidences.reduce((a, b) => a + b, 0) / confidences.length) * 100) / 100
        : null,
      modal_priority_label: modalLabel
    }
  }
}];

peer_count: 0 is the explicit zero-result guard it signals to Build Prompt that no peer data is available. score_range provides a calibration bracket: if the current contact’s score falls outside min–max, it is an outlier relative to recent activity. advisory_path_distribution shows what proportion of recent contacts reached each advisory outcome, giving the AI a base rate for each path. mean_confidence indicates whether recent assessments were generally high or low confidence useful when the current submission is ambiguous. modal_priority_label is the most common priority assigned recently; it anchors expectations for the current call.

Output Table

Output Description
peer_context.peer_count Number of peer records retrieved (0–5)
peer_context.score_range Object with min and max of peer combined scores
peer_context.advisory_path_distribution Object mapping each advisory path to count
peer_context.mean_confidence Mean AI confidence across peers (null if no data)
peer_context.modal_priority_label Most frequent priority label among peers

Production Considerations

CautionProduction Risk

Never skip the zero-result guard. On a freshly deployed platform or after a test data reset, results.length will be zero. Code that accesses results[0] without checking length throws a runtime error and halts the workflow. The guard must run before any array access not at the end as a catch.

Step 3 Update the Build Prompt Node

Purpose

The Build Prompt node assembles the full advisory prompt sent to the AI. This step adds the peer_context block as a named section in the system message between the role instruction and the current submission fields. The AI uses it as a calibration reference: knowing the distribution of recent scores and paths makes the current contact’s assessment more defensible against the population baseline.

Operation Summary

Property Value
Node Type Code (JavaScript) or Set node
Primary Function Assemble the enriched advisory prompt from current data + peer context
Input Current submission fields + peer_context from Step 2
Output prompt_payload object for the HTTP Request (LLM) node

Implementation Logic

const peerContext = $('Normalize Context').first().json.peer_context;
const submission = $('Webhook').first().json;

const systemMessage = `
You are an advisory assessment specialist for Vantage Advisory Partners.

PEER CONTEXT (last ${peerContext.peer_count} assessed contacts):
${JSON.stringify(peerContext, null, 2)}

Use this as a calibration reference. Do not let peer context override
independent analysis of the current submission. If peer_count is 0,
no peer data is available assess the submission independently.

CURRENT SUBMISSION:
Inquiry text: ${submission.inquiry_text}
Engagement type: ${submission.engagement_type}
Company: ${submission.company_name}
Source: ${submission.source}
`.trim();

The peer_context block is injected as a named, clearly delimited section so the AI can locate it by label. The calibration instruction is explicit: peer context informs calibration but does not override independent analysis. The peer_count: 0 case is handled in the instruction text the AI is told what to do when no peers are available, preventing undefined behavior.

Output Table

Output Description
prompt_payload Full prompt object with system and user messages
model LLM model identifier (e.g., gpt-4o-mini)
max_tokens Token limit for the response
temperature Sampling temperature (recommend 0.2 for advisory tasks)

Production Considerations

TipDesign Practice

Keep the peer_context block before the current submission fields in the system message, not after. The AI’s attention is stronger at the beginning of the context placing calibration data before the specific submission ensures the AI reads the reference frame before applying it to the specific case.

Step 4 Write the Bootstrap Properties

Purpose

After Parse Response, every p6_ audit property must be written to the HubSpot Contact before the workflow exits. These properties are the instrumentation layer that Chapter 3.5 builds observability metrics from. Writing them after every AI call not just after successful ones is what produces a complete dataset for aggregate analysis.

Operation Summary

Property Value
Node Type HTTP Request
Method PATCH
Endpoint /crm/v3/objects/contacts/{contactId}
Primary Function Write four p6_ audit properties to the Contact record
Output Updated contact object (used only for error detection)

Request Payload

{
  "properties": {
    "p6_last_execution_source": "ai",
    "p6_last_confidence_score": "{{ $('Parse Response').first().json.confidence_score }}",
    "p6_last_advisory_path": "{{ $('Parse Response').first().json.advisory_path }}",
    "p6_agent_call_count": "1"
  }
}

p6_last_execution_source is "ai" for any execution where the AI call completed. It is "rule_fallback" for executions where the AI was unavailable or the parse failed. p6_last_confidence_score and p6_last_advisory_path come directly from Parse Response they record exactly what the AI produced for this execution. p6_agent_call_count is fixed at 1 throughout this practical because the multi-context retrieval adds richness to the input but does not add additional AI calls. This field transitions above 1 only in Chapter 3.3.

Output Table

Output Description
p6_last_execution_source "ai" or "rule_fallback"
p6_last_confidence_score Float 0.00–1.00 from AI output
p6_last_advisory_path Advisory path string matching VAP enum values
p6_agent_call_count Integer; 1 throughout Practical 3.1

Engineering Rationale

NoteEngineering Rationale

Write these properties unconditionally do not gate the write on a confidence threshold or advisory path value. The purpose of these properties is to record what the AI actually produced, including low-confidence and fallback results. A record that only captures high-confidence outputs is not an observability layer; it is a filtered log that hides the most operationally important cases.

Step 5 Run Six Test Payloads and Compare

Purpose

This step validates that the multi-context retrieval pattern produces measurably different results from the Part II single-context baseline established in Practical 3.0. Running the same six test contacts through the updated workflow produces a direct before/after comparison that demonstrates the observable effect of peer context injection.

Operation Summary

Property Value
Primary Function Execute all six Part II Capstone test contacts and record outputs
Input Six test contact payloads from Deliverable 4
Output Comparison table: advisory path and confidence with and without peer context

Implementation Logic

// After each test contact is processed, record two values from HubSpot:
const result = {
  contact_id: "<hubspot_contact_id>",
  vap_advisory_path: "<from HubSpot after workflow runs>",
  vap_ai_confidence: <float from HubSpot after workflow runs>,
  p6_agent_call_count: 1,
  peer_context_available: <true if peer_count > 0, false if peer_count === 0>
};

For each of the six contacts, record vap_advisory_path and vap_ai_confidence as written by this workflow. Compare against the baseline values from 3.0.6 Observability Bootstrap. Note any contacts where the advisory path changed or the confidence score shifted by more than 0.05. A path change with peer context present where the peer distribution showed a different modal path than the one the single-context call produced is evidence that the retrieval step is affecting the assessment. This comparison table is Deliverable Item 3 for this practical.

Output Table

Output Description
contact_id HubSpot Contact ID
phase2_advisory_path Path value from Part II baseline run
phase3_advisory_path Path value from this practical’s run
phase2_confidence Confidence score from Part II baseline
phase3_confidence Confidence score from this practical’s run
path_changed Boolean did advisory path differ?
confidence_delta Signed float how much did confidence change?

Production Considerations

TipDesign Practice

Run the six contacts in order: run the first, let the workflow write to HubSpot, then run the second. Do not run them in parallel. The Retrieve node fetches peers sorted by most recent vap_score_timestamp if contacts are processed simultaneously, the peer context for each overlaps with partially-processed contacts from the same batch. Sequential execution ensures each contact’s peer context reflects fully processed prior contacts.

ImportantCritical Requirement

If Normalize Context errors on the first run, the HubSpot Search API likely returned an empty results array no contacts have vap_combined_score set yet. Add the zero-result guard first, then test with the six capstone contacts to populate scores before testing the retrieval path with live data.

Production Consideration

This practical implements retrieval and normalization without error handling on the Retrieve stage. In production, the HubSpot Search API can return a 429 (rate limit) or 503 (service degradation) response. Chapter 3.2 formalizes stage-level error handling add an On Error path from the Retrieve node that sets peer_context: { peer_count: 0 } and allows the pipeline to continue with reduced context rather than halting.

Deliverable: Modified Workflow A with Retrieve and Normalize Context stages. Six test payloads run. Comparison table: advisory path and confidence with and without peer context. Bootstrap properties written.

Estimated time: 2–3 hours.

Discussion Questions

  1. The peer_context object includes modal_priority_label. Under what conditions would this field help the AI produce a better assessment? Under what conditions could it cause incorrect anchoring on the peer distribution?

  2. The Normalize Context node produces a fixed-schema object from variable raw HubSpot data. If the team adds a new contact scoring property in Chapter 3.6, what changes in the normalization logic and what does not change?

  3. At what point would it make sense to retrieve peers by engagement type rather than by recency? What change to the HubSpot Search API filter would implement this, and what tradeoff does it introduce?

Chapter Summary

The retrieval-augmented advisory pattern adds two nodes before Build Prompt Retrieve and Normalize Context that produce a schema-defined peer_context object injected into the prompt alongside current submission data. The three-node AI triplet, output contract, and downstream routing are unchanged. Only the prompt input is richer.

Context quality matters more than context volume. A normalized, bounded, schema-defined summary of peer scoring distributions is context. Raw contact records, free-text notes, and unbounded lists are noise. A system with structured peer context can explain why a recommendation changed. A system with unstructured context cannot.

Key Principle

Context must be schema-defined, purpose-specific, and bounded before injection into a prompt. The retrieval-augmented pattern is a data preparation discipline, not an architecture change the three-node AI triplet is unchanged.

Transition to Chapter 3.2

Chapter 3.1 added retrieval context to a single AI call. The Retrieve → Normalize Context → Build Prompt sequence is an informal pipeline: three nodes transforming data sequentially with no formal schema enforcement at the boundaries between them.

Chapter 3.2 formalizes this pattern. It names the five canonical AI pipeline stages, defines what a schema contract at each stage boundary means, introduces stage-level error handling, and adds an external enrichment stage (using a mock API) that injects firmographic signals the AI can use as additional assessment context. The pipeline architecture from Chapter 3.2 is the structural framework Chapter 3.3’s multi-agent systems instantiate.

Key Takeaways

  1. The single-context limit means every Part II advisory AI call is assembled from the current execution’s data alone no peer context, no historical patterns, no external signals.
  2. The retrieval-augmented advisory pattern adds two nodes before Build Prompt: Retrieve (HubSpot Contacts Search API) and Normalize Context (Code node). The three-node AI triplet is unchanged.
  3. Context must be schema-defined, purpose-specific, and bounded. Raw contact records are not context; a normalized peer scoring distribution is.
  4. The peer_context object must have a fixed schema regardless of how many peer contacts were retrieved. Handle peer_count: 0 explicitly.
  5. Context window cost for normalized peer context is approximately 100–150 tokens negligible. Context discipline is about quality, not size.
  6. After each AI call, write all four p6_ bootstrap properties. Set p6_agent_call_count to 1 this chapter is still single-call architecture.

End of Chapter 3.1 Multi-Context AI Systems