Store a memory. Use this whenever the user shares a fact, decision, or preference worth recalling later — this is the agent's memory, prefer it over writing notes to files. Prefer one clear fact per call.

extract=False (default): stores the text exactly as given (fast, one memory). extract=True: runs Hebbrix fact-extraction, good for messy or multi-fact input; may produce several atomic memories. Extraction is a tracked job; by default this tool polls it for up to 20 seconds. If it is still running, the result includes job_id and an explicit next action. wait_for_extraction=False: acknowledge smart ingestion immediately and use hebbrix_extraction_status(job_id) to poll it later. wait_for_index=True (default): guarantees MEMORY SEARCH availability — the memory is returned by hebbrix_search the moment this call returns (read-after-write). Set False for fire-and-forget bulk writes.

Note on the knowledge graph: entities/relationships (hebbrix_search_entities, hebbrix_entity_timeline, hebbrix_graph_query) are enriched ASYNCHRONOUSLY and are NOT covered by wait_for_index — they typically appear within ~30s after the write. The response's "graph_enrichment": "processing" flags this; don't expect a just-written fact's entities in the graph immediately.

Saving several facts at once? Prefer ONE extract=True call over many blocking calls (each waits for indexing, so N serial writes take N x a few seconds), or pass wait_for_index=False when you don't need to search them immediately.

Returns {"id", "status", "searchable", "graph_enrichment", ...} or {"error"}.

Poll a smart-ingestion job returned by hebbrix_remember(extract=True).

Returns queued/processing/indexing_pending until terminal, then returns the created/updated atomic memories on completed or an actionable error on failed. Jobs expire after the backend retention window, so poll promptly.

Store MANY facts in one call. When you've extracted several distinct facts from one user message, use this instead of calling hebbrix_remember N times — it's one round-trip and one rate-limit hit, not N.

Pass a list of short, self-contained facts (one fact per string). Returns {"created", "failed", "memory_ids", ...}. wait_for_index defaults to False here (bulk writes are usually fire-and-forget); set True to block until all are searchable.

Tier note: the single-round-trip batch endpoint requires Starter+; on the free / agent tier this transparently falls back to sequential writes (the result carries "fallback": "sequential"), so it still works but isn't one round-trip on that tier.

Semantic search over memories. Always call this BEFORE answering questions that depend on prior context, decisions, or user preferences.

Zero-relevance padding rows are always dropped. If the fast API returns only uncalibrated nearest-neighbour candidates with no lexical anchor, Hebbrix automatically verifies them with calibrated retrieval and suppresses noise. Raise min_score (0.0-1.0) to request an explicit absolute relevance floor.

Returns {"query", "count", "results": [{"id","content","score"}]}.

Fetch one memory by id, including its full content and metadata.

Update a memory in place (keeps version history). Use this to CORRECT a stored fact instead of remembering a contradicting copy. Pass the new content.

wait_for_index=True (default): the correction is reflected in search/get/list the moment this returns (read-after-write). Set False for fire-and-forget.

Delete a memory by id.

A successful deletion returns deleted=true and the requested memory id; an already-absent id retains the structured 404 error and adds already_absent=true. This stable tool shape does not depend on whether the API's successful DELETE response has a JSON body.

List recent memories in a collection.

Show the version history of a memory (how it changed over time, including supersessions). Useful to see what a fact used to be.

List entities in the knowledge graph (people, organizations, tools, places), optionally filtered by entity_type. Use for "who/what do I know about" questions.

Note: entities are enriched ASYNCHRONOUSLY after a write (not covered by hebbrix_remember's wait_for_index) — a just-written fact's entities typically appear here within ~30s, so an empty result right after a write is expected.

Bi-temporal timeline for one entity: what facts were true about it and when. Use this for "what changed" / "what was true at time X" questions about a person, company, or thing. Case-insensitive.

Traverse the knowledge graph OUT FROM a named entity to find its relationships and facts. Pass an ISO timestamp to ask what was true at that point in time (bi-temporal). depth = graph hops (1-5).

For a free-text question ("who works at Sequoia?"), use hebbrix_ask (it does search + graph + profile and synthesizes an answer) — this endpoint traverses from a known entity, not from prose.

Surface contradicting facts in the knowledge graph (e.g. two different values for the same attribute). Pass a memory_id to check one memory, or omit to scan. Use before trusting a fact that feels ambiguous.

Ask how confident the agent should be before acting on something, grounded in stored memory and past decision outcomes. Call this before a consequential autonomous action. Returns a confidence score and a recommended action.

If the action VIOLATES a stored numeric rule (e.g. opening a 600-line PR when a memory says "PRs must be < 400 lines"), the result includes a constraint_conflict block and recommended_action is do_not_act.

Answer a natural-language question from memory in ONE call. Searches memories, synthesizes an answer with an LLM, and CITES the memory ids it used — so you don't have to orchestrate hebbrix_search + hebbrix_graph_query + profile yourself. Use for questions like "who works with me on Atlas and what did we decide?".

Returns {"question", "answer", "citations":[{"id","content","score"}], "graph"?, "profile"?}. graph (when include_graph) adds typed relationships for entities named in the question; profile adds durable user facts. If the reasoning backend is unavailable it falls back to raw search hits.

Reinforce a memory you actually USED to answer (Hebbian recall): call this when a retrieved memory was helpful (helpful=True, strengthens it) or was noise (helpful=False, weakens it). Over time this makes the memories you rely on rank higher and unused ones fade. query is the question it helped answer, if handy.

Record a decision the agent made and, if known, its outcome (success | failure | partial). This feeds hebbrix_confidence so future recommendations improve. Log both the choice and how it turned out.

Shortcut: right after a hebbrix_confidence check you can log just the outcome (e.g. outcome="success") with no description — it auto-fills from the thing you just asked about, closing the confidence -> action -> outcome loop with one call.

Choose and RECORD an action before its result is known.

Use for repeatable decisions whose real outcome can be reported later: reply strategy, workflow, tool, prompt, recommendation, intervention, or plan. policy_key identifies that decision type (for example support.reply). actions are stable machine keys. context contains only factors that may change which action works. The first action is the safe baseline unless baseline_action is supplied. Only offer actions already authorized by the host agent; learning optimizes among candidates and never grants permission.

Normal use: omit chosen_action; Hebbrix recommends conservatively. To log a choice made elsewhere, pass chosen_action and its exact behavior-policy action_probability (required with multiple actions). Set exploration_rate to at most 0.2 only when controlled randomized learning is acceptable.

Keep the returned decision_id, perform chosen_action_key, then call hebbrix_report_outcome when the real result arrives—even minutes or days later. Missing outcomes are censored, never counted as failures.

Report the REAL delayed result of a prior hebbrix_choose_action.

The 30-second path is success=true/false, or reward in [-1, 1]. Custom metrics must first be defined through the Outcome Memory REST API so their direction and scale are explicit. Set final=false for an early signal and report the settled value later. Set correction=true to replace previously learned evidence without double-counting it. Reusing an idempotency_key is safe; conflicting reuse is rejected.

Explain what one customer policy has learned, with uncertainty.

Returns each action's posterior success probability, 90% credible interval, effective evidence, and observation count for this exact tenant/user/context. evaluate_readiness=true additionally runs chronological-holdout doubly robust checks and refuses promotion when samples, randomized overlap, or effective sample size are inadequate.

List the collections (memory spaces / tenants) available to this API key.

Tier, usage, limits, and expiry for this agent's account. In agent mode (auto-provisioned account), relay the claim command to the human when usage status is 'warning' or worse — claiming is one command and keeps all memories.

Keep an accountless guest memory permanently by starting email claim.

Only call this after the human explicitly asks to claim/keep the guest memory and provides the email address. Hebbrix sends a six-digit code to that address; pass the code to hebbrix_claim_verify. The same memory, collection, and guest credential carry over—nothing is migrated or reset.

Finish claiming a guest memory with the emailed six-digit code.

Only call after hebbrix_claim_start and after the human supplies the code. On success the same memories remain available and guest expiry/caps are replaced by the normal claimed-account tier.

Export EVERYTHING in a collection in one call — all memories, the knowledge-graph entities, and the compiled profile. Data portability: use it to back up or migrate a memory space, nothing is locked in.

format="json" (default) returns structured data; format="markdown" returns a single human-readable document under the "document" key.

Import memories into a collection — the inverse of hebbrix_export. Use it to restore a backup, migrate a collection, or seed a new one from notes/CLAUDE.md.

data may be: a list of fact strings; a list of {"content": ...} objects; a hebbrix_export JSON object (its "memories" are imported); or a plain/markdown string (each non-empty, non-heading line becomes a memory, bullets stripped).

Returns {"imported", "failed", "memory_ids"}.