12.8 The bundled SMEs

packs:agentspacks:agent-governancepacks:ai-agents

After this you can: run the bundled Support SME — what arrives on a ticket, the fences, supervision, the dark AI lane — as one job description Felix can take on.

Before you start — tick each one:

• Lesson 12.6 — Model providers and budgets (opschain learn 12.6)

In the GUI: Operations → Agents lists the SME like any agent; its supervised triage requests wait in Reviews & approvals, and the writes it makes through the Jira Service Management integration land in Audit history.

Felix has been an operator process and an AI Agent. This lesson hands it a job description LimePoint wrote: the Support SME, the reference support-desk agent that ships in the product's examples/ tree. It is one more manifest, one more rules file and one more seed script — the identity fabric, trust tiers, approval funnel, kill switches and audit are exactly the ones you applied to felix in lessons 12.2 to 12.5. The kit enrols the agent under the code support-sme; read every support-sme below as Felix wearing the job. It watches the Jira Service Management integration's ticket events (lesson 13.2) and needs packs:agents; its AI lane, when you choose to switch it on, needs packs:ai-agents.

1. Two bundled SMEs, one leash

packs:ai-agents ships a working agent out of the box: the OpsChain SME, the product's own question-answering expert — identity opschain-sme, type ai, owned by a group you choose at seed time. Seed its one delegation grant, mint a token, paste your model key, and it is answering:

examples/opschain-sme/seed-opschain-sme.sh limebank release_managers
opschain admin agent-token create --project limebank --code opschain-sme
OPSCHAIN_SERVER=<url> OPSCHAIN_TOKEN=<token> \
OPSCHAIN_AGENT_OWNER=release_managers ANTHROPIC_API_KEY=<your key> \
    python3 sdk/python/examples/opschain_sme_agent.py

It answers from exactly two sources. Product questions come from the estate's entitlement-gated embedded docs — ask about a feature your licence does not include and you get the pack-upgrade guidance, never the content. Estate questions are read at your own authority: each chat exchange delegates its reads through the asker run-as mode, so the SME sees precisely what the asking user may see — two colleagues with different grants get different answers, and a refusal is relayed as the answer. The delegation needs an explicit grant, which the seed creates:

opschain admin trust grant --agent opschain-sme --project limebank --scope / --act-as asker --note "SME asker delegation"

Everything from lessons 12.2 to 12.6 applies to it unchanged: the pack gate refuses its enrolment without packs:ai-agents, the ai ceiling pins it, its adapter transcripts are sealed and redacted, caps bound any grant it is ever given, and HALT severs it. It is the standing proof that the vendor's own AI wears the same leash it sells.

The Support SME is the second, and the rest of this lesson. It is rule-based by default: the AI lane ships dark (ai.enabled: false), and dark the agent runs no model code at all — no model call exists in the flow and no model credential exists on its host. Switching the lane on is a deliberate, multi-step act (section 6), and even enabled it is brokered-only: still no key on the host.

2. What arrives on a ticket

For every new request the agent posts one internal analysis note through the integration's audited write door:

• a classification (product area, suggested severity) from the kit's editable rules file;
• known-issue and duplicate correlation (the rules registry plus prior tickets it has seen);
• the estate's own licence and entitlement context;
• suggested lessons from the embedded docs corpus — licensed pages only; the entitlement gate is the knowledge boundary;
• a clearly-labelled draft first response. The note is an internal note — the write door cannot express a customer-visible comment, so a human always reviews and posts replies as themselves.

Tickets labelled legal, security-incident, complaint or regulatory (extendable, never shrinkable) and tickets the rules cannot classify get an escalation note instead, and no further processing.

3. The fences, operationally

• Internal notes only — structural on the write door (lesson 13.2).
• Never resolves — the integration's verbs authorise on per-verb rule paths (/admin/integrations/jsm/requests/comment|transition| fields|resolve), and the seed grants the agent only the comment path. No principal in this kit ever holds the resolve path; resolution stays a human act.
• Supervised actions wait for humans — triage transitions and labels are requested as governed changes under a SUPERVISED trust grant with rate and budget caps, and sit in Reviews & approvals until the named approvers act; the approved change's estate action performs the write through the door with its own narrowly-granted service account.
• Attachments and support bundles never enter the agent — it reads only the normalised ticket envelope fields, and the AI lane's context builder enumerates its permitted fields by name, so attachment and bundle payloads cannot transit to a model either.

4. Run it

# prerequisites: the JSM connection and its provisioned webhook (lesson 13.2), and packs:agents
examples/support-sme/seed-support-sme.sh limebank release_managers <approver> [triage-door-sa]
opschain admin agent-token create --project limebank --code support-sme
OPSCHAIN_SERVER=<url> OPSCHAIN_TOKEN=<token> \
OPSCHAIN_AGENT_OWNER=release_managers OPSCHAIN_AGENT_RELEASE=support-sme@0.1.0 \
    python3 examples/support-sme/support_sme_agent.py

Rerun the seed once after the first start — the policy assignment, owner and grant need the registered agent. The agent then appears in opschain admin agents list --project limebank as support-sme, RELEASE support-sme@0.1.0, LANE stable. What you drive and read:

• …/agents/support-sme/x-status — cursor, triage counts, whether the supervised lane is on;
• …/agents/support-sme/x-analyze — triage one ticket by hand;
• …/agents/support-sme/x-draft-backlog-card — after a human confirms a defect, drafts the card text as an internal note; filing the card is a human act;
• opschain approvals list — the supervised requests waiting on you;
• opschain admin agent trust-review support-sme and opschain admin agent activity support-sme — the evidence trail of lesson 12.3;
• opschain events --type-search jsm — every door write.

Tune examples/support-sme/support-rules.json (areas, severities, the known-issue registry, extra deny-list labels) and config.example.json → config.json (connection code, project keys, poll interval, the supervised lane) per estate.

5. Supervise it

A named owner group owns the agent (opschain admin agent owner); the SUPERVISED grant names the approvers and carries the caps. The agent never acts on a refusal — a missing grant, an ADVISE tier, a blown cap or an ungranted verb path each refuse by name, and the refusal is the outcome it records. Raise or narrow its reach only through opschain admin trust grant — the fences live in grants and manifests, not in the agent's good behaviour.

6. The AI lane — dark by default, deliberate to enable

AI-assisted triage and drafting ships in the kit but off: with ai.enabled: false the agent behaves exactly as described above, byte for byte. Enabled, the lane adds a clearly-labelled AI-assisted section to the internal note — an AI classification, a short analysis, and an AI-drafted first response a human still reviews and posts as themselves. The rules analysis always posts regardless: the lane assists the note, never replaces the pipeline. What the lane guarantees when on:

• Approved providers only. It calls the model gateway against a catalog entry that carries the data-handling-approved marker (lesson 12.6); the seed refuses to configure the lane against an unreviewed entry.
• Minimised, masked context. Only a fixed, named set of ticket fields transits: summary, description and conversation are masked (emails, phone numbers, credential-shaped strings) before transmission; the reporter appears only as a salted opaque pseudonym; custom fields are excluded unless explicitly allow-listed (the list ships empty); attachments and bundles cannot transit at all.
• Exclusions before any model call. Deny-listed labels halt triage before the lane runs, and ai.denied_organisations (with ai.organisation_field naming the organisations field) honours a per-organisation opt-out — those tickets take the rules path with no model call.
• Caps that degrade to rules. The lane's grant carries a per-UTC-day token budget, an invocation budget and a per-minute rate; an over-cap call refuses pre-flight (warn:trust:cap_refused) and the lane falls back to rule-based analysis for the rest of the day — marked loudly in the note, never queued, never blocking a ticket.
• Masked transcripts. Every model exchange lands in the agent's adapter transcript under the standing redaction rule.

Enable it in three deliberate steps:

# 1. mark the reviewed provider, then seed the AI grant and the signed ai release
opschain admin model-providers update demo-anthropic --data-handling-approved
OPSCHAIN_SME_AI_PROVIDER=demo-anthropic \
  examples/support-sme/seed-support-sme.sh limebank release_managers <approver>

# 2. switch the lane on in config.json:
#    "ai": {"enabled": true, "provider": "demo-anthropic", "model": "<model>"}

# 3. restart on the ai release
OPSCHAIN_AGENT_RELEASE=support-sme@0.2.0 python3 examples/support-sme/support_sme_agent.py

Step 3 is a new release because the AI job description discloses a model, an adapter and a custody mode the rules-only manifest does not — and a signed release freezes its disclosures (lesson 12.4).

7. What is deliberately absent

Customer-visible posting, autonomous communications and support-bundle parsing are not in this kit: the lane drafts, humans send, and bundles stay human-parsed.

Check yourself

• What does the Support SME write to a ticket, and what is deliberately absent from it?
• Which single configuration key keeps the AI lane dark, and what three steps switch it on?

What you learned

• The two bundled SMEs — the OpsChain SME and the Support SME — are job descriptions under the same leash Felix wears: enrolment, owner, tiered grants, the funnel, transcripts, halt.
• The Support SME posts one internal analysis note per ticket, escalates the deny-listed labels, never resolves, and requests transitions as supervised changes.
• Its AI lane ships dark; enabling it is a reviewed provider, a config switch and a new signed release — minimised, masked, capped, transcribed.
• The fences live in grants and manifests, not in the agent's good behaviour.

Next: lesson 12.9 — An AI assistant as a client: MCP (opschain learn 12.9), or back to your track (opschain learn).