LLM Match Learnings

This document covers llm_match_learnings, which reads the learned mappings behind an 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 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

{
  "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.

Human interaction and orchestration

AI

Memory

Document extraction and review

Files and PDF utilities

Custom tools and code

Web automation

Agent data store

Databases and lookups

SFTP

Email

NetSuite

SAP

Tally

Slack

Google Sheets

Smartsheet

Dropbox

Box

OneDrive

SharePoint

Zendesk

DocuSign

GoHighLevel

AdvancedMD

AthenaHealth

DrChrono

PracticeSuite

Medical coding

Nanonets Health

Sage Intacct

Authentication and enablement

Inputs

Scope: what the matcher sees vs. what this tool taught

Outputs

Limits and behaviour

Errors

​Authentication and enablement

​Inputs

​Scope: what the matcher sees vs. what this tool taught

​Outputs

​Limits and behaviour

​Errors

Authentication and enablement

Inputs

Scope: what the matcher sees vs. what this tool taught

Outputs

Limits and behaviour

Errors