Build with Mubit
Add data
Use helper-first writes for normal Mubit memory flows, and fall back to raw ingest only when you need explicit async ingest control.
Most Mubit integrations should start with client.memory.remember() (or the global mubit.remember() inside a run).
Use raw control.ingest only when you need explicit async ingest behavior, job polling, or bulk payload control. For normal agent memory writes, the helper path is simpler and stays aligned with the current SDK contract.
Recommended write contract
- Keep one stable
run_idper workflow, claim, ticket, or task. - Use
remember()for facts, traces, lessons, rules, handoffs, feedback, and tool artifacts. - Use raw
control.ingestwhen you need explicit async ingestion lifecycle control. - Stamp
agent,kind, and metadata so later diagnose, reflect, and context assembly stay useful.
Helper-first write examples
When raw ingest is still the right choice
Use raw client.raw.invoke("control.ingest", payload) when you need one of these explicitly:
- async job polling through
client.jobs.get(job_id, run_id=...)(anIngestJobwithdone,status,error) - controlled batch writes through
/v2/control/ingestor/v2/control/batch_insert - wire-level debugging of serialized payloads
- compatibility with systems that already generate ingest payload JSON directly
ℹ️Note
control.ingest and control.batch_insert accept at most 1000 items per request; larger requests return 400 (InvalidArgument) — chunk bigger writes.
Failure modes and troubleshooting
| Symptom | Root cause | Fix |
|---|---|---|
| Important memory never shows up later | kind or metadata missing | Tag writes with kind, agent, and useful metadata |
| Helper writes feel too implicit | You need job-level control | Switch that path to raw control.ingest |
| Cross-task contamination | run_id changes per request | Keep one deterministic task/run mapping |
Next steps
- Read with Retrieve data.
- Use the helper catalog at SDK methods.