Access first, bounded actions, a person at every boundary: the design of an agentic customer-care platform.

A useful service product connects the conversation to the work needed to resolve it.

↗
Evidence before guidance
Current facts and relevant, approved knowledge.

✦
Reasoning within a boundary
Useful investigation with limited tools and authority.

✓
Confirmation before closure
A verified result or a named person owning what remains.

Three options. One deliberate starting point.

I would start with a representative-facing assistant for a small set of resolvable requests. Broader autonomy has to earn its place.

A

Knowledge assistant

Find and explain approved information.

Best fit

The answer is in a document.

Tradeoff

Cannot establish current account facts or finish a service action.

Useful for knowledge-only requests

B · My starting point

Bounded service assistant

Investigate across permitted sources, compare options and prepare a reviewable next step.

Best fit

The next lookup depends on what the evidence shows.

Tradeoff

Needs reliable tools, clear authority and a usable human handoff.

C

Autonomous resolution

Complete a narrow request without routine human approval.

Best fit

A low-risk, reversible action with proven controls.

Tradeoff

Greater exposure when evidence, policy or execution is uncertain.

Consider only after evaluated pilots

Where AI earns its place: interpreting a mixed request and choosing the next useful lookup. A known eligibility check, a fixed notification or a simple status response can remain deterministic.

The entry decision

Permission comes before personalization.

Before customer context, retrieval or an AI call

Authenticate. Authorize. Minimize.

Deny by default

1. 01 / Authenticate

   Who is making the request? Validate the requester and session. A claimed identity in a prompt is not proof.
2. 02 / Authorize

   Which case and data may they access? Check account/tenant, role, purpose and resource permissions on the server.
3. 03 / Minimize

   What does this task actually need? Allowlist fields, remove unnecessary identifiers and keep credentials out of context.
4. 04 / Admit context

   Release only the permitted scope. Pass scoped evidence and capabilities to the router.
   Exception:

   Missing permission stops the path.

No authorization → no customer context → no AI execution. Recheck access on every retrieval and tool request. Apply the same controls to representatives and specialists.

The complete operating loop / Product + technical design

Resolve this contact. Improve the next one.

Smart routing connects the customer to the right capability. Reconciliation and reviewed feedback turn each interaction into evidence for a better service.

✦

One accountable service

Resolve today. Improve tomorrow.

A live service loop and a reviewed release loop, connected by evidence.

Human ownership at every boundary

Human and specialist escalation

The service operation is confirmed before resolution is reviewed. Improvement still needs evaluation and release approval.

A request for a person bypasses AI resolution. Each transfer carries the goal, evidence, attempted actions, unresolved state and accepting owner. If a team is unavailable, keep an owned callback or queue state; do not claim a completed transfer. In this design, three turns without progress also hand off, and a clinical, safety or authorization issue hands off at once.

Scripted trace / no live customer systems

Ready to follow the selected route

Play the route or step through each stage. This is a scripted design example.

Ready to follow the selected route. Play the route or step through each stage. This is a scripted design example.

Admit only authenticated, authorized context.

The contact enters through a channel adapter, but no customer records or AI call are released until identity and resource-level access are established. I would assemble only the fields needed for the permitted purpose. Voice transcripts receive the same access and data-minimization treatment.

Validated identity + allowed case/data scope + channel request

Minimal, scoped context and permitted capabilities; otherwise a blocked state

Implementation contract

Verify the session/token server-side, evaluate tenant/account/case permissions and policy, then construct an allowlisted context envelope. Credentials and raw security tokens never enter the model prompt.

Denied cross-account access, unnecessary fields, expired sessions and data-exposure incidents

The animation illustrates an intended operating model, not autonomous live learning. A reviewed change must pass evaluation and a release decision before it returns to customer service.

Implementation model

Two connected paths. One versioned system.

I separate the low-latency customer interaction from asynchronous quality review and improvement. Shared evidence makes the two paths traceable.

Serve the customer.

• Authentication + authorization gateway
  Channel adapter · validated identity/session · account/case permissions · purpose · minimum permitted fields
• Intent + routing policy
  Rules/classifier · risk · skills · queue capacity · explicit human request
• Retrieval + operational reads
  Approved SOPs → chunks → embeddings/index · hybrid retrieval + reranker · current-state APIs
• LLM orchestrator + tool gateway
  Versioned skill/prompt · bounded reasoning · typed tools · authorization rechecked per call
• Response + case workflow
  Evidence-backed reply · output/recipient checks · action receipts · authorized human handoff · pending state

⇄

Correlated evidence

Interaction + operation IDs
Approved evidence references
Model / skill / index versions

Minimize sensitive data. Enforce access on traces, review queues, training datasets and exports; keep credentials out of logs.

↻

Improve the system.

• Event stream + reconciliation worker
  Deduplicate events · correlate receipts · check final case state · handle late events
• Quality evaluator + score store
  Deterministic checks · provisional LLM rubric · ratings · evidence-linked dimensions
• Human review + cause classification
  Critical flags · disagreement · cohort samples · adjudicated labels · assigned owners
• Versioned change pipeline
  SOP/index · prompt/skill · tools/process · optional, governed model training
• Evaluation + controlled release
  Held-out tests · critical gates · canary/cohort comparison · stop/rollback decision

↺Only an approved version returns to runtime. Measure customer outcomes against the baseline; keep the previous version recoverable.

Event contract I would define

This abbreviated, synthetic contract establishes traceability. It is not an internal schema or a production-ready API.

{
  "interaction_id": "demo-contact-014",
  "event_id": "demo-event-007",
  "occurred_at": "2026-09-23T10:14:00Z",
  "stage": "outcome_reconciled",
  "route": "representative",
  "intent": "appointment_change",
  "access": { "decision_ref": "demo-policy-allow-004", "scope_ref": "demo-case-scope" },
  "operation_id": "demo-operation-002",
  "outcome": "pending",
  "evidence_refs": ["approved-note:3", "operation-status:2"],
  "versions": { "model": "candidate-A", "skill": "v3", "index": "v12" },
  "review": { "status": "required", "reason": "receipt_mismatch" }
}

Consumers deduplicate by event ID, distinguish event time from arrival time and reconcile updates against source state. Access references are traceability data, not credentials or reusable grants; downstream services recheck current permission. Sensitive payloads stay out of analytics events where a scoped reference is sufficient.

Engineering decisions I would test before scaling

Identity & access boundary

Reject invalid, expired or inappropriate credentials before fetching customer context or invoking the model. Deny cross-account/case access, revalidate changed scope and keep identity recovery separate from account disclosure.

Retrieval & output boundary

Enforce access filters before retrieval and recheck source permissions before including passages. Apply response field/recipient checks and sensitive-data redaction. Prompts, retrieved instructions and a confident model response cannot widen authority.

Execution boundary

Typed tools, server-side permission checks, idempotency and pending-state reconciliation. The read path remains useful when actions are disabled.

Evaluation boundary

Versioned rubrics, human calibration, outcome checks and an untouched evaluation set. Sample by intent, language, channel, risk and resolution status.

Release boundary

Compare candidate and baseline on quality, cost and latency. Assign rollout and rollback owners; a failed critical check stops promotion regardless of the average score.

From feedback to an improvement decision

A rating starts the review. Evidence determines the score.

I would compare the response, final resolution and overall contact quality, then segment the results to find the component worth improving.

Synthetic example / provisional assessment

A helpful response. An unfinished outcome.

Illustrative weighted rubric. Each dimension is scored 0–4.

Unresolved — no resolution credit

The aggregate helps triage. It never overrides an unresolved outcome or a critical failure.

Evidence · 4 / 4 · 30% weight

Retrieved guidance supports the explanation.

Resolution · 0 / 4 · 25% weight

The response promised a changed appointment; the scheduling record is still pending.

Policy & authority · 4 / 4 · 20% weight

The permitted scope was respected.

Communication · 3 / 4 · 15% weight

The next step was clear, but the promised confirmation did not arrive.

Handoff · 1 / 4 · 10% weight

A follow-up owner was missing from the handoff.

Inspect the human review decision

Reviewed cause / Execution / reconciliation

Keep the case open. Assign an owner, reconcile the scheduling record and fix confirmation handling before expanding automation.

This is an authored reviewer example. A separate LLM may assist assessment, but human calibration and business evidence are required to trust the score.

Segment before prioritizing

Compare intent, channel, language, complexity, risk, route, release version and final outcome. Review low scores, critical flags and disagreement alongside samples of successful contacts. Keep rating coverage, sample size and reviewer agreement visible.

Six improvement paths. Different owners.

The reviewed cause decides whether to change the LLM, its evidence, its tools or the service around it.

Observed gap

An approved procedure is missing or obsolete.

The process owner reviews the SOP. Publish a version with scope, effective date and provenance; chunk and index it. Invalidate stale entries and rerun retrieval/citation checks.

Versioned artifact

SOP version + index version + retrieval regression set

How I would judge improvement

Fewer unsupported or stale answers; stronger coverage on reviewed queries.

Optional model-learning branch

Reviewed examples → permitted dataset → train or fine-tune → held-out evaluation → limited release.

Updating an SOP in RAG changes the evidence available to the model; it does not retrain its weights. I would pursue model training only when the reviewed failure pattern justifies it and permitted data supports the experiment. Improvement has to be measured, not assumed.

Evidence in. Accountable action out.

The common components stay recognizable. The permitted records, business tools and decision rights change with the industry.

Entry requirement: authentication, case/data authorization and minimized context are established before this flow starts. Access is rechecked for evidence, actions and human handoffs.

◌

Illustrative customer request

“My service visit was cancelled. Can someone come tomorrow?”

Scripted demonstration

Authenticate, authorize, then understand

I establish identity and resource-level access before assembling customer context or engaging AI. I allow only the account/case records and fields needed for the permitted purpose. Conversational familiarity never grants access.

Deny by default; recheck retrieval and every tool action. Human escalation has the same access boundaries.

Follow a request through the design.

The boundary that changes with the industry

An equipment-safety concern goes to a qualified specialist.

A representative confirms the exact appointment with the customer. A goodwill adjustment would need its own authority.

The interfaces I would specify with engineering

Context & evidence

Authenticated scope, source authority, freshness and an explicit unavailable state. Retrieval-augmented generation (RAG) supports explanations; a source-system response establishes current operational facts.

Tools & authority

Typed inputs, restricted capabilities and server-enforced permissions. A tool protocol such as MCP can standardize connections; it does not replace business authorization or validate a customer outcome.

Action & confirmation

A precise approved operation, a way to detect repeated requests and a status check when the outcome is uncertain. No confirmation means the interface must not display success.

Handoff & continuity

A named owner receives the customer goal, verified facts, attempted work and open questions. Case notes remain reviewable, with a distinction between proposed and completed actions.

I align the service around the decision.

A technically connected system is only useful when the people running it agree on responsibility, exception handling and a workable release.

Customer care & operations

Make the work usable.

Observe real service work, define escalation ownership and test whether the assistance reduces effort. Agree training, staffing and a manual fallback.

Engineering, design & data

Make the behavior dependable.

Specify evidence and action contracts, expose uncertainty in the interface, and connect traces to quality and service outcomes.

Legal, compliance & domain safety

Make authority explicit.

Review allowed data, customer communication and action permissions. Bring patient-safety partners into healthcare scope decisions; keep clinical judgment with qualified professionals.

First / Learn

Read-first assistance

One service queue and a few supported requests. Compare with current tools before changing how work is authorized.

Next / Validate

Controlled actions

Add a reversible action after evidence quality and handoff behavior meet agreed criteria. Exercise failure and recovery paths.

Then / Expand

Earn broader scope

Expand by request type when customer benefit, reliable completion and operating cost support the decision.

Release decisions and the cases I would test

Before a pilot

Missing and conflicting evidence; changed customer scope; rejected approval; unavailable tools; uncertain execution; repeated requests; a handoff without losing context.

Before expansion

Evaluate on held-out scenarios and a limited service cohort. Review accuracy and representative corrections by request type. Agree stop conditions and action-disable ownership before launch.

If the model is unavailable

Keep the service usable with verified records, manual knowledge access and a clear owner. The support operation should not depend on an AI suggestion arriving.

Measure resolution. Then decide what deserves to scale.

These are proposed measures and decision signals—not reported results. I would agree the cohort, observation window and baseline before a pilot.

Proposed north star

Confirmed resolution without avoidable repeat contact.

Eligible contacts with a confirmed resolution and no same-issue repeat contact in the agreed window ÷ eligible contacts. Check exclusions and hard cases separately. Customer effort remains a separate guardrail: repeated explanations and customer-reported ease.

Customer outcome

Repeat-contact rate

Same-issue repeat contacts / eligible contacts.

If speed improves but repeat contact rises, investigate quality before expanding.

Operational outcome

Confirmed completion

Verified completed operations / eligible attempted operations.

If confirmation is unreliable, prioritize integration and recovery over more intents.

Service efficiency

Time to useful guidance

Elapsed time to an evidence-backed next step, including the slow tail.

If delay comes from source systems, fix that constraint before adding model complexity.

Unit economics

Cost per resolved case

(Service labor + AI + integration + rework cost) / verified resolutions.

Compare the full cost with the baseline; faster handling is not automatically cash savings.

Decision quality

Unsupported guidance

Suggestions with unsupported material claims / reviewed suggestions.

Separate missing knowledge, bad retrieval and reasoning errors before funding a fix.

Control quality

Unauthorized or repeated actions

Confirmed control failures / attempted actions, with individual incident review.

Disable the affected capability and investigate; a favorable average is not clearance.

The learning loop

Feedback becomes a release decision.

I would review accepted suggestions as well as corrections. Representative acceptance alone does not prove correctness.

• 01 Observe
  Customer and operator signals
• 02 Investigate
  Confirm the cause and owner
• 03 Prioritize
  Knowledge, tools or experience
• 04 Evaluate
  Test a versioned change
• 05 Release
  Limited rollout, then measure

Reviewed corrections can improve knowledge, prompts, tools or workflow. They do not automatically retrain a model.

What this design makes visible

Product leadership livesin the boundaries and the tradeoffs.

I connect the service problem, architecture choices, customer experience and operating measures so the team can decide what to build—and whether it is working.

Scope and public technical references

This is a portable design example based on my product architecture experience. It uses fictional customer requests and does not reproduce employer systems, internal procedures, source documents or performance figures. The animation is a scripted explanation, not a connected service.

Public background: Anthropic: agent and workflow tradeoffs ↗ · MCP: authorization boundaries ↗. Additional background: Microsoft: hybrid keyword and vector retrieval ↗ · Anthropic: agent evaluation and human calibration ↗. OWASP: authorization checks ↗ and sensitive information disclosure ↗ inform the access and data boundaries. These references support general concepts, not my employment history or performance claims. The illustrated contracts, scenarios and scores are newly authored examples.

A service interaction may require account facts, policy interpretation and a business action. Those responsibilities often span several teams and tools. I focus the product on helping a representative assemble the evidence and move the issue to a clear outcome.

Before investing, I would interview customers after resolved and unresolved contacts, observe representative workflows, sample repeat-contact reasons and map where time is spent: finding information, interpreting it, deciding, executing or documenting. That separates a knowledge problem from a broken integration or an authority gap.

The opportunity I would test
Can bounded assistance reduce customer effort and avoidable rework while preserving decision quality?