Skip to main content
← All use cases

The scenario

A plain record waits for fact extraction — an LLM call — before it returns. On a request path that latency belongs somewhere else, and for a bulk import it is unusable.

Step 1 — Queue a single write

Sub-second return instead of waiting on extraction.

Step 2 — Send them in batches

record_batch is always asynchronous. Each item takes the same fields a single write does, scope keys included.

Step 3 — Poll for the outcome

Evals

  1. Queue one write, poll to completion, assert memory_ids is non-empty.
  2. Time a blocking record against a background one. The difference is why this exists.
  3. Import a hundred items and check memory_count against what you sent — extraction can produce more memories than items, and that is expected.

Guardrails

Set timestamp on every backfilled item. Without it, a year of history imported this afternoon all happened this afternoon, and every temporal question becomes unanswerable. There is no way to fix this in bulk afterwards.
  • Throughput is bounded platform-side. A large import takes real time; size your expectations from a measured batch rather than from the accept latency.
  • accepted is not stored. It means the queue took them. The job is what tells you they landed.
  • A failed job needs handling. Poll for failed as well as completed, or a silent import gap looks like a retrieval problem weeks later.

The script

Complete and runnable: background_ingestion.py.