Issue to resolution: make “resolved” mean the customer can move on

A customer reports that the system returned the wrong source document. A pleasant apology is not the resolution. Someone needs to reproduce the problem, find the affected output, correct it, explain the fix and establish whether the customer can now continue.

The support loop handles the coordination around that work. The prototype includes a ticket lifecycle, escalation into a linked case, goodwill-credit controls and customer-health changes. It is an experimental local workflow; the actual inbox, diagnostic tools and customer communications need live adapters and evaluation.

The ticket and the case are different

The ordinary path is:

new → triaged → context_loaded → draft_ready
    → awaiting_customer → resolved

A difficult ticket can instead create a linked case for investigation. That case retains the relationship to the original interaction and relevant account records. It can reach a draft resolution, request a goodwill decision or remain open while another loop supplies evidence.

I want the distinction because a support assistant can often prepare the right next step without being able to fix the underlying product. Escalation should preserve useful work already done, not reset the customer to “please explain the issue again.”

Walk a routine ticket in the prototype

from i2r.pipeline import build_i2r_pipeline

support, dispatcher = build_i2r_pipeline()
seed = support.seed("studio-demo")
result = support.resolve(seed, tenant_id="studio-demo")
assert result.allowed

The helper demonstrates legal state transitions. Its seeded facts do not prove diagnostic accuracy or customer satisfaction. The next evaluation needs real failure categories and a check that the claimed resolution matches the recorded action.

For the document-search example, the context bundle would include the question, returned answer, source references, document version, user permissions and relevant agreement. Personal or unrelated account data should not be included simply because the platform can retrieve it.

Give the agent a concrete resolution contract

A useful draft can contain:

{
  "issue": "wrong reporting period in cited evidence",
  "reproduced": true,
  "affected_result": "answer-042",
  "proposed_fix": "re-run retrieval with the accepted period filter",
  "verification": "source passage and period match the question",
  "customer_message_state": "DRAFT"
}

This is an example work packet. The diagnostic result needs an actual tool receipt or reviewer evidence; a model should not set reproduced merely because the description sounds plausible.

A sent explanation moves the case to a waiting state. Resolution requires the applicable evidence: a successful check, customer confirmation or an explicit closure policy. A scheduled follow-up should stop if the customer responds through another channel.

Goodwill is its own action

The local goodwill policy demonstrates a per-credit threshold of US$500 and an annual cap of US$2,000. An amount above the threshold or an amount that exceeds the running cap is denied on the automated path. The current comparison permits an amount equal to the threshold when the cap is respected.

These are prototype constants. Before applying the pattern, I would bind the limit to the account's actual entitlement, currency and approved policy. The running total must be computed from authoritative issued credits, not supplied by the agent. Concurrent requests also need to reserve against the same allowance atomically.

A credit recommendation, approved credit note and settled refund are different states. A support response must not say money has arrived merely because a credit object was created.

Support is a product signal

Repeated citation errors should create a product investigation with examples. Repeated confusion about a feature may need documentation or design work instead. The support loop can group evidence, but the product loop decides which improvement deserves investment.

This is also where account health changes become useful to renewal planning. The handoff should include the unresolved issue and customer impact. It should not consist only of a red score.

Evaluate the costly mistakes

My first support dataset would include a duplicate ticket, an already-fixed issue, a request beyond the customer's entitlement, a wrong-account reference, an unsupported refund promise and a case where the correct answer is to ask for one missing detail. I would score whether the action and explanation agree, not just whether the reply sounds empathetic.

The founder should receive exceptions with enough evidence to decide quickly. The platform earns autonomy by reducing repeated context gathering while keeping unresolved work visible. Closing tickets faster is useful only when the closure is correct.

Give the support agent evidence-gathering tools first

For a wrong-citation complaint, the useful tools are read_answer, read_source_version, read_permissions, find_related_case and prepare_reproduction. A refund tool is not needed to establish the failure. A code-deployment tool is not needed to explain which result is affected.

The context builder should collect the customer's question, generated result, cited passage, retrieval filter and release version. It should exclude unrelated account data. A model can then propose the smallest next diagnostic step, rather than produce a long generic apology.

A concrete reproduction packet includes the expected reporting period, actual source period and a stable test input. If that evidence is missing, the correct outcome is a request for the result reference. The agent should never claim it reproduced an error because the customer's description resembles a familiar issue.

Convert a support fix into a regression case

from company_lab.evaluation import verdict

expected = {
    "state": {"case_state": "AWAITING_VERIFICATION", "refund_sent": False},
    "forbidden_actions": ["promise_refund", "close_without_evidence"],
}
observed = {
    "state": {"case_state": "AWAITING_VERIFICATION", "refund_sent": False},
    "actions": ["prepare_reproduction", "draft_customer_update"],
}
assert verdict(expected, observed)["passed"]

This checks a structured outcome, not the tone of the reply. A separate reviewer can evaluate whether the explanation is clear and appropriate. Combining both scores into one average would hide a harmful action behind an empathetic message.

Reserve goodwill against the same allowance

The earlier threshold example is easy to implement incorrectly under concurrency. Two agents can each read S$1,800 already issued against a S$2,000 annual cap and each approve S$200. The pure rule passes both requests individually while the combined result exceeds the cap.

The reference function is intentionally only a calculation:

from company_lab.business import credit_allowed
assert credit_allowed(20000, 180000)
assert not credit_allowed(20000, 190000)

A real action must lock or atomically reserve against the account allowance, then retain the reservation until the credit is issued, rejected or reconciled. The amount and currency need the same unit definition as the allowance. The model may recommend goodwill, but it should not supply the authoritative running total.

If the provider call times out, preserve the reservation while the outcome is uncertain. Releasing it immediately could permit a second credit before discovering that the first one succeeded. An operator may later resolve the uncertainty with a provider receipt and a recorded decision.

Keep customer communication consistent with action state

The message template should depend on confirmed facts. “A credit has been approved” is different from “a refund has settled.” If the action is still under review, the customer should receive the relevant expectation without an invented completion claim. The communication draft can be checked against the operation record before sending.

The support loop also needs to notice cross-channel updates. A customer may reply by email to an issue opened in a portal. Link the new interaction by verified account and case reference, then cancel any stale follow-up. Matching only the subject line can join unrelated cases; matching only an address can collapse several open issues into one.

The founder's exception should fit on one screen

A useful review packet contains the customer impact, reproduced facts, attempted actions, current unresolved question and proposed next step. Include the accepted commercial promise when it affects entitlement. The founder should not need to reopen every source system to understand why the agent stopped.

The test exercise is a customer asking for a refund while the payment outcome is still unknown. The correct workflow gathers and reconciles evidence, prepares a response and holds any financial action. A fluent promise to refund immediately should fail the evaluation even if the customer would like to hear it.