Intent-Task Catalog

The Intent-Task Catalog is the routing layer of the Decision plane: it maps every supported intent to a risk-classified task template and the Decision Specs that template produces. Without it, every team writes ad-hoc workflows for the same business intent.

Definition

A versioned, governed registry of Intent entries (canonical intent name with metadata) and TaskTemplate entries (parameterized plan blueprints bound to one or more Decision Specs). Each intent declares its risk class, accepted channels, locale support, and the task templates eligible to handle it.

Why it exists

Intents are how the runtime understands what the user wants. If different teams classify “refund” differently or build different workflows for it, decisions become incomparable across teams, audit becomes impossible, and improvement loops stall. The catalog gives intents a single name, single risk classification, single set of approved templates.

How it works

1. Author an Intent with name, description, risk class, accepted channels.
2. Author one or more TaskTemplate entries that handle that intent.
3. Bind each task template to its Decision Specs (e.g., support.refund.eligibility and support.refund.execute).
4. Resolve at runtime — the Compiler’s intent classification stage maps a raw input to one canonical intent; the Planner picks an eligible task template by Run Context and risk.
5. Emit decisions — every Decision Record carries its intent_ref for downstream evaluation and improvement.

Intent

{
  "intent_id": "support.refund",
  "version": "3.0.0",
  "owner_role": "support_ops",
  "description": "Customer requests a refund on a prior order.",
  "risk_class": "destructive",
  "accepted_channels": ["app_chat", "email", "voice"],
  "locale_support": ["en-IN", "en-US", "hi-IN"],
  "eligible_task_templates": ["task_refund_with_eligibility", "task_refund_self_serve"]
}

Intent fields are tightly governed because they decide which workflow runs and what risk tier applies.

TaskTemplate

{
  "task_template_id": "task_refund_with_eligibility",
  "version": "2.1.0",
  "intent_id": "support.refund",
  "owner_role": "support_ops",
  "decision_bindings": [
    { "decision_key": "support.refund.eligibility", "checkpoint_after_step": "s2" },
    { "decision_key": "support.refund.execute",     "checkpoint_after_step": "s2" }
  ],
  "default_plan": {
    "steps": [
      { "id": "s1", "tool": "adp_orders.lookup", "params_schema": "schema://adp_orders.lookup.in" },
      { "id": "s2", "tool": "adp_policy.eval",   "depends_on": ["s1"] },
      { "id": "s3", "tool": "adp_payments.issue_refund","depends_on": ["s2"], "approval_mode": "destructive" }
    ]
  },
  "eligibility_rules": {
    "and": [
      { "==": [{ "var": "request.channel" }, "app_chat"] },
      { ">=": [{ "var": "user.tenure_days" }, 30] }
    ]
  }
}

Task templates are not scripts. They are versioned, owned, schema-validated blueprints the Planner expands into a concrete Plan.

Risk classification

Every intent declares one of the approval-mode tiers as its risk_class. Effects:

• the Compiler refuses to surface tools whose approval_mode exceeds the intent’s risk_class without explicit policy permission,
• the Critic verifies plan steps respect the intent’s risk class,
• the Trust plane stratifies sampling and release gates by risk class.

Routing

For an inbound invokeAgent request:

1. Intent classification produces one canonical intent.
2. Eligibility rules across templates are evaluated against the Run Context; ties broken by template version recency.
3. The selected template is the Planner’s blueprint.
4. The Run Context records the selected intent_id and task_template_id so the Critic and the Decision Record can reference them.

Interfaces

Inputs

• Raw user input (message, channel, locale, attachments)
• Run Context (user, agent, tenant, claims)

Outputs

• intent_id, task_template_id
• Decision-binding map for the planner
• Risk class for downstream sampling and release gates

Failure modes

• Multiple intents match — runtime requires a deterministic tiebreaker (highest specificity, then most recent version).
• Selected template binds to a non-existent decision spec — fail closed at compile time.
• Task template plan references a tool not in the pack’s tooling_layer — caught by the Critic’s verify pass.
• Intent risk class lower than the highest tool’s approval_mode — prevents safe execution; raise the intent’s risk class.

Operational concerns

• Owner role accountable for every intent and template; orphans flagged.
• Versioned changes; deprecation windows for breaking changes.
• Per-tenant routing overlays cannot grant new tools, only constrain.
• Routing latency budget folded into the planner timeout.

Evaluation metrics

• Intent-classification precision/recall on golden requests.
• Template-selection consistency across replays.
• Risk-class drift detection (intent changing risk class across versions).
• Mean templates per intent (target: low).

Example

Two templates handling the same intent at different risk levels:

{
  "intent_id": "support.refund",
  "templates": [
    { "task_template_id": "task_refund_self_serve",
      "decision_bindings": [{ "decision_key": "support.refund.execute" }],
      "eligibility_rules": { "<=": [{ "var": "request.context.refund_amount" }, 200] },
      "highest_approval_mode": "delegated" },
    { "task_template_id": "task_refund_with_eligibility",
      "decision_bindings": [{ "decision_key": "support.refund.eligibility" }, { "decision_key": "support.refund.execute" }],
      "eligibility_rules": { ">": [{ "var": "request.context.refund_amount" }, 200] },
      "highest_approval_mode": "destructive" }
  ]
}

Common misconceptions

• Intents are not user phrases. They are canonical, governed names; classification maps phrases to intents.
• Task templates are not scripts. They are blueprints; the Planner expands them into a Plan.
• Risk class is not optional. Without it, the Compiler cannot apply approval-mode filtering correctly.