> ## Documentation Index > Fetch the complete documentation index at: https://agents.nanonets.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # LLM Match Learnings > Read the corrections and confirmations that have been taught to an LLM Match tool. This document covers `llm_match_learnings`, which reads the **learned mappings** behind an [`llm_match`](/docs/tools/llm-match) tool: the corrections and confirmations people have made on past matches, which the matcher then feeds into every later match prompt. It answers questions *about* a matcher rather than performing a match. Use it to check whether a term has already been decided, to see what has been taught about one part of a catalog, or to review what a particular task or reviewer taught. ## Authentication and enablement Configured tool. Bind it to the same integration, table and column as the `llm_match` tool whose history you want to read: `integration_id`, `table_name`, `embedding_key`. Bound that way, it resolves the **same** match config the matcher uses, including a config isolated via `isolate_match_learnings`. Alternatively bind `config_uuid` — the matching service's external config UUID — when you already hold one. The config must belong to the calling workspace; one that does not is reported as not found. Off by default. Enable it in the agent's Tools panel. The config must have been synced to the matching service at least once — a config that never has reports that it has no learnings rather than failing. That is a **weaker** prerequisite than `llm_match`'s, which additionally requires the config to be `ready` and will wait for an in-flight sync before matching. This tool deliberately does not: learnings are taught against the config, not against the catalog snapshot, so a config that is mid-resync still has a truthful training history to report. ## Inputs All inputs are optional — an unfiltered call returns the most recent learnings. | Input | Meaning | | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `search_term` | Only learnings taught for this term. | | `search_term_match` | `exact` (default, case-insensitive whole value) or `contains`. | | `similar_to` | Rank the result by semantic closeness to this term instead of newest-first. **Reorders, does not filter.** | | `match_type` | `positive` (the taught product is right) or `negative` (it is wrong). | | `event_kind` | `correction` (a human changed the proposed match) or `confirmation` (a human accepted it). | | `source` | Where the learning came from: `review_form_commit`, `step_edit`, `feedback_api`, `agent_tool`. | | `task_id` | Only learnings taught by one task. | | `actor_user_id` | Only learnings decided by one person (configured binding; not offered to the model). | | `created_after`, `created_before` | `YYYY-MM-DD` or RFC3339. A bare date names a whole UTC day: `created_after` starts at its first instant, `created_before` runs to its last, so the day you name as the upper bound is included. An explicit RFC3339 timestamp is used as written. | | `filters` | Structured `$and`/`$or` filter over the **taught product's** attributes — the same shape [`llm_match` filters](/docs/tools/llm-match#filters) take. | | `return_columns` | Project each taught product down to these columns. The matched column is always retained. | | `scope` | `effective` (default) or `config` — see below. | | `limit`, `offset` | Default 25, maximum 200. | ### Scope: what the matcher sees vs. what this tool taught A match config either keeps its learnings to itself (the default, and what `isolate_match_learnings` guarantees) or shares a pool with every other non-isolated config on the same integration and column. * `effective` (default) returns the set **the matcher itself reads** — for a shared config, the whole pool, including rows other tools taught. * `config` returns only rows taught through this config, which is the view to use when auditing one tool's contribution to a shared pool. The two differ only for a config that shares a pool. The result always states which set it read. ## Outputs ```json theme={null} { "status": "success", "match_config_id": "0f1c…", "table_name": "CUSTOMER", "match_field": "NAME", "scope": "config", "order": "recency", "learning_count": 2, "learnings": [ { "search_term": "Acme Pharma Ltd", "match_type": "positive", "confidence_score": 1.0, "product_identifier": "0001042", "values": { "NAME": "ACME PHARMA LIMITED", "CITY": "PUNE" }, "taught_by": { "task_id": "7b2e…", "step_id": "91af…", "actor_user_id": "3c55…", "source": "review_form_commit", "event_kind": "correction" }, "created_at": "2026-09-14T09:12:44Z" } ] } ``` * `scope` is `config` or `pool` — the requested scope resolved against the config's isolation. * `order` is `recency` or `similarity`. * `taught_by` is **omitted entirely** for a learning nobody attributed. Learnings written before attribution was recorded carry none, so an absent block means "unknown", not "nobody". * `values` is the taught product's catalog row, projected by `return_columns`. * `limit` / `offset` are echoed only when the answer may be partial (a full page, or a non-zero offset). ## Limits and behaviour * Default 25 learnings per call, maximum 200. Every learning carries a catalog row, so ask for a page rather than a corpus — use `return_columns` when rows are wide. * `similar_to` costs one cached embedding lookup in the matching service; the rest of the call is a single indexed read. * A negative learning means "this product is **not** the match for this term". Treat a term with both a negative and a newer positive as decided by the positive. * This tool never writes. Learnings are taught by reviewing a match (review form, step edit) or via the feedback API. ## Errors | Message | Cause | | ------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `No match configuration found for this integration/table/column combination.` | The binding does not point at a synced `llm_match` config on this workspace. | | `No match configuration found for that config_uuid.` | Unknown UUID, or one belonging to another workspace. | | `this match config has not been synced to the matching service yet, so it has no learnings` | The catalog sync has not completed; nothing can have been taught yet. | | `invalid filter: …` | The filter root is not `$and`/`$or`, or a condition is malformed. | | `matching service did not apply requested filters (…)` | The matching service is older than this client and ignored a predicate. The rows it returned would be wider than asked for, so they are refused rather than presented as filtered. |