Skip to main content
BlueprintsDepartments

Customer service

A proposed workflow for customer service. Revised 17 September 2026. The roles below are design options, not claims that these agents are deployed or that multiple agents are necessary.

By Murali SidLinkedInPublished Updated

The business opportunity

A customer disputes a bill. The agent needs the account record, the applicable tariff or contract, and the earlier conversation.

Resolve a customer problem: Verify the customer, then Gather account facts, then Explain the issue, then Approve a remedy, then Check resolution.

Start with the simplest useful solution

Compare the agent with searchable help articles, a billing calculator, and established escalation rules. Use the same representative cases and count human review, errors, integration, and ongoing operation. Add an agent only where choosing what to investigate or handling varied evidence improves the result.

Proposed responsibilities

Start with one agent and ordinary tools. Separate a responsibility only when it needs different permissions, independent review, or its own operating schedule. The autonomy and learning positions are starting choices to test, not certification levels.

How the architecture supports the task

Knowledge and memory (direct: a governed knowledge base, never model memory), human oversight (direct: escalation to a real queue), observability and audit trail (direct: conversations are legal evidence), tool gateway (direct), identity and policy (direct: a separate edge on the shared policy service), evaluation and release (direct: customer escalations label failures for free, making this the highest-value trace source in the enterprise), runtime (supporting).

Controls and human decisions

Require account verification before disclosure. Apply refund limits outside the model. Let the customer reach a person.

Give every tool call a task identity, a limited permission scope, and a recorded result. Before a write, check that the source record has not changed. Stop when required evidence is unavailable, the task budget is reached, or a proposal exceeds the authorised scope.

A useful investigation loop

Observe the exception, identify the missing fact, request that evidence, and check whether it changes the proposed action. Repeat only while there is a concrete unanswered question. End with a reviewed proposal, a confirmed result, or an explicit request for human help.

Economics and measures

Measure resolution and repeat contact together, time to a person, disputed answers, and cost per resolved issue.

Agree the baseline with the process owner. Count value only after the outcome is confirmed. Compare the value of recovered time and improved outcomes with the full cost of tools, models, evidence preparation, supervision, and correction.

Limits to test

A contained conversation is not necessarily a resolved issue. Test difficult cases, language differences, and incorrect source records.

Evaluate ordinary cases, uncommon failures, conflicting evidence, and recovery after an interrupted action before expanding authority.

External reading

The workflow above is the guide's proposal. These sources support the general investigation and risk-management methods; they do not validate the proposed business result.

Sources reviewed 17 September 2026.

Cite this page

Written by Murali Sid, Founder and AI Systems Architect, last updated 15 October 2026. Licensed CC BY-SA 4.0, so quote it freely with attribution.

Murali Sid (2026). Customer service. Agentic Architecture Skills. https://www.agenticarchitectureskills.com/library/blueprints/departments/customer-service

Machine-readable version of this page: /library/blueprints/departments/customer-service.md

On this page