Intelligent Context: getting agents to read your documents without hallucinating the answer

Point an agent at a folder of PDFs — policy documents, signed contracts, support transcripts — ask it “does this customer’s contract allow a mid-term downgrade,” and watch it answer with total confidence. The problem is you have no idea whether it read the right clause. It retrieved some chunk of some document, the chunk happened to mention “downgrade,” and the model wrote a fluent paragraph on top of it. Maybe the chunk was the cancellation section of a different customer’s renewal. Maybe the relevant clause got split across two chunks and the agent only saw half. You can’t tell from the answer, because a confident wrong answer and a confident right one look identical.

This is the other grounding problem. We wrote recently about grounding agents on a semantic layer — the fix for agents inventing your metrics, the “what was revenue in the West” failure. That’s the structured half. This is the unstructured half: the 80% of enterprise data that lives in documents, and the naive retrieval-augmented generation most teams bolt on to reach it. Salesforce’s answer, rolled out across 2026 as part of the Data 360 and Agentforce 360 story, is Intelligent Context — and the reason it matters isn’t that it does RAG. Everyone does RAG. It’s that it makes the parts of RAG that silently determine quality — extraction, chunking, retrieval tuning — into something you can see and test before you scale to millions of records. This post is what the pipeline actually is, the decisions inside it that separate a competent document agent from a plausible liar, and where it stops.

Naive RAG is a demo; the failure is in the middle

Retrieval-augmented generation, in one sentence: instead of trusting the model’s training, you search your content for relevant passages and feed them to the model as grounding. The happy path is easy and every vendor demo runs it — upload a doc, ask a question, get an answer that cites the doc. It works in the demo because the demo uses one clean PDF and a question whose answer sits in one paragraph.

Production is not that. Production is a scanned contract where the extraction step mangled a table into word soup, a 90-page handbook where “the answer” is spread across three sections, a support transcript where the useful sentence is buried in a page of pleasantries. The retrieval quality — whether the right passage is the one that reaches the model — is decided by three steps in the middle that nobody demos:

• Extraction: how faithfully text, tables, and structure come out of the source file.
• Chunking: how the extracted text is cut into the segments you embed and retrieve.
• Retrieval: how a question is matched against those segments to pick what the agent sees.

Get any of those wrong and the model is grounding on garbage — but fluently, so the failure is invisible until someone who knows the contract reads the answer. Intelligent Context’s whole reason to exist is that these steps have historically been a black box you configured blind and discovered in production. It turns them into a workspace.

Retrieval is the part of RAG that decides whether the agent is right. It’s also the part every demo skips. If you can’t see which chunk grounded an answer, you’re not running a document agent — you’re running a confident guess with citations.

The workspace: iterate on a handful, then publish to millions

The design idea that makes Intelligent Context more than a config screen is the loop. It’s an AI-powered workspace inside Data 360 where you upload a small sample of representative documents, configure how they’re processed, and then ask questions in an agent chat window to check what actually comes back — do the chunks and vectors retrieve the clause you meant? You tune the parsing and chunking, ask again, watch the retrieval change. When the logic is right on the sample, you publish that configuration to an Unstructured Data Model Object (UDMO) to run across millions of live records.

That order — perfect it on ten documents, then scale — is the opposite of how most teams do RAG, which is “index everything, then discover in production that the chunking was wrong.” Getting the pipeline right on a representative sample before you’ve spent the compute to vectorize the whole corpus is both a quality win and a cost win, and the cost part is not incidental — everything downstream meters.

The pipeline, stage by stage

Under the workspace is a modular processing pipeline, and each stage is independently configurable and — this is the part that matters for hard documents — extensible with your own code. The stages, in order:

1. Extract. Raw text and structure come out of the source: PDFs, Word documents, images via OCR, audio and video transcripts. This is where scanned tables and multi-column layouts go to die if the extractor is naive, and it’s the first place to look when a document agent is confidently wrong — often the answer was never extracted cleanly in the first place.

2. Transform / clean. Noise removal, language normalization, image understanding (OCR and captioning). For documents that don’t yield to the defaults, this stage accepts custom pre-processing logic.

3. Chunk. The extracted text is split into the segments you’ll embed and retrieve. This is the single highest-leverage decision in the whole pipeline (more below).

4. Embed. Each chunk becomes a vector — a numeric representation of its meaning — so that semantically similar chunks sit near each other. Data 360 ships out-of-the-box embedding models and supports custom or external ones.

5. Index. The vectors are stored and organized for fast retrieval. Data 360 provides native keyword, vector, and hybrid indexing.

The data-model vocabulary is worth learning because it shows up in every configuration screen and error message. Your source files land as an Unstructured Data Lake Object (UDLO) — the raw ingested files from S3, Azure Blob, Google Drive, and the like. The processing configuration publishes to a UDMO. And when chunking runs, the segments are stored as Chunk Data Model Objects (CDMOs), which are what the search index actually serves. UDLO in, CDMO out, and the retriever reads the CDMOs.

Chunking is where the quality actually lives

If you take one thing from this piece, take this: chunking strategy is the lever that most determines whether a document agent is trustworthy, and it’s the one teams tune last, if at all. A chunk that’s too big drowns the relevant sentence in irrelevant context and dilutes the embedding. A chunk that’s too small severs a clause from the condition that governs it — you retrieve “customers may downgrade” and miss the very next line, “except during the initial 12-month term.” Same document, opposite answer, and the split decided which one the agent gave.

Data 360 supports more than one strategy, and the choice is document-shaped:

• Semantic chunking cuts on headings and structure — it keeps a section together as a unit. This is what you want for structured documents: contracts with numbered clauses, policy handbooks, anything where the author already organized meaning into sections.
• Window-based chunking works at the paragraph or sentence level with overlap. This fits flatter content — transcripts, free-form notes — where there isn’t clean structure to cut along, and the overlap is what stops a fact from being severed at a boundary.

There is no universal right answer, which is exactly why the workspace’s test-on-a-sample loop matters. You pick a strategy, ask the questions your agent will really face, and look at whether the retrieved chunk contains the whole answer or a truncated version of it. When a document agent is subtly wrong in production, the chunking is the first thing to re-open, every time — long before you reach for a different model.

When the defaults aren’t enough: Code Extension

Some documents don’t yield to any built-in strategy. A messy claims form, a domain-specific report layout, a table that has to be reshaped before it’s chunkable — these need real logic in the pipeline, not a dropdown. That’s what Code Extension is for: a capability that lets you author Python and deploy it into Data 360’s secure compute, so a stage of the pipeline runs your parsing or transformation code instead of the default.

Conceptually, a custom pre-processing function looks like this — illustrative of the shape, not a drop-in:

# Custom pre-processing deployed via Data 360 Code Extension.
# Runs in the transform stage before chunking.
def preprocess(document):
    text = document["extracted_text"]

    # Domain rule: contract clauses are numbered "N.N" — keep each
    # clause and its sub-conditions together so chunking never splits
    # a right from the condition that limits it.
    clauses = split_on_clause_numbers(text)     # e.g. r"^\d+\.\d+\s"

    return [
        {
            "text": clause.body,
            "metadata": {
                "clause_no": clause.number,
                "doc_type": document["metadata"].get("doc_type"),
            },
        }
        for clause in clauses
    ]

The metadata you attach here is not decoration — it’s what lets retrieval filter by document type or clause number later, and it’s often the difference between “search all contracts” and “search this customer’s contract.” Push the domain knowledge into the pipeline once, in code, and every downstream agent inherits it.

Retrieval: hybrid search and the retriever wrapper

Indexing gives you two search modes worth understanding, because picking wrong quietly caps your accuracy. A vector search index matches on semantic similarity — great when the question and the document use different words for the same idea (“cancel” vs. “terminate”). A hybrid search index combines vector similarity and keyword matching, which is what you want the moment exact tokens matter: a product SKU, a policy number, a named entity that a pure-semantic search will happily approximate into the wrong record. For most enterprise document corpora, hybrid is the safer default precisely because real questions mix concepts and exact identifiers.

The agent doesn’t touch the index directly. It goes through a retriever — a wrapper over the search operation that you configure in AI Models to shape and filter what comes back so it’s relevant to your use case. The retriever is then a resource inside a prompt template, which is where grounding actually happens: the template describes how to read the input, call the retriever to find relevant chunks, and generate an answer from that content rather than from the model’s general training. That chain — retriever inside a prompt template, wired to an Agentforce action — is the same grounding plumbing behind every Data 360-backed agent, and it’s why the Atlas reasoning engine’s tendency to be confidently approximate gets bounded here: it reasons over retrieved facts instead of improvising them.

Here’s the shape of that grounding contract, illustratively:

retriever:
  name: contract_clause_retriever
  search_index: contracts_hybrid_idx      # hybrid: semantic + keyword
  max_results: 5
  filters:
    - field: account_id                   # never cross customer boundaries
      operator: equals
      value: "{{input.account_id}}"
    - field: doc_type
      operator: equals
      value: "MSA"
  return_fields: [text, clause_no, source_file]

Note the account_id filter. A document retriever without a hard tenant filter is a data-leak waiting to happen — an agent that can retrieve any customer’s contract when asked about one customer’s is a breach, not a feature. Scope retrieval to the record in front of the agent, server-side, and never rely on the prompt to enforce it.

Where Intelligent Context stops

The honest section, because a document pipeline sold as a cure-all is how teams get burned three months after go-live.

• It rides on extraction, and extraction has a ceiling. If the source is a scanned, skewed, coffee-stained PDF, OCR will fumble it, and no chunking strategy repairs text that came out wrong at stage one. Intelligent Context makes extraction visible and configurable; it doesn’t make a bad scan legible. Audit your worst documents first, not your cleanest.
• A confident wrong retrieval is more dangerous than an empty one. An agent that says “I couldn’t find that in the contract” is safe. An agent that retrieves the wrong clause and paraphrases it with authority is a liability, and the second failure mode looks exactly like success until someone checks. Test with adversarial questions — the ones whose answers sit near a different, wrong-but-similar passage — not just the softballs.
• It meters, and unstructured is not cheap. Vectorization, index storage, and retrieval all consume Data 360 credits, and an agent that fires a retrieval on every turn multiplies that against your conversation volume. Re-embedding a large corpus when you change the chunking strategy is its own bill. This is exactly the kind of structured-and-unstructured grounding cost our credit optimization playbook exists to catch — model it before you index everything, and lean on the sample-first workflow precisely so you’re not re-vectorizing millions of records to fix a chunking mistake.
• It’s retrieval, not reasoning over your whole business. Intelligent Context answers document-shaped questions — “what does this contract say.” It is not the semantic layer that computes “what was net revenue,” and it is not the real-time data graph that grounds an agent on the live record in front of it. Three grounding paths, three question shapes; a serious agent uses the right one per question and doesn’t try to answer “compute this metric” by retrieving a spreadsheet’s alt text.

And the security note that applies to all agent grounding, with force here because a retriever is a query surface an attacker can try to drive from natural language: everything in our least-privilege guide for agents holds. Scope which documents a given agent’s retriever can reach, filter by tenant server-side, and treat retrieved document text — which may itself contain injected instructions — as untrusted input, not as trusted context.

What to actually do

If you’re grounding an agent on documents today with a hand-rolled RAG pipeline — dump files in a bucket, chunk on a fixed token count, hope — Intelligent Context is the consolidation worth doing, and the reason is not that it’s newer plumbing. It’s the workflow. Start with a sample of your hardest documents, not your cleanest ones, because the hard ones are where retrieval breaks and where your real questions live. Configure extraction and chunking, then interrogate the sample with adversarial questions in the workspace until the retrieved chunks actually contain whole answers. Prefer hybrid search when your questions mix concepts and exact identifiers, which in the enterprise is nearly always. Push domain-specific parsing into a Code Extension once so every agent inherits it. Filter every retriever by tenant, server-side. And cost the vectorization before you publish to millions of records, not after.

The difference between a document agent people trust and one they quietly stop using is entirely whether it retrieves the right passage before it speaks. Intelligent Context doesn’t make that automatic — nothing does — but it finally lets you see the retrieval, test it, and fix it before it’s in front of a customer confidently misreading a contract. That visibility is the product. Use it before you scale, not after the invoice and the wrong answer arrive together.

Understanding the basics

What is Intelligent Context in Salesforce Data 360?

Intelligent Context is an AI-powered workspace in Data 360 for grounding agents on unstructured data — PDFs, contracts, transcripts, images. You upload a small sample of documents, configure how they’re extracted, chunked, embedded, and retrieved, and test the results interactively in an agent chat before publishing the configuration to an Unstructured Data Model Object (UDMO) that scales the pipeline across millions of live records. Its purpose is to make the retrieval-quality decisions that usually stay hidden — extraction, chunking, search tuning — visible and testable before you scale.

How is Intelligent Context different from a semantic layer?

They solve different question shapes. A semantic layer (Tableau Semantics in Data 360) governs metrics computed from structured data — “what was net revenue in the West.” Intelligent Context handles documents — “what does this contract say about downgrades” — through retrieval-augmented generation over unstructured files. One computes a number from a governed definition; the other retrieves the right passage from a corpus. A serious agent uses both, plus real-time data graphs for live record context.

Why does chunking matter so much for document agents?

Because chunking decides what the agent can retrieve. Chunks that are too large dilute the relevant sentence; chunks that are too small sever a statement from the condition that qualifies it, so the agent retrieves half an answer and states it with full confidence. Data 360 supports semantic chunking (on headings and structure, for contracts and handbooks) and window-based chunking (on paragraphs or sentences with overlap, for transcripts and flat text). The right choice is document-dependent, which is why Intelligent Context’s test-on-a-sample loop exists — you verify that retrieved chunks contain whole answers before scaling.

---

Grounding an agent on your documents and not sure whether the wrong-clause problem is your extraction, your chunking, or your retrieval? Talk to us — building document agents that retrieve the right passage before they speak, on Data 360, is exactly the work we do.