Servicing agent
How an end customer's question becomes an answer supported by evidence, or a handoff to a human who owns the next step.
Start with an approved, read-only pilot. For example, answer product questions using current, approved knowledge articles. Add private account or ticket-status lookups once the application can enforce access permissions and obtain data that is fresh enough for those questions. Actions that change business records, such as approving a return, need a separate approval and execution path later.
Before building: agree with the enterprise client on the business goal, measure today's request volume and service outcomes as a baseline, and choose the request categories (intents) the pilot will support. Identify who owns data quality and access, policy decisions, support operations, and technical delivery so each decision has an accountable person or team. This page proposes an interview design; it does not describe an existing Salesforce deployment.
One request, two bounded model calls
Follow top to bottom. Each arrow names the data passed from one step to the next. Select a step to read what it checks and what happens if it cannot continue. Both diagrams fit the page width.
The router gets the end customer's verified identity from the authenticated session, stored in application state. The model's output cannot set that identity. The application also keeps the original request, access scope, and retrieved evidence available to later steps; each arrow shows the main output, rather than every field carried forward.
Product guidance · ticket status
Clarify · unsupported
No tools granted by model output.
Route proposal only.
Knowledge searchCase lookupLive status API*Snowflake query
*Only if the enterprise client has one.
Authorized facts · source IDs
Policy version · as-of time
Retrieved content is data.
It cannot grant tool permissions.
request
End customer asks for help
Session context + requestHuman request bypasses models
intent
Propose an intent and parameters
Schema-constrained proposalNo private record access yet
+ access
Allowlist, identity, record permissions
Public knowledge or authorized private-data workflowBlocked → safe fallbackevidence
Fetch only what this intent needs
Bounded calls + timeoutsAccess filters enforced in toolsUnavailable → fallback
evidence
Freshness, applicability, missing facts
Policy authority + conflict flagsUse approved rules where possibleUnclear → human review
answer
Explain supported facts and limits
Answer + evidence referencesNo business writes
+ send
Validate output, then deliver
Append response + case eventAnswered ≠ resolvedInvalid → fallback
The model proposes a route and writes an answer; application code decides what may run. Each model call has a defined job, and tools have limits on data, time, and retries. For an exact ticket-status answer, a template can insert verified fields directly, removing the need for the second model call. Public knowledge questions do not require account authentication unless the content itself is restricted.
When the normal path stops
The flow stops trying to answer automatically if the end customer asks for a person, an access or evidence check fails, the available information is unclear, or a tool reaches its time or retry limit. The application explains the limitation and follows a predefined fallback, such as secure verification or a handoff to the enterprise client's service team. The handoff includes the context that team is permitted to see.
+ create handoff
Reason, permitted evidence, actions tried, next owner
Offer secure verification for access failures.No private information leaks in the fallback.
and decides
Named queue / owner, response expectation, exception authority
If nobody is available: offer an owned case or callback; never claim transfer succeeded.+ approved decisions
Both automated answers and human outcomes enter this record
Source refs, approval scope, expiry, outcome.Access-controlled system of record.
authorized request
Return to step 01; retrieve relevant state again in step 04
Recheck identity, scope, expiry, and policy.Case memory does not bypass the gates.
What each step owns
| Step / owner | Input → output | Control and failure behavior |
|---|---|---|
| 01 · Channel adapter | Receives the message and channel/session information. Packages them into a request envelope, the data passed to the workflow, with verified identity if available. | Check that the channel and session are valid. Use rate limits to control request volume, and send the model only the information needed to classify the question. Keep credentials and unrelated account data out of that input. An explicit request for a human goes directly to the service path. |
| 02 · Intent model | Reads the question and supported intent descriptions. Proposes a category and inputs, or indicates that clarification is needed. | A schema-constrained response uses a fixed output structure and allowed intent names, such as ticket_status. It is a proposal for code to validate. If a ticket reference is missing, ask for it within a fixed clarification limit, then route the request again. If the request is unsupported, explain the pilot's scope and offer an appropriate service option. The model cannot grant tool access or establish identity. |
| 03 · Workflow router | The model's proposed intent and inputs + trusted session → an approved workflow with checked inputs. | Application code checks that the intent is supported, the inputs have the required format, the workflow is enabled, and the end customer can access the requested record within the correct enterprise client. Identity and tenant come from the authenticated session. Tools enforce those permissions again when querying. Public FAQs need no account authentication. See the ticket example and each check explained. |
| 04 · Read adapters | Checked inputs + trusted access scope → a limited collection of retrieved facts and source details, called a bounded evidence bundle. | Backend connectors fetch the information the approved workflow needs from a knowledge base, status API, Snowflake, or case system. Each connector enforces permissions, uses parameterized reads, and limits returned data, waiting time, and retries. It returns facts with source IDs, versions, timestamps, and access labels for step 05 to check. See the ticket example and technical terms explained. |
| 05 · Evidence / policy gate | Checks the retrieved evidence against this intent's requirements. Passes usable facts onward, or gives a reason to clarify or hand off. | Check whether the policy is effective and applies to the product and region, whether required fields are present, and whether the data meets the agreed freshness requirement. Pipeline freshness means how recently the source was refreshed, which differs from when a ticket last changed. Code can apply approved structured eligibility rules. A detected policy conflict or unresolved interpretation needs human review; passing field checks does not establish the meaning of every policy passage. |
| 06 · Response model | Uses permitted facts, source reference IDs, and response rules to produce a grounded draft, or abstains when it cannot support an answer. | Give the model only the context needed for this answer. Articles and transcripts are evidence to read, not instructions that can override application rules. The model has no execution credentials, write tools, or authority to grant exceptions. If composing the answer exposes an unresolved ambiguity, route it for review. |
| 07 · Response boundary | Checks the draft against the evidence and delivery rules, sends an acceptable answer, and appends an event to the case history. | Validate the output schema (required response structure), source references, and prohibited fields. Compare exact structured facts, such as status values, where possible. A real citation ID can still accompany an unsupported claim, so free-text answers also need testing and review based on observed failures. Use templates for exact fields where practical. Record whether sending succeeded; a delivery failure must remain visible. |
| Handoff service | Uses the failure reason and permitted context to create an assigned case or queue item, then tells the end customer what happens next. | Include the intent, evidence references, checks already performed, and next action, while limiting sensitive information. Name the team or person responsible and set a response expectation. Record whether the queue accepted the handoff. If it failed, say so and use the established service fallback. Queuing a case does not mean its problem is resolved. |
| Authorized reviewer | Reviews the handoff and records a resolution, an approved exception, a rejection, or a request for more information. | Check that this reviewer has authority to make the decision. Store who decided, why, which records or actions it applies to, any conditions, and when the approval expires. The service team must still follow identity and access requirements when handling the case. |
| Case / event store | Saves response events and approved human decisions so a later authorized request can retrieve the relevant history. | Keep answered, awaiting review, and confirmed resolved as separate states. On the next contact, retrieve the current policy and check whether a prior approval still applies before using it. An LLM-generated summary may help explain the history, but only an authorized decision record establishes approval. |
Step 03 explained: the workflow router
The workflow router is application code that checks the model's proposal and selects which predefined workflow can run. Suppose the end customer asks, “What's happening with ticket 12345?” The intent model proposes ticket_status with ticket reference 12345. Before fetching anything, the router checks:
| Check | Plain meaning | Ticket example |
|---|---|---|
| Intent enum | A fixed list of supported intent names. | Is ticket_status a category this application supports? |
| Argument schema | The required inputs and their permitted format. | Is a ticket reference present and correctly formatted? Reject extra fields, arbitrary SQL, or instructions where a reference is expected. A correctly formatted reference still needs access checks. |
| Allowlist | The workflows and tools enabled for this pilot and channel. | Ticket lookup is enabled. The model cannot invent an action such as issuing a refund. |
| Tenant boundary | Keep each enterprise client's records isolated. | Only look within the company associated with the trusted session. A ticket from another company is outside that boundary. |
| Record access | Check permission to see the particular record within that company. | Is this authenticated end customer permitted to see ticket 12345? Being in the correct tenant alone is insufficient. |
The authenticated session supplies identity and tenant. The model cannot establish who the end customer is or grant access. After validation, the router passes checked inputs to the scoped ticket-lookup tool. The tool restricts its query to the correct enterprise client and records this end customer may see. Record-level permission checks can happen within that lookup, before any private ticket details are returned.
If a required input is missing, ask for clarification. If authentication is needed, use the approved verification flow. If access is denied, stop without revealing private record details; a human handoff does not override permissions.
“The model proposes an intent and inputs. A deterministic router validates them, checks that the workflow is enabled, and enforces tenant and record permissions before invoking a scoped tool.”
Step 04 explained: read adapters
Read adapters are backend connectors that fetch information from the enterprise client's systems. Each adapter knows how to talk to one source, enforce access, and return the fields this workflow needs. “Read” means this step retrieves information; it does not change a ticket, approve a return, or issue a refund.
Ticket example: step 03 approves the ticket-status workflow with ticket reference 12345. The application supplies the trusted tenant and end-customer access scope. A ticket-lookup adapter uses those inputs to call an approved API or run an approved query. It fetches only an authorized ticket and returns permitted fields, such as its status and last update, together with source details. If the API supports only broader service credentials, the backend must still enforce the end customer's permissions.
| Technical term | Plain meaning | How it works here |
|---|---|---|
| Adapter / read tool | Code that connects the workflow to a particular data source. | A knowledge-search adapter finds product guidance. A status API adapter retrieves operational status. A Snowflake adapter queries suitable records or history. A case-lookup adapter retrieves prior decisions. Use only the adapters this intent needs. |
| Scoped query / access filters | Restrict which records and fields the lookup can return. | Apply the trusted tenant and record-access rules inside the query or backend lookup. Fetch only permitted fields. The model cannot broaden that scope. |
| Parameterized read | Supply input values separately from the query's instructions. | Use a parameter placeholder in an approved query and supply 12345 as its value, rather than concatenate the reference into SQL. The database treats it as data. The backend must also control allowed tables, columns, and API endpoints; parameter binding alone does not enforce permissions. |
| Bounded evidence bundle | A limited collection of retrieved facts or excerpts, packaged with their source details. | Return the allowed ticket fields or relevant article passages, rather than the entire account history. This is input for the evidence gate, not an automatic claim that everything retrieved is current or authoritative. |
| Source IDs, versions, timestamps, access labels | Metadata explaining where information came from, which version it represents, when it was updated or refreshed, and who may use it. | Keep the ticket or article reference, available version, source update time, warehouse refresh time where relevant, and access restrictions. Mark missing metadata as unknown. A ticket's last change is different from the warehouse's last refresh, and fetching data now does not prove it is current. |
| Result limits | A cap on how much data a tool can return. | Limit rows, fields, and article passages. If a result is truncated or incomplete, mark that explicitly so later steps do not treat it as complete evidence. |
| Timeout | A maximum waiting time for a source to respond. | Stop waiting when the configured limit is reached. Return a clear timeout outcome rather than leave the request running indefinitely. |
| Retry budget / explicit failure | A fixed limit on repeat attempts, with a clear outcome when retrieval cannot finish. | A temporary connection error may justify another attempt, within the configured retry and time limits. A permission denial needs the access fallback. Internally, record whether data was unavailable, denied, not found, or incomplete. Explain the limitation to the end customer without revealing whether a private record exists. |
Source choice depends on the question. Approved knowledge search supports product guidance. A live status API can support current status if the enterprise client has one and its data meets the requirement. Scoped Snowflake reads may suit history or sufficiently fresh warehouse data. Case lookup supplies prior notes and approved decisions. The backend controls credentials and approved endpoints; the model does not get a general SQL console or permission to fetch arbitrary URLs.
The adapter passes its results to step 05, the evidence / policy gate, which checks freshness, policy applicability, and missing or conflicting facts before an answer can be composed. Retrieval failure follows the defined fallback or human-handoff path.
“Approved read adapters retrieve only the data this request needs. They enforce access inside the lookup, use parameterized reads, and bound result size, timeouts, and retries. They return facts with source references and timestamps so the next gate can decide whether those facts support an answer.”
Sources have different authority
Approved policy / knowledge
Use the approved version that is effective for the relevant product and region. Its owner is responsible for resolving unclear or conflicting guidance. For example, an expired return-policy article should not determine today's eligibility.
Operational records / Snowflake
Choose data that is fresh enough for the question. A warehouse refreshed daily may suit historical activity but fail a current-status requirement. A live API can help only if its underlying data is current and this end customer is authorized to access it.
Transcripts / prior case notes
These show what happened or what a representative promised. To act on an exception, retrieve an authorized decision record stating its scope and conditions. A promise written in a transcript cannot by itself authorize an exception to policy.
Four follow-ups you can explain from the diagram
| Situation | Decision point | What you say in the interview |
|---|---|---|
| “Where is my ticket?” but data is 24 hours old | Step 05 · Freshness gate | “I agree with the enterprise client how fresh ticket-status data must be. If an authorized current source is available, I use it. I give a timestamped, as-of answer only if older data meets that requirement. If it does not, I explain that I cannot verify current status and arrange a handoff. Adding a disclaimer alone would not make the data acceptable.” |
| A representative promised 60 days; policy says 30 | Step 05 → authorized human | “I treat the promise as evidence for an exception request. I send both the transcript and policy to someone authorized to decide. The agent does not approve the exception itself. I save the reviewed decision, including what it applies to and when it expires, so a later interaction can check it.” |
| The end customer contacts support again | Step 04 · Case lookup | “After checking identity and access again, the next request retrieves the relevant case history and approved decision. It checks that the approval is still valid and applies to this request. That memory lives in the enterprise client's record system, where it can be audited.” |
| The sponsor wants 70% containment | Outcome definition before rollout | “First I identify which requests the pilot can safely handle and measure today's outcomes as a baseline. Containment tells us how many interactions avoid human transfer, but those interactions may still leave problems unresolved. I also track verified resolution, repeat contact, cost, and CSAT. The pilot should improve service while keeping human help accessible.” |
Record outcomes, then measure improvement
At each stage, record a trace event: which request ran, which step completed, what evidence version it used, how long it took, and any error. These events help locate failures. Limit personal data in traces and restrict who can read them.
Also record what happened after the interaction: was the problem confirmed solved, was it handed off, or did the end customer return with the same issue? Agree on an observation window for repeat contact, such as seven days. Wait until each interaction has completed that window before including it in the final repeat-contact result. Otherwise, yesterday's answer could look successful simply because there has not been time for the end customer to return. Successful delivery shows that a response reached the end customer; resolution still needs the agreed evidence that the problem was solved.
| Business measure | What must be captured | Design connection |
|---|---|---|
| Cost per verified resolution | For the same group of requests (the cohort), add model, tool, infrastructure, allocated operating costs, and human effort. Divide that total by the number of requests verified as resolved. Include the cost of unresolved requests and escalations in that group's total. | Limits on calls and retrieval can reduce cost. Templates avoid unnecessary generation for exact facts. Useful handoffs reduce repeated work by human agents. Compare cost alongside service quality so a cheaper but less effective flow does not appear successful. |
| Resolution without repeat contact | Agree what confirms resolution, then track whether the end customer returns about the same issue during the observation window. Link contacts across channels where permitted. Calculate the result using cohorts whose full window has elapsed; no repeat contact alone does not prove resolution. | Fresh answers, useful handoff context, and saved case decisions help prevent repeat work. Seven days is an example window to agree with the enterprise client, based on how its service operates. |
| End-customer experience | Collect customer satisfaction (CSAT), the number of survey respondents, and the response rate. Also track failed transfers and cases where the end customer has to repeat their explanation. | Explain limitations clearly, make human help accessible, and give follow-up an owner. Report how many people answered the survey, because satisfied or dissatisfied respondents may not represent everyone who used the service. |
Rollout: establish today's baseline and responsible owners, then inspect historical cases to check the proposed flow. Start with supervised use, or shadow mode where the system produces outputs without sending them to end customers. Next, release to a limited group and compare results with the agreed success criteria before expanding. Keep a switch that disables the affected automation and returns requests to the established support process if needed.
Design notes
Why keep the model calls narrow?
Give each model call a specific job. The first maps the end customer's wording to a supported intent; the second turns the permitted evidence into an answer. Application code checks identity, controls tool access, and enforces business permissions. When a result is wrong, this separation helps identify which step failed. For exact ticket-status fields, a deterministic template can insert the values directly and remove the second model call.
What happens if we later allow returns or other writes?
A write changes a business record, such as issuing a refund. Add a separate action path after evidence review: check eligibility and current state, obtain required human approval and end-customer confirmation, then execute through a backend adapter limited to that action. Recheck the conditions just before execution.
Use an idempotency key, a unique request identifier the receiving system uses to prevent duplicate execution. If the request times out after a refund might already have been issued, check the system of record before retrying. Record the confirmed outcome, and reject approvals that were denied or have expired.
Which safeguards improve the basic flow?
Set limits on retries and clarification turns so a request cannot loop indefinitely. Let the end customer ask for a human at any stage. Tools must enforce tenant and record permissions even after the router has checked them, and retrieved text must remain evidence rather than instructions.
Preserve source timestamps so freshness can be checked, and record whether a handoff was accepted so requests do not disappear between teams. Track an answered question separately from a resolved underlying ticket: telling someone their ticket is pending does not resolve the issue that ticket represents. These are proposed design controls, not measured results.
How is quality improved over time?
Read actual request traces to see where failures occurred, such as choosing the wrong intent, retrieving the wrong article, or writing an answer the evidence does not support. Group observed failures by component and use them to choose focused checks. Record prompt, model, rule, and source versions so you can tell what changed between runs.
Review technical behavior alongside service outcomes. A flow can pass its format checks while still leaving end customers needing more help. This page describes the improvement process; it does not report results from a deployed pilot or supply an evaluation dataset.
Your 45-second walkthrough
“I would start with a read-only pilot for one service use case. The model interprets the question, then application code validates the route and checks access. Approved tools retrieve only the evidence that request needs. We check whether the data is fresh enough and the policy applies before composing an answer. If those checks fail or the end customer asks for a person, we send the relevant context to a responsible service owner. We save the response and any approved human decision so the next interaction can retrieve them. Before expanding, we measure whether problems were solved, whether people returned, and how cost and satisfaction changed.”
Prepared October 15, 2026. Visual style adapted from the Customs Packet Review System flow tab: gray model nodes, green application steps, pink human/input nodes, black arrows and dashed tool/context boxes. Interview context: recruiter sources SFDC-007 through SFDC-009. Architecture and controls shown here are proposals; component names indicate responsibilities, not existing source files. This page is local and makes no model or network calls.