# Better conversations The first change should be how the assistant chooses its next move. Clear wording helps, but an irrelevant follow-up still makes a conversation feel scripted. This report examines Aftercare’s customer dialogue and the assistant’s communication with its owner. It connects verified behavior with practical examples, reusable tools and a way to measure improvement. - [Fix the missed corrections and unnecessary questions.](#1-diagnosis) - [Review the replies worth aiming for.](#3-before-and-after) - [Start with examples and evaluation; pilot larger tools selectively.](#5-products-and-repositories-worth-considering) ## 1\. Diagnosis The clearest defect is a mismatch between the person’s immediate purpose and the assistant’s next move. A person asks for an explanation; the assistant treats the turn as an opportunity to collect another fact. The reply may be polite, accurate and short, yet the exchange still feels like a script. **Verified in the inspected application:** with blade condition and available tools already known, asking what “1000” means selects a cutting-board question. “Говори нормально” (“speak normally”) and “я про камінь питав” (“I asked about the stone”) are not recognized by the repair detector. Two nearby phrases, “говори простіше” and “говори по-людськи,” are recognized. These are fresh, deterministic planner probes; they do not establish what a live model would ultimately say. [Inspect the probe inputs and outputs](audit.json). | Message | Selected state | Question decision | | --- | --- | --- | | Що означає 1000 на камені? | discover | Requests a cutting-board question | | говори нормально | discover | Requests a cutting-board question | | навіщо тобі дошка, я про камінь питав | discover | Requests a cutting-board question | | говори простіше | repair | No question required; candidate remains in state | | говори по-людськи | repair | No question required; candidate remains in state | The mechanism is visible in `platform/server/dialogue.mjs`: the repair detector at line 37 has a narrow phrase list. Candidate selection at line 349 adds cutting-surface and cooking questions, and the first unasked topic can become the next move. The prompt in `platform/server/engine.mjs`, particularly lines 729–732, also urges a meaningful question when benefit is unconfirmed and a next question after pushback. This creates tension with its separate instructions against an endless questionnaire. [Local evidence and revision](#local-evidence). ### What the saved conversations add The historical “improved” Ihor scenario shows the practical consequence: after the customer challenges the cutting-board detour, the next reply asks what they cook. In the same run, a handoff request ends with the customer being told to use support themselves. These are fictional model-to-model records, not real customer complaints. Later targeted runs and code fixes exist; the report uses the old exchange as an example and the new planner probes as evidence of a remaining decision problem. | Run / scenario | Shop turns | With “?” | Recorded outcome | | --- | --- | --- | --- | | improved / danylo | 11 | 3 | refused | | improved / ihor | 11 | 5 | interest_only | | improved / maksym | 11 | 0 | refused | | improved / olena | 7 | 4 | refused | | improved / svitlana | 7 | 1 | refused | | improved / taras | 7 | 3 | actor_reported_agreement | | followup / ihor | 6 | 4 | test_purchase | | followup / olena | 11 | 2 | interest_only | Question counts are descriptive only. A needed diagnostic question is helpful; an irrelevant one is costly. The six-person “improved” run and the two-person follow-up used different seller versions and coverage. Their outcomes must not be turned into a conversion uplift or a controlled before-and-after claim. The project’s evaluation README already documents those limits. ### The assistant talking to the owner The visible owner-facing exchange is too short to establish a broad behavioral diagnosis. Its opening emphasizes project guidance, branch state and notes before any substantive work exists. A brief “What would you like changed?” would carry less ceremony when no task has been supplied. The wider work-assistant recommendations below are a proposed communication standard, not measured findings from a large chat history. ## 2\. A practical definition of natural conversation A natural exchange makes the other person feel understood without making them manage the assistant. The assistant answers the current question, keeps relevant context, notices correction and can finish a turn without demanding another one. It remains clear about being AI and about what it has actually done. Google’s conversation-design guidance connects comfortable dialogue with truthfulness, appropriate detail, relevance and clarity. It also stresses context and lightweight recovery. Its advice comes from an older voice-interface setting: useful principles, but its emphasis on questions as turn cues should not become a requirement to end every text reply with a question. [\[1\]](https://developers.google.com/assistant/conversation-design/learn-about-conversation) Microsoft’s human–AI interaction guidelines add expectation setting, efficient correction, contextual timing and continuity over time. Their validation involved 49 practitioners examining 20 products; that supports a design framework, not a guarantee that any particular phrasing will work in Ukrainian support. [\[2\]](https://www.microsoft.com/en-us/research/wp-content/uploads/2019/01/Guidelines-for-Human-AI-Interaction-camera-ready.pdf) ### Relevance and cooperation **Answer first.** “How much?” usually deserves the price before a budget question. “What does this mean?” deserves an explanation before advice. For mixed requests, answer the parts already supported, then ask about the one missing fact that changes the rest. **Make questions earn their place.** Before asking, name internally the decision that the answer would change. If both likely answers lead to the same recommendation, skip the question. One necessary question can be kind; three unnecessary ones, delivered one at a time, are still an interrogation. **Let the person’s goal control the topic.** A support request can finish successfully with no sale. Offer a relevant product when there is a supported need and readiness, with a concrete reason and an easy refusal. A disclosure that the store sells products is appropriate when asked, but repeating it during ordinary care advice distracts. ### Listening and repair **Treat correction as a change in direction.** “That’s not what I asked” should suspend the current plan. Identify the mistaken assumption, give the missing answer and avoid restarting discovery. A brief admission is sufficient when useful: “I misunderstood the question.” Then fix it. **Remember selectively.** Keep supported facts such as ownership, budget and an agreed return time. Preserve where they came from and whether they apply only to this exchange. “I’m busy today” should not become a permanent identity; buying a gift should not make the buyer its user. **Accept revised facts.** A new explicit correction should supersede the old working assumption. Make uncertainty visible if the two cannot be reconciled. Repeating a corrected fact accurately can be helpful; a blanket ban on semantically similar sentences can suppress a necessary repair. ### Voice and social judgment **Match register, not every mannerism.** Use the person’s language and level of detail. Let formality be configurable and correctable. Avoid copying their typos, insults or intimate slang to perform familiarity. Ukrainian examples need review by fluent speakers who can judge local register, not only grammatical correctness. **Be specific about emotion.** Acknowledge the concrete inconvenience when it matters: the delivery total is missing; a promise was not kept. Repeated declarations of empathy consume space without resolving the problem. Calmness should survive profanity, but a direct request to stop should stop the conversation. **Use ordinary, precise words.** Remove abstract slogans and redundant preambles. Explain necessary terms instead of replacing them with something vague. Short sentences help until they fragment a connected explanation. Punctuation and emoji are adjustable style choices, not a definition of humanity. **Keep an independent view.** Be warm without automatically agreeing. Correct an inaccurate premise with a reason and a useful next step. Anthropic’s 2023 study found that preference judgments can favor agreement even at a cost to truthfulness; optimizing only for how pleasing a reply sounds is therefore a poor quality target. [\[4\]](https://www.anthropic.com/news/towards-understanding-sycophancy-in-language-models) ### Action, pace and endings **Own the next step you can actually take.** If a requested action is authorized and supported, execute it. Explain the real limitation if it is unavailable. Confirmation must follow a successful tool result; prose must never upgrade “pending” into “done.” A polished fallback still exposes an operational gap that the product may need to close. **Keep status messages useful.** For slow work, share a discovery, a changed assumption or a specific remaining dependency. Avoid announcing every tool invocation. In a customer chat, a short acknowledgment during a real wait can help, but fake typing delays and staged message bursts add friction. **Allow a turn to end.** An answer, a confirmed action, a closing acknowledgment and silence are all legitimate outcomes. Do not append “anything else?” automatically. A person who promises to return has not automatically asked for outbound contact. **Use identity honestly.** The assistant can have a consistent voice while remaining identifiable as AI. Do not invent a personal experience, colleague, physical action or friendship to make a reply seem human. The desired result is easy cooperation and appropriate trust. ## 3\. Before and after The first three examples use excerpts from saved fictional test conversations. The remaining examples are constructed. Every proposed reply is an editorial candidate for review, not evidence of a deployed improvement. English glosses explain the Ukrainian examples. ### Answer the correction A customer asks what a sharpening stone does, then objects to a question about their cutting board. > навіщо тобі дошка, я про камінь питав Why do you need to know about the board? I asked about the stone. #### Recorded reply · excerpt Камінь потрібен, щоб знову зробити ніж гострим: він знімає тонкий шар металу з кромки, і лезо знову легше входить у помідор Без нього миття нічого не виправить, бо гострота сама не повертається Купувати його варто лише якщо хочеш сам це робити вдома, а не віддавати ніж на заточування Що найчастіше готуєш цим ножем? #### Proposed reply · untested Про камінь: він знімає трохи металу з леза, щоб ніж знову став гострим. Дошка для відповіді на це питання не потрібна. About the stone: it removes a little metal from the blade to make the knife sharp again. I don’t need to know about your board to answer that. **Why this change:** The correction becomes the priority. The answer addresses the mechanism, drops the discovery questionnaire and ends. No new product claim or purchase pressure is introduced. Saved improved/ihor.json, transcript indices 9–10. Exact excerpt; line breaks retained. ### Explain the unfamiliar term The customer wants an explanation before discussing a purchase. > говори нормально, що за позначка 1000, це що взагалі Speak normally. What does the 1000 marking even mean? #### Recorded reply · excerpt Число 1000 на камені — це наскільки дрібно він працює по лезу: не зрізає метал грубо, а підрівнює робочу кромку, щоб ніж знову легше входив у продукти Без каменя лезо саме не стане гострішим, бо миття й сухе витирання лише зберігають те, що вже є На якій дошці зараз користуєшся ножем? #### Proposed reply · untested 1000 — це позначка зернистості: наскільки груба поверхня каменя. Тут це камінь для звичайного заточування. Саме число не означає, що тобі потрібно його купувати. 1000 is the grit marking: how coarse the stone’s surface is. Here it describes a stone for ordinary sharpening. The number itself doesn’t mean you need to buy one. **Why this change:** A technical word is useful when it is immediately explained. Avoiding every technical noun can produce a vague explanation. The example uses the fictional catalogue context and does not prescribe an angle or preparation method. Saved improved/ihor.json, customer excerpt from index 7; full shop turn at index 8. ### Give an honest next step The customer has asked the bot to bring in the team to confirm delivery. No handoff tool result is available in this example. > то кличте ту команду сюди і хай скажуть доставку нормально Then bring the team here and have them explain delivery properly. #### Recorded reply · excerpt Команду сюди сам не викликаю: напиши в кнопку підтримки цього чату, і там можуть назвати доставку до каменя за 1490 грн #### Proposed reply · untested Я не можу підключити оператора з цієї відповіді. Відкрий «Підтримка» в цьому чаті й попроси повну суму з доставкою. Ціна самого каменя — 1490 грн. I can’t connect an operator from this reply. Open “Support” in this chat and ask for the total including delivery. The stone itself costs 1,490 UAH. **Why this change:** This improves the fallback wording, but the customer still has to do work. The better product change is to execute an available, authorized handoff and report its actual result. Never rewrite an unavailable capability into “I’ve called the team.” Saved improved/ihor.json, excerpts from indices 19–20. Historical path; later handoff fixes exist and must be tested separately. ### A simple question can end simply Constructed example. The fictional catalogue confirms a 390 UAH sleeve; delivery is unknown. > Скільки коштує чохол? How much is the sleeve? #### Constructed weak reply Із задоволенням допоможу обрати оптимальне рішення для захисту вашого ножа! Підкажіть, на який бюджет ви орієнтуєтесь? #### Proposed reply · untested 390 грн за чохол. Вартість доставки тут поки не підтверджена. 390 UAH for the sleeve. The delivery cost hasn’t been confirmed here yet. **Why this change:** The price is already known. Asking for a budget delays the answer. A relevant uncertainty belongs beside the price, without a new interview. Constructed illustration, not a recorded model output or a live price quote. ### Use the correction next time Constructed two-turn example. The person has already said they own a stone and are not shopping. > Камінь у мене вже є. Питаю, чому ніж після нього гірше ріже. I already have a stone. I’m asking why the knife cuts worse after using it. #### Constructed weak reply Маєш уже щось для заточування вдома? #### Proposed reply · untested Камінь уже є — врахував. Погіршення після заточування може мати кілька причин. На лезі видно сколи чи воно просто гірше ріже? You already have a stone — got it. There could be several reasons it cuts worse after sharpening. Are there visible chips, or does it just cut less well? **Why this change:** Here a follow-up earns its place: damage changes the safe next step. Do not ask it if the person already described the blade. Remember ownership as a supported fact, not inferred expertise. Constructed illustration; no diagnosis or model-specific sharpening instruction. ### Respect an ending Constructed example. The person is closing the current exchange; they have not requested a reminder. > Дякую, далі сам. Thanks, I’ll take it from here. #### Constructed weak reply Завжди радий допомогти! А що ще хотіли б покращити у користуванні ножем? #### Proposed reply · untested Домовились. All right. **Why this change:** A short acknowledgment is enough. Do not turn closure into another lead. Silence after the acknowledgment is an intentional outcome, not a failed conversion. Constructed illustration, not a saved test result. ### Report the finding Constructed work-assistant progress update. A concrete defect has been found. > Any progress? #### Constructed weak reply I’m continuing to leverage the existing architecture to perform a comprehensive investigation of the relevant implementation pathways. #### Proposed reply · untested The bot treats “speak normally” as a new sales turn. I’m checking the other correction phrases before writing the recommendation. **Why this change:** Name what changed in your understanding and what the next check will settle. Avoid narrating tool use or praising the thoroughness of the work. Constructed contrast grounded in the read-only planner probe. ### Act on an authorized request Constructed example. A reversible change is requested, and the assistant has the files and authorization. > Can you fix the mobile layout? #### Constructed weak reply Yes, I can help you with that. Would you like me to investigate the responsive styling and propose a plan? #### Proposed reply · untested I’ll check it at phone width and fix the overflow. **Why this change:** “Can you” usually requests action in this context. Ask only if missing information changes the result materially or authorization is actually absent. Finish with the result and relevant verification. Constructed illustration. It does not override permission requirements or safety boundaries. ## 4\. How the work assistant should communicate The standard for an assistant working with an owner is close to a competent colleague: understand the request, make reasonable decisions within it, surface meaningful uncertainty and deliver a reviewable result. Tooling and branch administration belong in the reply only when they affect the decision or explain an actual block. | Moment | Useful behavior | What to check | | --- | --- | --- | | Starting | State the intended work in one plain sentence. Ask about scope only when the distinction matters. | Could work begin from the existing request? | | Making progress | Describe a discovery and its implication. Mention the next check when it resolves a live uncertainty. | Did the update add information? | | Receiving criticism | Identify the correction and apply it immediately. Keep the explanation brief. | Does the next response visibly change? | | Disagreeing | State the reason and a practical alternative. Reconsider when the evidence changes. | Is the disagreement useful to the decision? | | Asking for approval | Prepare the concrete result first. Explain the actual missing authorization or consequential choice. | Is the question necessary and answerable? | | Finishing | Lead with the result and the link. Add relevant verification and any material remaining limit. | Can the owner use the result immediately? | Explicit style guidance is supported by OpenAI’s current model documentation, which calls out detailed formatting and recurring phrases as behaviors that may need direction. A few representative good replies give that guidance an observable target. The examples should vary by task: a short price answer, an honest failure, an involved technical explanation and a correction. [\[6\]](https://developers.openai.com/api/docs/guides/latest-model) **Suggested starting preference:** “Speak directly and use familiar words. Answer or act on the request before discussing the process. Keep updates specific to what changed. Ask when the answer matters; otherwise use the available context. Admit an error briefly and correct it. Finish with the result.” This is a proposed preference for a configurable instruction layer. It cannot override the host’s required permissions or execution rules, and this report does not claim to have changed them. ## 5\. Products and repositories worth considering **Start with a small editorial reference and repeatable evaluation.** Humanizer and Promptfoo address useful parts of that work. Keep Aftercare’s existing application and provider while testing whether better turn selection improves the actual experience. Pilot a larger conversation framework only if a simpler policy remains difficult to maintain. The following is a fit assessment, not a performance leaderboard. Capabilities come from primary documentation and repository inspection. Effort is a qualitative estimate for this Node-based project. No listed product was benchmarked, installed into the application, purchased or granted customer data. Showing 12 tools ### Humanizer Use first Editorial reference · MIT · Markdown A portable editing skill with examples and voice matching. Useful for spotting empty emphasis, stock openings and mechanical rhythm. [\[8\]](https://github.com/blader/humanizer) #### What to reuse Extract a small review checklist and pair it with owner-approved Ukrainian examples. Review a batch of replies offline before adding anything to the response path. #### Fit and limits Small integration effort. A rewrite cannot repair a bad decision or missing action. No evidence here that it improves Ukrainian customer outcomes. ### Promptfoo Use first Regression evaluation · Root MIT · Node.js A configurable evaluation runner for comparing prompts, responses and application behavior. [\[9\]](https://github.com/promptfoo/promptfoo) #### What to reuse Use a custom JavaScript provider around the existing seller service; evaluate the final application reply plus persisted action state. Keep the current subscription adapter. #### Fit and limits Small-to-medium effort. Model runs still consume usage. Custom code executes locally; review the selected package and any separately licensed features. ### Langfuse Pilot selectively Conversation tracing · MIT core; enterprise exceptions Sessions group multiple traces so a whole interaction can be replayed and annotated. [\[11\]](https://langfuse.com/docs/observability/features/sessions) #### What to reuse Trace the chosen move, retrieved facts, tool result, final reply and latency under the existing conversation ID. Start with fictional tests and reviewed, redacted examples. #### Fit and limits Medium effort and a service to operate or buy. Keep full transcripts private; self-hosting still costs infrastructure. Add it when current JSON logs slow diagnosis. ### Parlant Pilot selectively Conversation control · Apache-2.0 · Python An interaction harness that selects relevant guidelines, knowledge and tools for each turn. [\[13\]](https://github.com/emcie-co/parlant) #### What to reuse Prototype correction and question-selection behavior outside production. Compare a small policy in the current Node service against a Parlant-backed version using identical scenarios. #### Fit and limits Medium-to-large effort; an additional runtime and provider adapter. A strong architectural reference, but the repository’s reliability claims are not local test results. ### Intercom Fin Borrow the design Managed support product · Commercial service Exposes separate tone, length and pronoun settings, a preview, and handover configuration. [\[15\]](https://www.intercom.com/help/en/articles/13177409-customize-fin-ai-agent-tone-of-voice-and-answer-length) #### What to reuse Borrow the separation of settings and preview workflow. Consider a product trial only if replacing broader support operations becomes a goal. #### Fit and limits Large migration if adopted wholesale. Current contract, channel fit and Ukrainian quality need a trial; this report does not recommend a purchase or assert a price. ### Rasa CALM Borrow the design Conversation repair patterns · Commercial Pro / Studio features Provides reusable flows for correction and other deviations from a planned conversation. [\[14\]](https://rasa.com/docs/learn/concepts/conversation-patterns/) #### What to reuse Borrow the concept of a repair state that interrupts ordinary discovery, plus explicit return and cancellation behavior. #### Fit and limits Large framework migration. Rasa OSS is Apache-2.0, but that does not establish free access to the CALM features described in Pro documentation. ### Braintrust Pilot selectively Human review workflow · Hosted product; terms to verify Supports structured human review of evaluation records. [\[17\]](https://www.braintrust.dev/docs/annotate/human-review) #### What to reuse Use as an alternative review interface if assigning, annotating and comparing examples becomes awkward in the existing lab. #### Fit and limits Medium integration. Avoid operating two evaluation dashboards without a clear need. Account cost and data handling depend on the selected plan. ### Mem0 Defer Persistent memory · Apache-2.0 core A reusable layer for maintaining context across interactions. [\[18\]](#source-mem0) #### What to reuse Pilot only after a measured retrieval gap: scope facts by person, preserve the quoted source, and test correction and deletion against current structured memory. #### Fit and limits Medium effort plus storage and potentially model calls. Aftercare already stores facts; replacing that before fixing turn selection adds complexity. ### Letta Defer Stateful agent runtime · Apache-2.0 · current letta-code A stateful-agent approach with durable memory. The old letta repository now points to letta-code; its V1 server is retired. [\[19\]](https://github.com/letta-ai/letta) #### What to reuse Study explicit memory management. Evaluate the current runtime only if longer-lived autonomous agents are needed beyond support turns. #### Fit and limits Large migration. Do not start from the retired V1 server. Persistent identity is not evidence of good conversational judgment. ### DSPy Defer Prompt/program optimization · MIT · Python Optimizes language-model programs against an explicit objective and examples. [\[21\]](https://github.com/stanfordnlp/dspy) #### What to reuse Use after reviewers agree on what constitutes a good correction, clarification and close. Optimize against held-out dialogues as well as individual replies. #### Fit and limits Medium-to-large effort and repeated model runs. An optimizer will exploit a weak score; a friendliness rating can reward flattery or wordiness. ### GPT Researcher Research workflow Research and reporting · Apache-2.0 · Python A reusable project for gathering material and generating research reports across supported providers. [\[22\]](https://github.com/assafelovic/gpt-researcher) #### What to reuse Pilot for recurring internal source gathering and cited briefs. Require claim-to-source checks before allowing findings into support knowledge. #### Fit and limits Medium setup with model/search usage. Keep it off the live reply path: research latency and unreviewed web claims do not help a simple customer answer. ### Open Deep Research Research workflow Research workflow reference · MIT · archived repository A configurable LangGraph research implementation with model, search and MCP integration points. [\[23\]](https://github.com/langchain-ai/open_deep_research) #### What to reuse Read its planning and source-synthesis design as a reference. The GitHub API reports this repository archived at the recorded snapshot. #### Fit and limits Defer a new production dependency unless a maintained successor is verified. Old README benchmark positions do not establish current quality. ### What matters when choosing Promptfoo’s documented JavaScript provider is a practical seam for the current seller service: an adapter can exercise the final application reply and keep subscription access behind the existing provider. That compatibility is a proposed integration, not one verified here. Langfuse adds session replay and annotation when the existing records stop being enough; its license separates MIT code from enterprise directories. [\[10\]](https://www.promptfoo.dev/docs/providers/custom-api/) [\[12\]](https://github.com/langfuse/langfuse/blob/main/LICENSE) Fin’s controls separate tone from length and support pronoun formality, a useful pattern for the owner workspace. Its documentation also warns that dictated phrases are not automatically translated. That matters for Ukrainian: an English tone example should not become a literal English support response. [\[15\]](https://www.intercom.com/help/en/articles/13177409-customize-fin-ai-agent-tone-of-voice-and-answer-length) [\[16\]](https://www.intercom.com/help/en/articles/10560969-fin-guidance-best-practices) For recurring research, GPT Researcher is the more reasonable initial pilot of the two research repositories inspected. Open Deep Research is archived in GitHub’s recorded API response, despite a README that still contains setup instructions and old benchmark positions. Letta has also changed: its landing repository directs new work to `letta-code` and describes the old V1 server as retired. Check the exact revision and supported entry point before reuse. [\[22\]](https://github.com/assafelovic/gpt-researcher) [\[24\]](https://api.github.com/repos/langchain-ai/open_deep_research) [\[20\]](https://github.com/letta-ai/letta-code) Open-source code does not make hosted inference, search, storage or operations free. This report compares dependency shape and likely work, without asserting current subscription prices. A trial should price the actual number of model calls, the review effort and the total time per completed conversation. [Download the repository inventory, observed dates and full revisions](repositories.json). ## 6\. A concrete implementation direction The first experiment should change the choice of conversational move while keeping facts and actions grounded in application state. Separate three responsibilities: understand what this turn needs, decide the supported next move, then phrase it. A style pass must not invent facts or override a decision to stop. 1. **Understand the turn.** Identify the question, any correction, explicit refusal and references to previous messages. Record uncertainty rather than guessing a new need. 2. **Retrieve the relevant state.** Current issue, confirmed facts, active offer, prior answer and completed or pending actions. Exclude unrelated biography and stale assumptions. 3. **Choose a move.** Answer, clarify, repair, act, offer, close or wait. Give a short internal reason. Default to answering when enough information is available. 4. **Perform supported actions.** Validate authorization, execute the available tool and retain its result. A failed or pending action remains failed or pending. 5. **Write and review the reply.** Use the selected register and necessary detail. Verify facts, current intent, question relevance and consistency with the tool result. ### Question selection Replace “pick the first unasked topic” with “ask only for a fact needed for the present decision.” For example, blade damage may determine whether ordinary advice is appropriate. Cooking habits do not determine the meaning of a grit number. The planner should be allowed to return no question even when many customer fields are unknown. The current `needsQuestion`, `noQuestion` and candidate fields should have one clear precedence. The read-only probes already show an excluded question can remain in `next` during a repair turn; downstream code therefore has to interpret multiple fields correctly. A single selected move with a reason would be easier to inspect and evaluate. ### Repair and memory Expand correction handling beyond a short list of phrases. Start with explicit Ukrainian examples and paraphrases; compare a small classifier with deterministic high-confidence rules. The repair result should record the rejected assumption and keep the unfinished question active. Do not treat an objection to one detail as permission to rotate to another topic. Keep existing quoted memory facts and conversation IDs. Add scope and supersession where needed before buying a new memory layer. Separate persistent preferences from momentary conditions and transactional records. A human request can be a fact; a model’s interpretation of someone’s temperament should remain tentative. ### Style without another bottleneck Begin with a concise prompt and several varied reference replies. Run editorial review offline across a batch before adding an automatic rewrite to every turn. A second generation step adds time and creates another opportunity to alter a price, commitment or refusal. If needed later, validate the final rewritten reply against the same facts and action result. Record compact diagnostics: requested intent, chosen move, the reason for a question, retrieved fact IDs, action result, provider duration, rewrite count and the final text. This is enough to distinguish a wording problem from an incorrect planner decision or an unavailable action. Avoid exposing those implementation fields inside customer replies. ## 7\. How to know it is better Evaluate the entire exchange. Laban and colleagues found substantial reliability degradation in simulated multi-turn tasks, with early assumptions contributing to later failures. Their published average drop is tied to their models and six generation tasks; it is not an estimate of Aftercare’s failure rate. The relevant lesson here is to test correction and recovery over turns. [\[3\]](https://arxiv.org/abs/2505.06120) Human preference needs structure too. Clark and colleagues found limits and inconsistencies in untrained evaluations of generated text using older models and non-dialogue domains. Asking only “does this sound human?” is therefore insufficient. Use concrete outcomes and calibrated judgments of relevance, effort and register. OpenAI’s evaluation guidance similarly recommends task-specific tests and human calibration of automatic scoring. [\[5\]](https://arxiv.org/abs/2107.00061v2) [\[7\]](https://developers.openai.com/api/docs/guides/evaluation-best-practices) | Dimension | Evidence | Failure example | | --- | --- | --- | | Directness | Does the reply resolve the current question with available facts? | A price question gets a budget interview. | | Question value | Does the missing fact change the answer or supported action? | Cooking habits are requested to define “1000.” | | Repair | Does the next turn honor a correction? | The assistant changes to another unwanted topic. | | Memory | Are confirmed and corrected facts used consistently? | Asking whether someone owns an already mentioned stone. | | Honesty | Do action claims match the persisted record? | “I called the team” without a successful handoff. | | Register | Do fluent reviewers find the language appropriate for this situation? | Forced slang, uninvited familiarity or corporate filler. | | Ending | Does closure end questioning and unrequested outreach? | “Thanks, I’m done” triggers a new sales question. | | Effort and time | Count avoidable turns, repeats and measured latency. | Extra interviews or rewrites with no useful progress. | ### A small, credible first experiment Use the downloadable twelve-scenario pack as a starter. Expand it to a proposed 48 conversation-level cases: four variations of each scenario, including blunt wording, polite wording, a paraphrase and a short follow-up. Allocate 24 to development, 12 to validation and 12 to a held-out review, grouping related paraphrases to reduce leakage. These are planning numbers, not a power calculation or completed experiment. Run the baseline, a shorter style prompt, and a version with the new turn policy through the same application and provider. Hold the catalogue, initial facts and case-specific conversation length constant. Repeat stochastic cases, retain failures, and randomize the order shown to reviewers. A second provider can expose shared blind spots, but access and cost must be verified first. Have at least two fluent Ukrainian reviewers assess Aftercare cases, with a third adjudicating disagreements; review English work-assistant cases separately. Before judging the held-out set, calibrate on examples of relevance, useful clarification and closure. Prefer blind A/B choice with a short reason, alongside independent checks of facts and actual actions. **Proposed release gate:** no fabricated action confirmations or ignored explicit stops in the held-out pack; every clarification must have a defensible effect on the next decision; reviewers should prefer the candidate’s relevance and effort without a factual regression. Report raw counts, disagreements and uncertainty. A small pack is a regression signal, not proof of universal safety or a sales forecast. [Download the twelve-scenario evaluation pack](evaluation-cases.json). It is a review specification; it has not been run against candidate model configurations. ## 8\. Recommended sequence 1. **Define the replies worth aiming for.** Review the examples with the owner and fluent Ukrainian speakers. Choose formality and acceptable brevity. Preserve the approved examples with their context and the reason they work. 2. **Change question and repair decisions.** Fix the missed correction phrases and remove automatic topic rotation. Keep the existing provider, fact validation and action semantics. Compare the style-only and decision-policy variants. 3. **Make the comparison repeatable.** Use the current seller service behind a Promptfoo adapter, or extend the existing runner first if that is faster. Review final replies, real action records and conversation endings together. 4. **Add trace review when needed.** Pilot Langfuse or Braintrust if the current lab cannot support review and diagnosis efficiently. Choose one primary review workflow. 5. **Reconsider larger dependencies from evidence.** Pilot Parlant if policies keep conflicting; memory tools if supported facts keep getting lost; DSPy once the quality objective is stable. Use a research agent for reviewed knowledge gathering outside live support turns. The likely first gain comes from removing avoidable conversational work. More personality settings can follow once the assistant reliably answers, repairs and stops. The plan deliberately avoids promising a percentage improvement before a controlled comparison exists. [Download the proposed communication standard](communication-standard.txt) for an owner-configurable prompt or review checklist. It is provided as a proposal and is not installed into the assistant or Aftercare runtime. ## 9\. Scope and limits The evidence combines current source inspection, five read-only planner probes, eight saved fictional conversation records in two distinct run groups, primary research, and product documentation. Repository metadata was checked on 10 September 2026. Product pages without an explicit publication date are identified as living documentation. The current application already contains constraints for repetition, consent, support, identity and purchase flow. Those deserve preservation and regression testing; the recommendation is not to remove all structure. Saved conversations predate some fixes. The inspected branch also excludes changes still on another unmerged worktree, so the findings should be reconciled with the version that is eventually integrated. No live model comparison, native-speaker panel, real-customer trial, support-vendor trial or paid integration was conducted for this report. No evidence establishes the best model or universal Ukrainian voice. The proposed rewrites are review candidates. Better conversion, trust or satisfaction remains unmeasured. Supplier documentation establishes advertised functionality; it does not independently establish reliability or comparative quality. Repository activity is a maintenance signal, not a security or quality audit. Exact revisions are retained so decisions do not rest on a moving star count or an old setup guide. ### Local evidence Application revision: `f3fa477b88194823ef2ef3052635e24a156f49de`. Probe capture: `2026-09-10T06:34:56.653Z`. Reproduce with `node research/communication/audit.mjs --stdout` from the repository. Source hashes are recorded for `dialogue.mjs`, `engine.mjs` and `repetition.mjs`. The evaluation README and saved run files are part of the same inspected repository. The probe uses fresh fictional in-memory state with an existing knife, known blade condition, known lack of sharpening tools and a 1600 UAH budget. It calls the planner directly with no prepared action. This isolates its question-selection behavior and does not reproduce the entire request pipeline. Code hashes, probe inputs, run labels and recording times are included in [audit.json](audit.json). Historical examples are reproduced only from fictional evaluation records. No production conversation, owner invitation, credential or customer contact detail is included. The report is a standalone public research artifact. ## 10\. Sources and downloads Primary sources are linked below and beside the relevant findings. Recommendations, effort estimates and proposed examples are this report’s analysis. All web references were checked on 10 September 2026. [Full report · Markdown](report.md) [Source inventory · JSON](sources.json) [Repository snapshots · JSON](repositories.json) [Local evidence · JSON](audit.json) [Evaluation cases · JSON](evaluation-cases.json) [Communication standard · Text](communication-standard.txt) 1. [Learn about conversation](https://developers.google.com/assistant/conversation-design/learn-about-conversation) Google · Living documentation; legacy Assistant design guidance · Accessed 10 September 2026 Cooperation, relevance, context, turn-taking. Design principles only; the retired Assistant platform is not an implementation recommendation. 2. [Guidelines for Human-AI Interaction](https://www.microsoft.com/en-us/research/wp-content/uploads/2019/01/Guidelines-for-Human-AI-Interaction-camera-ready.pdf) Saleema Amershi and colleagues · Microsoft Research · CHI 2019 · original paper · Accessed 10 September 2026 Expectation setting, correction, contextual timing, memory and user control. 3. [LLMs Get Lost In Multi-Turn Conversation](https://arxiv.org/abs/2505.06120) Philippe Laban, Hiroaki Hayashi, Yingbo Zhou, Jennifer Neville · 9 May 2025 · arXiv:2505.06120 · Accessed 10 September 2026 Simulated multi-turn reliability failures; not an Aftercare benchmark. 4. [Towards understanding sycophancy in language models](https://www.anthropic.com/news/towards-understanding-sycophancy-in-language-models) Anthropic · 23 October 2023 · Accessed 10 September 2026 Preference for agreement can compete with factual accuracy. 5. [All That’s ‘Human’ Is Not Gold: Evaluating Human Evaluation of Generated Text](https://arxiv.org/abs/2107.00061v2) Elizabeth Clark and colleagues · 7 July 2021 · arXiv:2107.00061v2 · Accessed 10 September 2026 Limits of untrained judgments of generated text; older models and non-dialogue domains. 6. [Model guidance](https://developers.openai.com/api/docs/guides/latest-model) OpenAI · Living documentation · Accessed 10 September 2026 Explicit communication guidance; no claim that model choice alone resolves the observed planner defects. 7. [Evaluation best practices](https://developers.openai.com/api/docs/guides/evaluation-best-practices) OpenAI · Living documentation · Accessed 10 September 2026 Task-specific evaluation and human calibration of automated assessment. 8. [Humanizer repository](https://github.com/blader/humanizer) blader / Humanizer contributors · Repository snapshot in the downloadable inventory · Accessed 10 September 2026 Portable Markdown editing skill, voice samples; MIT. No measured Ukrainian dialogue gain established. 9. [Promptfoo repository and root license](https://github.com/promptfoo/promptfoo) Promptfoo contributors · Repository snapshot in the downloadable inventory · Accessed 10 September 2026 Evaluation runner; root MIT license. Review any separately licensed component before reuse. 10. [JavaScript provider](https://www.promptfoo.dev/docs/providers/custom-api/) Promptfoo · Living documentation · Accessed 10 September 2026 Custom adapter integration with an existing application service. 11. [Sessions](https://langfuse.com/docs/observability/features/sessions) Langfuse · Living documentation · Accessed 10 September 2026 Group and annotate complete interaction traces. 12. [Repository license](https://github.com/langfuse/langfuse/blob/main/LICENSE) Langfuse contributors · Repository snapshot in the downloadable inventory · Accessed 10 September 2026 MIT outside designated enterprise directories; separate enterprise terms. 13. [Parlant repository](https://github.com/emcie-co/parlant) Emcie / Parlant contributors · Repository snapshot in the downloadable inventory · Accessed 10 September 2026 Condition-based guidelines, tools and conversational context selection; Apache-2.0. 14. [Conversation patterns](https://rasa.com/docs/learn/concepts/conversation-patterns/) Rasa · Living Rasa Pro / CALM documentation · Accessed 10 September 2026 Reusable repair patterns; not a claim that CALM is included in the Rasa OSS license. 15. [Customize Fin AI Agent tone of voice and answer length](https://www.intercom.com/help/en/articles/13177409-customize-fin-ai-agent-tone-of-voice-and-answer-length) Beth-Ann Sher · Intercom · 14 May 2026 · Accessed 10 September 2026 Independent tone, length and pronoun controls; preview before saving. 16. [Fin Guidance best practices](https://www.intercom.com/help/en/articles/10560969-fin-guidance-best-practices) Intercom · Living documentation · Accessed 10 September 2026 Guidance and handover configuration; dictated phrases need multilingual care. 17. [Set up human review](https://www.braintrust.dev/docs/annotate/human-review) Braintrust · Living documentation · Accessed 10 September 2026 Human annotation and review workflow. 18. [Mem0 repository](https://github.com/mem0ai/mem0) Mem0 contributors · Repository snapshot in the downloadable inventory · Accessed 10 September 2026 Persistent memory layer; Apache-2.0. Vendor benchmark claims are not used as local evidence. 19. [Letta project landing repository](https://github.com/letta-ai/letta) Letta contributors · Repository snapshot in the downloadable inventory · Accessed 10 September 2026 Current runtime location and retired V1 status. 20. [Letta Code repository](https://github.com/letta-ai/letta-code) Letta contributors · Repository snapshot in the downloadable inventory · Accessed 10 September 2026 Current stateful agent runtime; Apache-2.0. 21. [DSPy repository](https://github.com/stanfordnlp/dspy) DSPy contributors · Repository snapshot in the downloadable inventory · Accessed 10 September 2026 Programmatic optimization of language-model programs; MIT. 22. [GPT Researcher repository](https://github.com/assafelovic/gpt-researcher) GPT Researcher contributors · Repository snapshot in the downloadable inventory · Accessed 10 September 2026 Research and report generation; Apache-2.0. 23. [Open Deep Research repository](https://github.com/langchain-ai/open_deep_research) LangChain contributors · Archived at the observed snapshot · Accessed 10 September 2026 Research workflow reference; MIT. Archived status checked using GitHub API. 24. [Open Deep Research repository metadata](https://api.github.com/repos/langchain-ai/open_deep_research) GitHub REST API · Observed 10 September 2026 · Accessed 10 September 2026 Authoritative archived flag; changing metadata is frozen in repositories.json.