- Runtime ingestion feeds content in as it is generated during live agent interactions, one turn at a time.
- Bootstrap ingestion loads pre-existing data in bulk: historical conversations, documentation, migrations from another system.
The ingestion pipeline
Every document you send, via either path, flows through the same stages before it becomes a memory you can retrieve:Categorization
document_type and selects the appropriate extraction logic. A chat conversation, an email, and a PDF are each processed differently.Extraction
Chunking
Entity resolution
Storage
Ingestion modes
A single parameter,mode, controls how deeply the extraction stage analyzes each document. The same two modes are available on both ingestion paths.
- fast
- long-range
Document types
document_type tells the pipeline what kind of content it is looking at and which extraction logic to apply. Both paths accept the same set:
Scoping every document
user_id and customer_id determine where a memory is stored in the scope hierarchy, which in turn controls who can retrieve it later. On B2C agents, customer_id is resolved automatically and you only pass user_id; on B2B agents you pass both. The same scoping rules apply on both ingestion paths. See Memory Scopes for the full hierarchy.
Runtime ingestion
Runtime ingestion feeds content into Synap as it is generated during live agent interactions. This is the primary ingestion path for most applications. After each conversation turn (or at the end of a conversation) your application callssdk.memories.create() to send the turn through the pipeline. The call returns immediately, so your agent never waits for ingestion before responding to the user; fast is the natural default here.
Your agent receives a user message
Your agent retrieves context from Synap
Your agent generates and delivers a response
Your agent ingests the turn
sdk.memories.create(). This returns immediately and does not block the user experience.Synap processes in the background
The SDK call
Fitting it into the agent loop
Include speaker labels in conversation content
Include speaker labels in conversation content
User: and Assistant: labels. The pipeline uses them to identify who said what, which is critical for accurate preference detection and entity attribution.Use consistent user and customer IDs
Use consistent user and customer IDs
user_id (and customer_id on B2B) consistent across all calls for the same user and organization. Inconsistent IDs fragment the store into isolated pockets of context that cannot be retrieved together. Derive them from your auth system.Ingest after the response is delivered
Ingest after the response is delivered
Handle ingestion errors gracefully
Handle ingestion errors gracefully
Set document_id for idempotent retries
Set document_id for idempotent retries
document_id to prevent duplicate memories. Derive it from your conversation or message identifier.Bootstrap ingestion
Bootstrap ingestion loads pre-existing data into Synap in bulk. Before your agent goes live (or alongside live operation) you often need to seed it with historical context: past conversations, product documentation, knowledge base articles, customer records. You callsdk.memories.batch_create() with many documents at once. Because this data is historical and processed in the background, long-range is the natural default.
Use bootstrap ingestion whenever you need to load a significant volume of existing data:
- Migrating from another system: a custom memory solution, a competing product, or an in-house knowledge base.
- Loading historical conversations: past chat logs, support tickets, or email threads.
- Seeding product documentation: docs, FAQs, help center articles, internal wikis.
- Backfilling customer data: CRM records, customer profiles, organizational context.
- Populating shared knowledge: company policies, SOPs, reference material at customer or client scope.
BOOTSTRAP priority in the ingestion queue, which processes below real-time but above maintenance tasks. Your live agent keeps operating normally while historical data is processed. You do not need to finish bootstrapping before going live. The two paths can run simultaneously without competing for resources.The batch ingestion method
sdk.memories.batch_create() accepts multiple documents in a single call, reducing per-call overhead and enabling server-side throughput optimizations. Each document is a CreateMemoryRequest supporting the same fields as sdk.memories.create().
CreateMemoryRequest supports the same fields as a single create call, including document_id for idempotency and document_created_at for temporal accuracy.
Key considerations
Preserve original timestamps
document_created_at to the document’s original creation time. Without it, Synap defaults to the ingestion time, which distorts temporal ordering. If a user later asks “What did we discuss last March?”, accurate timestamps are essential for correct retrieval.Use document IDs for idempotency
document_id to every document, ideally derived from your source system’s primary key (e.g. migration_{source_id}). If a batch is interrupted, you can safely retry it: already-ingested documents are skipped, preventing duplicates and making it easy to trace memories back to their source.Use long-range mode for historical data
long-range (the default for batch) performs deep entity resolution, relationship mapping, and preference detection. The extra processing time is fine for background loads.Validate and organize before loading
Monitor ingestion progress
sdk.memories.status():