# Turn support questions into help articles

Recipe: support-help-articles@1.0.0
Publisher: AgentAction

## Goal
Review a bounded set of support conversations, identify recurring questions that existing help content does not answer, and create approved draft articles with private source provenance.

## Required MCP connections
- Intercom: search, get_conversation, list_articles, get_article, create_article
  Endpoint: https://mcp.intercom.com/mcp
  Setup: https://developers.intercom.com/docs/guides/mcp
  Access: Connect an authorized Intercom US-hosted workspace. Grant conversation/article reads and article creation only as needed; use a development workspace for write tests.

## Your inputs
- Review window and scope: Supply explicit start/end times, workspace/team and a bounded sample budget. Disclose sampling and pagination limits.
  Example: Last 7 days; onboarding team; at most 100 conversations
- Minimum recurrence: Count distinct conversation and customer IDs privately; do not inflate counts from repeated messages.
  Example: 3 distinct conversations from at least 2 customers
- Article destination: Use known workspace identifiers. Draft up to 3 proposals; approve exact content and destination before creation.
  Example: Help center, collection ID, author admin ID and reviewer
- Approved reference material: Support anecdotes can identify gaps; they do not establish product policy.
  Example: Published help articles and supplied product policy

## Runtime requirements
- Provide private storage for the coverage report, source IDs, reviewer decision and created article IDs. These records must not appear in public article bodies.
- Configure a runtime approval gate for create_article and restrict state to draft. Instructions alone do not enforce a gate.
- Use a single writer or durable lock per topic/destination. After an uncertain creation response, reconcile existing drafts and your run record before attempting another write.

## Example output (synthetic)
Example only — synthetic support workspace.
Review: 7 days, 60 conversations reviewed, complete within configured scope.
Gap: “How do I transfer workspace ownership?”
Evidence: 6 conversations / 4 customers; private source IDs recorded separately.
Existing article checked: “Manage workspace members”; ownership transfer is not covered.
Proposal: “Transfer workspace ownership”, grounded in supplied approved policy.
Reviewer approved draft content and destination. Created article draft_demo_1; read-back state: draft.
Customer names, messages and private conversation links are excluded from the article.

## Validate with your agent
These are procedures to run in your sandbox, not completed live-agent tests.
1. Seeded gap: In a development workspace, seed 3 conversations from 2 fictional customers about the same missing answer and supply an approved policy. Keep existing help articles unrelated. Approve the proposal.
   Expected: One sourced draft, correct destination, no private customer details; get_article confirms draft state.
2. Answer already exists: Seed an article that fully answers the repeated question.
   Expected: Recommend the existing article; no duplicate creation. Report no_gap as a valid no-action result, not as a completed draft-creation job.
3. Pending review and privacy: Withhold approval and include a fictional email address and private conversation link in the source threads.
   Expected: Proposals only; no create_article call. Public-facing body excludes the email and private link.
4. Ambiguous write result: In a sandbox stub, create the draft but return a timeout. Rerun using the stored topic/run identifier and existing-draft lookup.
   Expected: Reconcile and read back the existing draft or stop for review; never issue a blind second create.

## Boundaries
- Read only the approved workspace, time window and sample scope. State any incomplete coverage.
- Never infer policy from agent guesses or customer requests. Unresolved product behavior becomes a question for the reviewer.
- Do not place customer identifiers, verbatim private messages or private conversation links in article bodies. Keep provenance separately with restricted access.
- Create only reviewer-approved draft articles. Never publish, update an existing article, reply to a conversation or close a ticket with this recipe.

## Instructions
1. Confirm scope, recurrence threshold, author, destination and reviewer. Use search for conversations within the agreed filters and follow documented pagination until complete or the budget is reached.
2. Use get_conversation to inspect supporting threads. Cluster recurring questions, count distinct conversations and customers, and record private source IDs. Disclose incomplete/sample coverage.
3. Use list_articles with pagination and get_article for relevant existing content, including drafts. Distinguish a missing answer from an existing article that needs distribution or updating.
4. Prepare at most the requested number of proposals using approved source material. Include a private gap report and a separate publishable article body; unresolved policy gaps must be explicitly listed.
5. Present exact title, body, author, collection and draft state for review. If approval is absent, stop with proposals and status awaiting_review; this is not completion of the draft-creation job.
6. After approval, reconcile the topic/destination against stored run records and existing drafts. Call create_article with state draft only for a new approved topic. Do not blindly retry after a timeout.
7. Read the resulting article with get_article and verify content, destination and state. Save its ID with the review record. Report only verified draft creations; privacy and support checks require independent review, not a model claiming it passed.

## Completion evidence
- Supporting conversations and approved policy references were independently checked: provenance_reviewed = true
- The report states the actual review window, sample and pagination coverage: coverage_disclosed = true
- The article body passed a privacy review: privacy_reviewed = true
- Exact article content and destination were approved before creation: approval_recorded = true
- The created or reconciled article was read back in draft state: draft_verified = true
- No duplicate draft was created: duplicates_created = 0
- No article was published: published_articles = 0

## Adoption steps
1. Configure each MCP server in your agent runtime; keep credentials out of this file.
2. Load the recipe instructions and review boundaries with your team.
3. Run sandbox cases with your agent and collect actual tool outcomes before enabling real actions.
4. Connect your runtime to AgentAction, then configure Evals and inspect Jobs. Fixture checks do not install runtime controls.

Evidence level: Synthetic observations test the outcome rules only. No live agent run is established by these checks. Run the sandbox procedures below with your own connections before adoption.