Quickchat AI

View saved version →

---
name: conversation-triage
description: >-
  Find and prioritize the customer conversations a teammate should follow up on:
  ones that are still unresolved and ones the AI escalated for the team to
  review. Read a sample, summarize what happened, note any that got a negative
  rating, and suggest a next step for each. Use when the user asks what
  needs a reply, which chats to review, what to follow up on, or to sort the
  support inbox. Do NOT use for aggregate stats (use performance-review) or to
  change the Agent (use improve-agent).
metadata:
  author: quickchat-ai
  version: "1.0"
---

# Conversation triage

Surface the customer conversations a teammate should follow up on, and make each
one actionable.

## Before you start
- Call `list_scenarios` to resolve the Agent. One Agent -> use it; else ask.
- Default window: the last 7 days.

## Steps
1. Use `get_insights` with insight_type="flagged" for the conversations the AI
   escalated for the team to review. It defaults to the most recent matches
   across ALL time, so pass `start_date`/`end_date` to constrain it to the
   window rather than filtering all-time results yourself, and page with
   `next_cursor` if needed.
2. Use `list_conversations` with `resolution_status="open"` plus
   `start_date`/`end_date` for the window to find open conversations.
3. Open `get_conversation_detail` on the most important few to read the
   transcript, see what happened, and note any negative rating the customer left.
4. Where a reply looks wrong or an action seems to have failed, call
   `get_message_diagnostics` on that conversation: it shows the tools the AI
   actually executed (with errors) and the Why AI Said That analysis when one
   exists (`analysis_status=not_generated` means it has not run yet).
5. Cross-reference: a conversation that is both escalated and unresolved is the
   top priority.
6. For each item the user approves, act on it with `update_conversation`:
   `assign_to` to route it to a teammate (or to 'me'), or `status='resolved'` to
   close it out (add `assign_to='me'` if it is not yours, `confirm=true` to resolve).

## Guardrails
- Assigning and resolving are real writes on the customer's Inbox, and resolving
  ends the conversation and can ask the visitor for a final rating. Ask before
  each one and never batch them without approval. Both need SUPPORT access or
  above; if you do not have `update_conversation` on this connection, recommend
  the next step and tell the user to take it in the Quickchat Inbox instead.

## Output
A prioritized list, most important first. For each: the customer's request in one
line, why it is on the list (unresolved or escalated for review), any negative
rating it received, and a suggested next step. End with the single top item to
handle first.

Referenced files: 1

View saved version →

---
name: improve-agent
description: >-
  Audit a Quickchat AI Agent and improve it: read its current settings and
  knowledge base, mine recent conversations for gaps (unanswered questions, wrong
  answers, off-brand tone, missing knowledge), then propose specific
  configuration edits and knowledge-base additions. Apply changes only after the
  user approves each one. Use when the user asks to improve, tune, optimize, fix,
  or update an Agent, add knowledge, or change its persona, greeting, language,
  or profile picture.
metadata:
  author: quickchat-ai
  version: "1.0"
---

# Improve an Agent

Read first, change second. Diagnose from real data, propose the smallest fix, and
never write without explicit approval.

## Before you start
- Call `list_scenarios` to resolve the Agent. Config tools require EDITOR-or-above
  on that Agent; if the user lacks it, say so and stop.
- Ask whether to PROPOSE changes only (default) or also APPLY approved ones.

## Diagnose
1. `get_assistant_settings` — persona, profession, creativity, greeting, language,
   reply length, KB descriptions.
2. `list_knowledge_base_articles` — what the Agent already knows. `content` here
   is a preview, not the article; `get_knowledge_base_article` returns the body.
3. `get_insights` plus a `list_conversations` sample read with
   `get_conversation_detail` to find where it struggled. Classify with
   `references/failure-taxonomy.md`.

## Propose
For each recurring problem, propose the SMALLEST change that fixes it:
- Missing knowledge -> a new KB article (draft the exact text).
- Wrong tone/persona -> a specific `personality` (an enum id, not a scale) or an
  `ai_commands` guideline.
- Too long / short / robotic -> `reply_length` or `creativity_level`.
Present proposals as a before -> after diff, then STOP for approval.

## Apply (only after approval)
- `update_assistant_settings` — pass ONLY the fields that change; effective
  immediately, no retrain.
- `add_knowledge_base_article` — content required; embedded automatically in the
  background, no retrain.
- `update_knowledge_base_article` — replaces the article's WHOLE body, so read it
  with `get_knowledge_base_article` first and send the full edited text.
  `previous_title` + `previous_content` restore the previous title and
  body, unless `previous_content_truncated` is true.
- `delete_knowledge_base_article` — irreversible; read the article first, since
  the response echoes only the first 20,000 characters for recovery. It requires
  `expected_title` and `expected_added_at` from
  `list_knowledge_base_articles` (they fail the call if the article changed
  underneath you) plus confirm=true.
- `set_assistant_avatar` — profile picture from an image URL, a base64 data URI
  (png/jpg/gif/webp, max 5 MB), or `use_default=true` to reset. It permanently
  replaces the previous image and the legacy launcher icon, and needs a plan
  that allows widget customization. It returns the resulting `avatar_url` —
  there is no settings field to re-read it from.
- After each other write, re-read with `get_assistant_settings` /
  `list_knowledge_base_articles` and confirm the change landed.

## Guardrails
- Never call a write tool before the user approves that specific change.
- Never build an edit out of a preview — correcting one line still means sending
  the whole article, and a preview sent back silently drops the rest.
- `personality` and similar fields are enum ids — use the ids from the tool
  schema, not free text.
- Some fields (e.g. `ai_commands`) need a plan feature; if a write is rejected for
  that reason, report it plainly instead of retrying.

## Output
A short report: top issues (ranked, one example each), the proposed changes as a
diff, and — if you applied any — a confirmation of what changed.

Referenced files: 2

View saved version →

---
name: launch-agent
description: >-
  Configure a Quickchat AI Agent from scratch, end to end: set up the empty Agent
  the account already has (or provision one when every Agent is already
  configured), build it from a website URL or from a short interview when there is
  no site, then show the generated configuration and how to test it. Use
  when the user asks to create, build, launch, set up, or spin up a new Agent, to
  make an Agent from a website or URL, or when they have just connected Quickchat
  and have nothing set up yet. Not for editing an established Agent (use
  improve-agent).
metadata:
  author: quickchat-ai
  version: "2.1"
---

# Launch a new Agent

Stand up a working Agent in one guided flow. Most people running this have just
connected Quickchat and already have an empty Agent, so configure THAT one and
build something before you report anything.

## Before you start
1. Call `list_scenarios`. Connecting Quickchat already created an Agent, so if any
   entry has `configured: false` AND a `role` of EDITOR or above, use that
   `scenario_id` for everything below and do NOT call `create_assistant` (creating
   another leaves theirs blank forever). Ignore unconfigured Agents you only have
   VIEWER on: they are someone else's and onboarding them will fail. Only when
   every Agent you can edit is already configured, or the user asked for an extra
   one, call `create_assistant` with confirm=true and use the scenario_id it
   returns. If more than one Agent qualifies, ask which to set up.
2. Ask whether they have a website to build from. That answer picks the path below.
3. Their Agent is on the FREE tier (no charge, no card); say so if you create one.

## Path A — they have a website
1. Use the scenario_id from "Before you start". Set the display name with
   `update_assistant_settings` if they gave one.
2. Call `onboard_assistant_from_url` with that scenario_id, the URL and
   confirm=true — all three are required, and the call is rejected without the
   confirm. Say out loud that this takes 20-60 seconds while it scrapes the
   site, writes the persona and embeds the content — silence here is where
   people give up. It OVERWRITES persona and settings and adds the scraped
   content to any existing knowledge, so run it on an Agent that holds nothing
   yet; on an already-configured Agent, ask first.
3. Poll `get_assistant_settings` until `onboarding_from_url_completed` is true.
   If it reports `onboarding_progress_tracked` false there is no completion
   signal — read the settings once after ~60s instead.
4. Show what was generated: the name, the main prompt, the guidelines and the
   language it picked.

If the URL is rejected as a placeholder or marketplace domain, ask for their own
business website rather than retrying the same URL.

## Path B — no website
Do NOT create an empty Agent and stop. Interview first, in one short round of
questions:
- What does the business do, and what is it called?
- Who will be talking to the Agent (customers, members, players, staff)?
- What tone should it take?
- What are the top 3 questions it must answer?

Then configure their Agent in a single `update_assistant_settings` call on the
scenario_id from "Before you start". Do this on every no-website run, including
when you had to create the Agent: creation happens before this interview, so it
cannot have carried answers you had not collected yet, and skipping the write
leaves the new Agent blank.
- `name` and `one_word_description` — what the Agent is called
- `short_description` — the main prompt: role, what it helps with, what it must
  not guess at
- `ai_commands` — one short rule per item, from their must-answer questions
- `greeting` — the first line a visitor sees
- `language_chosen` — the language they answered in

Then offer `add_knowledge_base_article` for any facts they can give you now
(hours, pricing, policies). Content is embedded automatically; there is no
retrain step.

## Optional — connect a system
If they name something the Agent should reach (an order lookup, a booking system,
an internal API), offer `create_http_request_action`, then
`test_http_request_action` to prove it works. It takes no confirm argument. Skip
this unless they raise it, and never invent an endpoint.

## Close by making it real
1. `get_deployment_info` — give them the widget embed snippet and the public chat
   link.
2. Tell them they can talk to it right now at
   `https://app.quickchat.ai/i/<scenario_id>/ai-preview`.
3. Offer one concrete next step (add knowledge, tune the persona via
   improve-agent).

## Guardrails
- Configure the Agent the account already has. Create at most ONE Agent per
  request, only when none is unconfigured or the user asked; never loop
  `create_assistant`. If its result carries a `warning` naming an Agent that
  is still blank, tell the user and offer to configure that one instead.
- If initial settings are rejected, the Agent still exists — adjust and apply with
  `update_assistant_settings` on the returned scenario_id; do NOT call
  `create_assistant` again.
- If a configuration call returns an error, re-read with `get_assistant_settings`
  before retrying; the write may already have landed.

## Output
Confirm the Agent's name and scenario_id, summarize the configuration you set,
and give the preview link plus 1-2 next steps.

Referenced files: 1

View saved version →

---
name: performance-review
description: >-
  Produce a performance review of a Quickchat AI Agent: pull conversation
  volume, resolution rate, CSAT, handoff response time, and topic trends over a
  period and turn them into a prioritized set of recommendations. Use when the
  user asks how an Agent is doing, for a weekly or monthly review, a health
  check, KPIs, or to compare one period against another. Do NOT use for reading
  individual conversations (use conversation-triage) or changing settings (use
  improve-agent).
metadata:
  author: quickchat-ai
  version: "1.0"
---

# Performance review

Turn a Quickchat AI Agent's analytics into a short, decision-ready review.

## Before you start
- Call `list_scenarios` to resolve which Agent the user means. Exactly one Agent
  -> use it; otherwise ask which one.
- Confirm the period. Default: the last 7 days vs the 7 days before it.

## Steps
1. Use `compare_periods` to compare the current period with the previous one of
   equal length. Pass the PREVIOUS (older) window as `period_a` and the CURRENT
   window as `period_b`: deltas are computed as period_b minus period_a, so this
   makes a positive delta mean "up versus the previous period." Returns both
   overviews plus per-metric deltas.
2. Use `get_topics` for the customer-intent split, and read `topics_by_day` from
   the overview for free-text themes that are rising.
3. Use `get_csat` for satisfaction and `get_ttfr` for human handoff speed (only
   if the Agent hands off).
4. For any count, rate, total, or trend, ALWAYS use the analytics tools above.
   Never page through `list_conversations` to compute an aggregate.

## Read the numbers correctly
- `resolution_rate` already combines confirmed and assumed resolutions; report it
  as a percentage of conversations.
- `get_csat` empty means no CSAT was received, NOT a low score — say "no CSAT
  data" rather than implying dissatisfaction.
- `get_ttfr` measures HUMAN responders after a handoff, in seconds, not
  business-hours adjusted; prefer the median and note overnight gaps inflate the
  average.
- See `references/metrics-glossary.md` for the full field reference.

## Output
1. One-line headline: better or worse, and why.
2. A compact table: this period vs last, with deltas, for volume, resolution
   rate, CSAT, and handoffs.
3. Rising topics worth attention.
4. 2-3 concrete, prioritized recommendations.
Keep it scannable; lead with the metric that moved most.

Referenced files: 2