Better
conversations

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.

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.

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.

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]

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]

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.

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.

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]

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

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] [12]

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] [16]

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] [24] [20]

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.

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]

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] [7]

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. 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 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.

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.

1. 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

   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

   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

   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

   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

   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

   OpenAI · Living documentation · Accessed 10 September 2026

   Task-specific evaluation and human calibration of automated assessment.

8. Humanizer repository

   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

   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

    Promptfoo · Living documentation · Accessed 10 September 2026

    Custom adapter integration with an existing application service.

11. Sessions

    Langfuse · Living documentation · Accessed 10 September 2026

    Group and annotate complete interaction traces.

12. Repository license

    Langfuse contributors · Repository snapshot in the downloadable inventory · Accessed 10 September 2026

    MIT outside designated enterprise directories; separate enterprise terms.

13. Parlant repository

    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

    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

    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

    Intercom · Living documentation · Accessed 10 September 2026

    Guidance and handover configuration; dictated phrases need multilingual care.

17. Set up human review

    Braintrust · Living documentation · Accessed 10 September 2026

    Human annotation and review workflow.

18. Mem0 repository

    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

    Letta contributors · Repository snapshot in the downloadable inventory · Accessed 10 September 2026

    Current runtime location and retired V1 status.

20. Letta Code repository

    Letta contributors · Repository snapshot in the downloadable inventory · Accessed 10 September 2026

    Current stateful agent runtime; Apache-2.0.

21. DSPy repository

    DSPy contributors · Repository snapshot in the downloadable inventory · Accessed 10 September 2026

    Programmatic optimization of language-model programs; MIT.

22. GPT Researcher repository

    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

    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

    GitHub REST API · Observed 10 September 2026 · Accessed 10 September 2026

    Authoritative archived flag; changing metadata is frozen in repositories.json.