Replacing Intercom Fin Without Losing Support Quality

A packaged agent combines ingestion, retrieval, prompting, model access, reporting, escalation, and a support workspace. Replacing it does not mean recreating all of those surfaces. It means identifying the part that creates differentiated value or disproportionate cost, then owning that path while preserving mature commodity systems around it.

The strongest reason to build is control: product-specific account context, custom permission checks, specialized actions, measurable release gates, or provider flexibility that a generic agent cannot express. The weakest reason is a surprising invoice with no baseline. An internal system has model, retrieval, platform, review, maintenance, incident, and opportunity costs. Compare verified outcomes after including them all.

Use three decision gates. First, can the team define a correct resolution for the major support intents? Second, does the product expose trusted account state and actions through secure interfaces? Third, will one team own quality, safety, and cost after launch? If any answer is no, improve instrumentation or integration before replacing the production route.

Export a representative set of conversations with intent, channel, customer segment, language, handling time, escalation, reopen status, and final resolution. Sample across the long tail instead of selecting only high-volume password and billing questions. Remove personal data or create reviewed synthetic versions. Preserve the policy and product state that applied when the conversation occurred.

Label the customer goal, required facts, approved sources, allowed actions, prohibited actions, escalation requirement, and what counts as resolved. A friendly answer that sends the customer back three messages later is not a resolution. A correct policy answer that ignores account state may also fail. The dataset needs product outcomes, not only stylistic preferences.

from dataclasses import dataclass

@dataclass(frozen=True)
class SupportCase:
    case_id: str
    customer_message: str
    account_state: dict
    expected_sources: tuple[str, ...]
    required_facts: tuple[str, ...]
    must_escalate: bool
    prohibited_actions: tuple[str, ...]

refund_case = SupportCase(
    case_id="billing-refund-042",
    customer_message="I was charged after cancelling yesterday.",
    account_state={"cancelled": True, "charge_age_hours": 18},
    expected_sources=("refund-policy-current",),
    required_facts=("refund review window", "confirmation timeline"),
    must_escalate=True,
    prohibited_actions=("promise_refund", "change_subscription"),
)

Score factual correctness, policy compliance, source support, account-context use, action correctness, escalation correctness, clarity, and resolution. Use deterministic checks for tool arguments, permissions, required fields, and prohibited promises. Use calibrated rubric graders for nuanced quality. Review disagreements with experienced support staff and add examples to the rubric.

Establish the packaged-agent baseline by replaying cases where possible and by reviewing historical outputs where replay is unavailable. Record coverage, correct resolution, false resolution, unnecessary escalation, missed escalation, reopen rate, first-response latency, human handling time, and cost per verified resolution. Break results down by intent and risk. A global automation rate can rise while billing or account-security outcomes deteriorate.

• Dataset includes high-volume, high-risk, and long-tail intents
• Resolution is defined from the customer outcome
• Required and prohibited actions are explicit
• Escalation is evaluated in both directions
• Historical baseline includes reopened conversations
• Support reviewers calibrate automated graders

Build four explicit boundaries. The knowledge layer retrieves approved product and policy material. The account layer reads authenticated customer state through narrow, audited interfaces. The decision layer assembles evidence and decides whether the system may answer or must escalate. The action layer executes only allowlisted operations after trusted authorization and validation.

Do not place account credentials, tenant identifiers, or permissions in prompt text and expect the model to enforce them. The authenticated application derives identity and passes only authorized data. Every tool call is re-authorized outside the model using user, tenant, resource, action, and current state. Generated arguments are untrusted input and must pass a strict schema and business rules.

Retrieval should distinguish public help content, internal support policy, customer-specific documents, and account facts. Each source has a visibility policy, owner, effective date, and deletion path. Search filters use trusted identity. The trace records source identifiers and versions so a reviewer can explain why the agent gave an answer on that day.

Store conversation state intentionally. Keep verified facts separate from model summaries. Summaries can compress history, but they may introduce errors that persist across turns. Include provenance for any fact reused later. Set a bounded lifetime for sensitive state and ensure deletion covers traces, caches, and derived summaries.

The system prompt should state the role, policy order, evidence boundary, response contract, escalation conditions, and prohibited behavior. Keep account authorization and irreversible action policy in code. Provide only the tools and context required for the current intent. A giant universal prompt increases conflict, token use, and the chance that one instruction weakens another.

SYSTEM ROLE
You are the first-response support assistant for Acme.

POLICY ORDER
1. Enforce account permissions and tool policy.
2. Use only the supplied account facts and approved knowledge.
3. Escalate when a required fact is missing or policy requires review.
4. Never promise an outcome that needs human approval.

RESPONSE CONTRACT
- Answer the direct question first.
- Cite the approved source for policy claims.
- State the next action and expected handoff.
- Ask at most one clarifying question.

ESCALATION OUTPUT
Return a structured escalation with reason, urgency, facts gathered,
sources checked, and the exact unresolved decision.

Write examples around hard boundaries: partial refunds, cancelled accounts, security incidents, angry customers, unclear identity, conflicting policies, missing evidence, and requests that combine several intents. Include examples of a useful refusal and a high-quality escalation summary. Avoid examples that reward verbosity; support answers should lead with the direct answer and the next action.

Version the prompt with model route, tool schemas, retrieval policy, and eval report. Prompt changes can alter escalation, tone, action selection, and policy interpretation. They require the same comparison and staged rollout as application code. Separate language style from decision policy so a tone update cannot quietly change when the agent promises an outcome.

Design for uncertainty

Confidence should come from observable evidence, not model self-report. Useful signals include retrieval coverage, source agreement, required account fields, policy match, tool-validation result, and eval performance for the intent. Combine them in explicit routing policy. A model saying it is confident is not a reason to skip human review.

A support agent fails when it escalates everything and when it resolves what it should escalate. Define mandatory escalation for identity uncertainty, security issues, legal threats, high-impact account changes, conflicting policy, missing required evidence, and actions requiring human approval. Add intent-specific thresholds rather than one confidence number for every conversation.

def decide_route(result, policy):
    reasons = []

    if result.permission_failure:
        reasons.append("permission_failure")
    if result.requires_human_approval:
        reasons.append("approval_required")
    if result.retrieval_confidence < policy.minimum_retrieval_confidence:
        reasons.append("insufficient_evidence")
    if result.customer_sentiment == "urgent" and result.account_risk == "high":
        reasons.append("high_risk_customer")
    if result.policy_conflict:
        reasons.append("conflicting_policy")

    if reasons:
        return {"route": "human", "reasons": reasons}
    return {"route": "respond", "reasons": []}

The handoff should include the customer goal, authenticated account context, facts gathered, sources checked, actions attempted, policy reason, urgency, and the unresolved decision. Do not make the human reread a long model transcript to discover the problem. Keep generated summaries linked to source turns so the agent can verify critical facts.

Measure missed escalation and unnecessary escalation separately. Missed escalation creates risk and incorrect promises. Unnecessary escalation increases queue load and customer effort. Review high-risk false negatives first. Then reduce low-risk false positives by improving retrieval, required fields, or policy clarity rather than instructing the model to be more confident.

Conversation volume is not the value unit. One conversation can contain several attempts, model calls, retrieval queries, retries, summaries, and a final human handoff. A cheap automated answer that is wrong and reopened can cost more than an immediate, well-prepared escalation. Tie every technical trace to the support outcome.

def cost_per_resolution(period):
    total_operating_cost = sum([
        period.model_cost,
        period.retrieval_cost,
        period.platform_cost,
        period.review_labor_cost,
        period.failed_automation_cost,
    ])
    verified_resolutions = (
        period.automated_resolutions
        - period.reopened_conversations
        - period.incorrect_resolutions
    )
    return total_operating_cost / max(verified_resolutions, 1)

def relative_cost(candidate, baseline):
    return cost_per_resolution(candidate) / cost_per_resolution(baseline)

Include model input and output, embeddings, reranking, vector storage, observability, platform infrastructure, human review, support handling after escalation, failed automation, and maintenance allocation. For comparison, normalize the current packaged-agent cost per verified resolution to 1.0. If the measured baseline is between 3.0 and 5.0 after accounting for reopen and review work, that is a meaningful replacement signal. If it is near 1.0, control or product fit may still justify ownership, but cost alone does not.

Break cost down by intent. Routine knowledge answers may be inexpensive while a multi-step account workflow uses large context, several tools, and human review. Route simple intents to smaller models or deterministic flows when eval parity is proven. Cache stable public knowledge with clear invalidation. Reduce repeated conversation context by extracting verified state. Cap retries and detect cascades. Each saving needs a quality guardrail.

Begin with shadow evaluation. Send a copy of eligible conversations to the candidate without showing its answer to customers. Compare output, route decision, sources, tools, latency, and normalized cost against the historical baseline. Review disagreements, then convert confirmed candidate failures into regression cases. Shadow traffic exposes current language and account states that the offline set missed.

Move to an assisted phase where support staff see the suggested response, sources, and escalation reason but approve the action. Record edits and rejection reasons. An edit is not automatically proof that the model was wrong; support staff may change tone or add information unavailable to the system. Classify edits so the team knows whether to repair knowledge, account integration, policy, prompting, or interface design.

Canary a narrow set of low-risk intents or tenants. Set explicit rollback thresholds for incorrect resolution, missed escalation, reopens, complaints, latency, and cost. Keep the packaged route available during the comparison. Expand by intent and risk only after the candidate clears the offline suite and live outcome threshold.

1. Shadow: no customer exposure; compare full traces and route decisions.
2. Assisted: support staff approve, edit, or reject candidate responses.
3. Canary: low-risk traffic receives the candidate with rapid rollback.
4. Expand: add intents after slice-level quality and economics clear thresholds.
5. Retire: remove the old route only after rollback and data-export needs are resolved.

The owner needs authority over the dataset, retrieval sources, prompt, tool policy, model routes, release gate, and dashboard. Support operations and engineering should share a weekly failure review during rollout, then move to a risk-based cadence. Review missed escalations, incorrect resolutions, changed policies, high-cost traces, user complaints, and grader disagreements.

Every confirmed production failure should become a labeled case with the exact account state and source versions needed to reproduce it. Every source needs an owner and freshness rule. Every meaningful model, prompt, retrieval, or tool change needs an eval comparison. Every exception needs an expiry. These are the mechanics that prevent an owned agent from becoming an unmeasured prompt hidden behind the help button.

Document the product boundary and support boundary. The agent should know which questions it answers, which actions it may take, and which decisions remain human. Tell customers when they are interacting with automation where appropriate, make escalation reachable, and preserve the evidence needed to investigate a wrong outcome.

• Define verified resolution and high-risk intents
• Baseline quality, escalation, reopens, handling time, and cost
• Keep identity and authorization outside model arguments
• Version approved knowledge and account-state contracts
• Evaluate required facts, prohibited actions, and escalation
• Normalize cost per verified resolution by intent
• Run shadow and assisted phases before customer canary
• Set rollback thresholds for quality, safety, latency, and cost
• Assign one owner to the dataset and release gate
• Turn reviewed production failures into regression cases

The replacement succeeds when customers receive at least the same quality, support staff inherit cleaner handoffs, the company can explain every action, and cost follows completed support work. Owning the code is useful. Owning that measured loop is the real advantage.