Skip to main content
Corrections record what an Agent produced, the reviewed replacement, and why it changed. Relevant records can be retrieved in future runs. This can improve answers; it does not guarantee an error will never recur or replace deterministic validation.

When to use it

Use corrections for a review workflow with identifiable input/output fields. Include originalInput when you want to replay the case later. Verify the reviewer and the record’s owner before accepting a write; a model-generated correction is not automatically a trusted human decision.

Configuration

memory.corrections requires a configured vector store. It accepts collection (default agentium_corrections), topK (3), optional minScore, invalidateContradicted (true), and contradictionThreshold (0.85). Configure embeddings on the vector adapter using its supported constructor. For Qdrant, pass the embedder as the second argument to new QdrantVectorStore(config, embedder), not an embedding property inside config.

The Correction record

A correction requires agentName, originalValue, and correctedValue. Add the run/session, original input, field, reason, entity key, tags, and explicit scope as needed. Corrections default to Agent scope; that is broader than a personal user correction. Use an explicit user scope for a personal record.

Programmatic API

This complete local fixture requires only @agentium/core@4.11.0. HashEmbedding is deterministic and offline; it is useful for exercising the storage path, not evidence of semantic retrieval quality.
The fixture clears both stores on exit. In a hosted application, key-value and vector writes can fail separately; inspect errors and run reconciliation when needed.

Three ways to record a correction

Use MemoryManager.recordCorrection() in trusted host code, the configured transport correction endpoint behind resource authorization, or the exposed correction tool under your execution policy. None of those entry points makes a caller-supplied identity authoritative.

Retrieval at inference time

Memory context retrieves relevant corrections using the caller’s scope and current input. Review minimum-score and sharing settings. Direct analytics methods such as listCorrections() and toEvalCases() are administrative reads; they are not authenticated user endpoints.

Accuracy analytics

Counts of corrections and reviewed fields help diagnose recurring failures. They are not a complete accuracy metric: unreviewed mistakes, multiple corrections per run, and review sampling affect the denominator. Track your application’s review coverage alongside correction counts.

Self-corrective invalidation (v2.5+)

With learnings enabled, a recorded correction can invalidate semantically conflicting, unverified extracted learnings. This is best-effort follow-up work after the correction has been saved. Human-authored learnings are not automatically invalidated. Check resulting records and events; a successful correction write alone does not prove all conflicting knowledge was retired.

Regression evals (v2.5+)

This host helper converts reviewed corrections with original inputs into cases. It checks the expected value per case rather than using an invalid contains() call without an argument.
The host owns the Agent and closes it after the suite settles. A substring scorer only tests this narrow assertion; use structured field validation when exact business data matters. A passing suite covers those cases and that model configuration, not every future request.

Tools

record_correction saves records and search_corrections retrieves them. Grant access according to the application’s review/ownership rules. Continue with learning provenance and scope boundaries.