CRMShowcase

Imported from urruegg/CRMShowcase (AGENTS.md). Install upstream with npx skills add urruegg/CRMShowcase. Copyright stays with the author.

Agent Registry — Runtime & Engineering Agents

Related: docs/AI.md · docs/DATA.md · docs/SD.md · docs/COMPLIANCE.md · SUPERPOWERS_CONTRACT.md · docs/PERSONAS-JOURNEY.md

Two classes of agent. This registry covers (1) runtime / functional agents AG-F-## — the CRM agents inside the showcase that an advisor, assistance agent or marketer collaborates with — and (2) engineering / build-time agents AG-E-## — the GitHub Copilot custom agents that build the showcase (files under .github/agents/).

Every runtime agent below carries a Maturity field (productive-at-customers vs. roadmap) and a Licence flag. Answer both honestly — blurring the maturity distinction is the fastest way to lose a regulated buyer's trust.

Non-negotiable principle — agents recommend, humans decide

Runtime agents are advisory by design. They score, propose and prepare; a human accepts, edits or dismisses in the cockpit, and that decision feeds the learning loop.

No AG-F-## agent performs an unattended customer-facing act — no autonomous send, no autonomous policy change, no autonomous pricing commitment. This is a deliberate design position for a regulated insurer (ADR-0014), and it is what keeps a named human accountable for every customer-facing decision.

Any proposal to make an agent act autonomously on a customer is a governance-changing event: it requires an ADR and Responsible-AI review (AG-E-06), not a configuration change.

1. Runtime / functional agents (AG-F-##)

Each agent lists Purpose · Inputs → Outputs · Realizing service · Guardrails · Side effects · HITL · Maturity · Licence.

AG-F-01 — Next-Best-Action Agent (book-wide scoring)

• Purpose. Score the whole book on a schedule and on lifecycle events, and emit explainable Next-Best-Actions into the advisor cockpit.
• Inputs → Outputs. Household / Contact / Policy / Claim / Interaction context → ranked, explainable NBA cards with a specific CTA.
• Realizing service. Copilot Studio agent / Power Automate + Dataverse; scoring grounded on one Dataverse.
• Guardrails. Explainability required on every card; consent checked before any outbound-capable CTA (ADR-0010); LeadCluster anti-over-contact bundling so one household is not approached five times.
• Side effects. Writes NBA records; never contacts the customer.
• HITL. Advisor accepts / edits / dismisses — the decision is the learning signal.
• Maturity. [TBD] · Licence. [TBD]

AG-F-02 — Life-Event & Curveball Detection Agent

• Purpose. Detect a material change (address, household composition, vehicle, object) and open the cascade the golden thread is validated against.
• Inputs → Outputs. Change event on a governed attribute → typed domain event + affected-portfolio impact set.
• Realizing service. Dataverse change tracking → event → Power Automate / Azure integration layer.
• Guardrails. Effective dating mandatory (ADR-0011); the agent identifies impact, it does not re-rate — rating stays in the engines of record (ADR-0008).
• Side effects. Emits events consumed by downstream systems; raises tasks.
• HITL. Jurisdiction-changing outcomes always route to a human (ADR-0012).
• Maturity. Design — implemented for the golden thread. · Licence. 🧩

AG-F-03 — Case Management Agent (prefill)

• Purpose. Predict and populate case fields at conversation accept / end.
• Realizing service. Out-of-box D365 Case Management Agent.
• Guardrails. Prefill is a draft; the agent does not close cases.
• HITL. Agent-populated fields are visibly marked so the contribution is unmistakable.
• Maturity. Native product capability — [confirm GA status] · Licence. [TBD]

AG-F-04 — Conversation Intelligence & Transcript Agent

• Purpose. Summarise the interaction, extract decisions and tasks, and write them back with a visible provenance badge.
• Guardrails. Every agent-touched row carries a provenance marker; records fill through actions rather than being pre-populated.
• Constraint. Live transcript + Copilot voice run on the native voice channel only — not while a third-party contact-centre platform owns the call (ADR-0015).
• HITL. Advisor edits before anything is committed.
• Maturity. [TBD] · Licence. [TBD]

AG-F-05 — Data-Quality & Identity-Resolution Agent

• Purpose. Detect duplicates and ambiguous identity (e.g. one inbound number resolving to several households) and raise closed-loop remediation tasks.
• Guardrails. Never silently merges a golden record; a merge is a human-approved act.
• HITL. Agent proposes the match; a steward confirms.
• Maturity. Design · Licence. 🧩

AG-F-06 — Campaign & Content Assist Agent

• Purpose. Natural-language segment building, content generation and channel optimisation for marketing.
• Guardrails. Consent per contact per channel enforced as a hard gate (ADR-0010); central templates and CI/CD rules bind decentral GA campaigns.
• HITL. Approval workflow before any activation.
• Maturity. Native — [confirm which sub-capabilities are GA] · Licence. [TBD]

Not-native, be explicit. Paid Meta / Google is not a native send channel — audience activation runs via export connectors. Look-alike modelling is not native — it goes to Azure ML. Budget / ROI / CPL is a custom table plus Power BI. Say this plainly rather than letting it be discovered.

1.1 Summary

2. Engineering / build-time agents (AG-E-##)

These are the GitHub Copilot custom agents in .github/agents/. Each AG-E-01–AG-E-10 has a matching chatmode in .github/chatmodes/; the support agents AG-E-11 / AG-E-12 are advisory and can gain a chatmode when a sprint needs it.

Imported conditional specialists

These specialists do not add decision authority and do not replace the AG-E-## owners. Invoke them only for the stated implementation surface.

Authority

Two decisions cannot be made by an agent alone:

1. Architecture approval (AG-E-03) — any change to system boundaries, the integration contract, the data model core, or the thin-CRM position.
2. RAI / compliance review (AG-E-06) — any change to models, prompts, evaluations, consent handling, or personal-data flows.

Both are enforced as required reviewers via CODEOWNERS — see SUPERPOWERS_CONTRACT.md §3.

See .github/agents/AGENT_WORKFLOW.md for the handoff pattern and .github/agents/NON_DELEGABLE_WORK.md for the decisions no agent may make alone.

3. End-to-end traceability

Requirement (topic area A#)
   → Use case (UC-…)              docs/ideas/
   → ADR                          docs/adr/ADR-####-*.md
   → Solution change              solution/
   → Test                         docs/TEST.md + automated checks
   → Evidence in PR               green pipeline run
   → Deployed to sandbox          the customer sees it running

This traceability chain is the concrete mechanism behind this repo's docs/FRONTIER-OPERATING-MODEL.md — the requirement/use case/ADR/change/test/evidence loop is how the Frontier Operating Model's "Microsoft IQ-driven development, build, and operate" principle is enforced in practice.

This chain is the answer to A8 (versioning, deployment, test automation, rollback). It is also the answer to A4's harder question — what happens to this extension at the next release? — because every change carries a recorded upgrade impact.