Matcher Actions
Matcher actions bind matching policy to a named agent tool. The agent supplies the left and right record arrays. It cannot change the match key, tolerance, date window, fuzzy threshold, or rules.
Authoring
Use the built-in matcher primitive for deterministic workflow steps. When a Process Studio package gives an agent a named matcher tool, the package binds the same matcher policy to that tool. This keeps the match key, tolerance, date window, fuzzy threshold, and rules out of model control.
Properties
| Property | Type | Required | Description |
|---|---|---|---|
matchOn |
string[] | Yes | Fields for exact matching |
tolerance |
number | No | Absolute numeric tolerance applied to amount comparisons (for example, 50 allows a $50 difference) |
dateWindowDays |
number | No | Date window in days |
fuzzyThreshold |
number | No | Text similarity from 0 to 100 |
descriptionKey |
string | No | Field for fuzzy matching |
rules |
object[] | No | Additional compact comparison rules |
Matching behavior is the same as the Matcher primitive. The registered action keeps the policy fixed while the agent supplies the declared datasets.
Registered vs Primitive
Use the matcher primitive in a workflow definition:
{ "type": "matcher", "properties": { "matchOn": ["invoice_id"], "tolerance": 50 } }
Use a packaged matcher action when an agent needs a named matching tool with a fixed policy:
{ "type": "action", "name": "invoice_payment_matcher" }
Usage as an Agent Tool
{
"mode": "react",
"objective": "Reconcile this batch of transactions",
"tools": [{ "type": "action", "name": "invoice_payment_matcher" }]
}
The agent can call the matcher when it needs to compare datasets. A tool call supplies left and right arrays. Stored policy fields are rejected if the model tries to replace them.
A packaged nway_match action uses the same policy-first model for three or four datasets, with stored sets, match keys, and tolerances as the authority. See N-Way Match.
ā Next: Custom Table Actions