Catalog agents by capability: match, classify, monitor, and approve

A useful catalog describes the operation, inputs, authority, evidence, and failures of a reusable capability; calling everything a “finance agent” hides that matching and approval need radically different controls. Two agents with the same sector label may share little, while an invoice comparator and a logistics-event comparator can share an operating contract.

The cost of cataloging by industry

Procurement, finance, and logistics identify sponsors, but they do not explain system behavior. A “procurement agent” might find suppliers, classify requests, compare bids, or approve orders. Each verb entails different data, evaluation, and risk.

A sector catalog also duplicates components. Three teams build separate extraction, queue, and approval mechanisms because they assume their agents are unique. The reusable unit is not the prompt. It is a primitive with a stable contract.

What belongs on a capability card

Every entry records:

Field	Question
primitive_id/version	Which exact contract did this execution use?
operation	Does it match, classify, monitor, or prepare approval?
business_object	Which object enters and which state may change?
input_contract	Which fields, rights, freshness, and provenance are required?
output_contract	Which result, reason, candidates, and evidence are returned?
authority	Does it recommend, execute reversibly, or require approval?
evaluation	Against which truth and cases is it validated?
failure_modes	Which not-found, ambiguity, policy, or dependency outcomes exist?
telemetry	Which event, latency, cost, and outcome are recorded?
owner/retire_at	Who operates it and when is it reviewed or retired?

The NIST AI RMF Core calls for inventory, differentiated responsibilities, documented risks, and lifecycle management. A capability card makes those controls comparable without suggesting NIST prescribes this architecture.

Primitive 1: MATCH — compare relationships

Input: two or more records with identifiers, normalized fields, and comparison policy. Output: match, candidates, differences, and reason code. Authority: automatic closure is limited to exact rules or approved tolerances; ambiguity goes to review.

Cases include invoice to order, payment to settlement, and event to plan. Evaluation separates false positives from false negatives by case type. One global percentage can hide a severe error in a small segment.

Primitive 2: CLASSIFY — assign policy or route

Input: object and permitted evidence. Output: class, reasons, schema version, and confidence. Authority: classification may route reversible work; it cannot by itself turn a label into rejection, payment, or sanction.

Cases include request type, exception reason, and document category. Include unknown and multiple as valid outputs. Forcing a class onto every case manufactures certainty.

Primitive 3: MONITOR — detect actionable change

Input: plan, current state, and ordered events. Output: variance, priority, clock, and owner. Authority: opens, updates, or closes an exception according to policy without repeating alerts for the same state.

Cases include delayed shipment, SLA risk, and stale data source. Evaluation measures useful events and duplicates rather than raw notification count.

The CloudEvents specification defines an interoperable envelope with required attributes including id, source, specversion, and type, while separating context from payload. It does not define monitoring logic; it demonstrates how one primitive can receive events from multiple engines without coupling to internal formats.

Primitive 4: APPROVE — prepare and record authority

Input: proposed action, object, evidence, policy, and consequences. Output: approved, rejected, returned, or expired, with actor and reason. Authority: the primitive records the decision; the agent preparing the case does not approve itself.

Cases include order release, variance acceptance, content publication, and access change. The contract includes separation of duties, substitution, expiry, and reopening. “Human in the loop” without defined permission and context is merely a screen.

Compose capabilities without creating an opaque chain

The OMG BPMN 2.0 specification provides vocabulary for tasks, events, gateways, error, escalation, and compensation. Use a process model to show how primitives change state instead of hiding orchestration inside one general agent.

An accounts-payable flow could be:

1. CLASSIFY identifies document and policy;
2. MATCH compares invoice, order, and receipt;
3. MONITOR opens an exception when data is absent or time expires;
4. APPROVE presents material differences to the authority;
5. deterministic automation posts the authorized action.

Every step emits an event with object, version, result, and evidence. When MATCH fails, the state does not move as if the whole chain were one undifferentiated failure; the exception names capability and reason.

Example of cross-domain reuse

This example is illustrative. Procurement uses MATCH for bid and requirement; finance uses it for payment and settlement; logistics uses it for event and plan. They share candidate mechanics, basic exact/ambiguous/not-found codes, and an evidence envelope. They do not share business rules or tolerances.

MONITOR shares deduplication, clock, and exception ownership, while each domain defines actionable change. APPROVE shares identity, policy, evidence, and decision; permission still belongs to the process.

The aim is not maximum code reuse. It is reuse of contracts and controls where meaning genuinely aligns.

A visible catalog in Quantum

In Quantum Automation Center, the catalog can distinguish agent, automation, and capability; executions and timelines show which version acted; artifacts and logs hold permitted references; permissions and human approval apply authority; and analytics compare use, exception, and outcome. The Quantum ontology links capabilities to business objects.

An executive card should show operation, owner, authority level, reusing domains, state, and evaluation evidence. Avoid names such as “advanced intelligent agent.”

Counterargument: too many primitives fragment the outcome

The criticism is right when every verb becomes a separate product, team, and queue. Orchestration can cost more than the original problem, and users end up moving among micro-agents.

Compose primitives around one object, state, and outcome owner. One implementation may execute several capabilities when that is simpler, but keep contracts and evidence distinct. Modularity is conceptual before it is organizational.

When not to use this approach

Do not divide a small, deterministic, low-risk flow into multiple agents. A function or rule may be clearer. Do not use probabilistic CLASSIFY where a reliable field already determines the class, or decorative APPROVE where policy permits reversible automatic execution.

Do not create a catalog without owners and real cases. A library of abstract names becomes dead inventory.

Catalog quality test

Take two entries from different industries. Hide their commercial names and compare contract, authority, and failures. If you cannot explain why they are the same capability, separate them. If you can, prove that evaluation and evidence transfer before claiming reuse. The catalog earns its place when it improves a design decision, not when it increases card count.

Sources

• OMG Business Process Model and Notation (BPMN) 2.0 — omg.org
• CloudEvents Specification — github.com
• NIST AI Risk Management Framework Core — nist.gov