Customer Support App

Install this app to draft grounded support replies and escalation notes.

When to Use

• A support agent needs a grounded reply draft from product facts and policy
• A specialist needs a structured escalation note with citations
• A reviewer needs to look up the policy before approving a refund or commitment

Not Suitable For

• ❌ Replacing the ticketing system itself (it is a workbench, not a queue)
• ❌ Outbound marketing copy (use Content Factory)
• ❌ Internal product documentation (use Knowledge Builder)

Product boundary

This package is a draft support workbench, not a standalone ticketing system. The host owns installation, permission prompts, storage, secrets, Evidence, and the runtime bridge. The app owns the support-specific entries, required Knowledge slots, reply artifact shape, policy compliance checks, and v0.6 Agent task runtime intent in app.runtime.yaml.

Intended entries

Entry	Kind	Runtime expectation
draft_reply	command	Starts a reply-drafting task from the active ticket or pasted customer message.
policy_lookup	panel	Shows relevant policy Knowledge with source links and version metadata.
escalation_note	workflow	Produces an internal note for specialist or manager handoff.
reply_draft	artifact	Stores the generated reply, citations, edits, and approval state.

Only draft_reply is declared in the draft frontmatter. The other entries describe the complete target shape a production version would add.

Required setup

• Bind product_facts to a current product or service Knowledge Pack.
• Bind support_policy to the approved support-policy Knowledge Pack.
• Optionally connect ticket_lookup for ticket metadata, history, and customer context.
• Configure tenant overlays for tone, prohibited promises, escalation rules, and region-specific policy.
• Review permissions before enabling any write-back Tool.

v0.6 runtime contract

This draft opts into app.runtime.yaml so hosts can stream reply-drafting tasks through lime.agent-task-event.v1, validate structured reply artifacts, mediate tool approvals, resume or fork sessions, and record Evidence without letting the app bypass policy.

Drafting workflow

Receive ticket context
→ retrieve product facts and support policy
→ identify customer intent and risk category
→ draft answer with citations
→ run policy compliance eval
→ ask human agent to approve or edit
→ create reply_draft artifact

Quality and safety gates

• Do not answer from generic model memory when required Knowledge is missing.
• Do not cite policy unless the source exists in bound Knowledge.
• Do not mark a draft as approved when policy_compliance fails.
• Do not write back to ticketing systems without an explicit Tool permission.
• Preserve rejected drafts and eval reasons so reviewers can audit the decision.

Red Flags

• ⚠️ Replies cite policy without a Knowledge source link
• ⚠️ Drafts approved despite policy_compliance failing
• ⚠️ Customer PII written into the official package
• ⚠️ App writes back to the ticket system without an authorized Tool

Upgrade path

To make this fixture production-ready, add runtime package assets, explicit requires.capabilities, storage schema, workflow descriptors, artifact viewer, secrets for ticket connectors, permissions for read/write operations, and release metadata with package provenance. Then opt into the full v0.6 layered set (app.capabilities.yaml, app.errors.yaml, app.i18n.yaml, app.runtime.yaml, evals/readiness.yaml) for production-grade authoring.