Our Approach — Behavioral Training
We don't write rules for our AI. We teach it.
Most conversational AI is steered by written instructions — pages of rules the model reads before every reply. We build differently: the experts who know the work teach our model through carefully crafted example conversations, until the right behavior is simply how it responds. That choice buys four things.
Safety
Safe behavior is taught into the model itself — present in the first word it speaks, not checked after the fact. And it is taught to know its limits and reach out to humans where appropriate.
Convergence
Each round of teaching moves the agent measurably toward the goal. A gap, a problem, or a new need is met the same way: more lessons. No revamp from the ground up, no dice roll.
Simplicity
Instruction-driven systems need a stack of checkers, rewriters, and patches around a fragile core. One taught model carries the behavior — less to build, less to break, less to maintain.
Your Experts
Domain experts across fields improve the agent directly, by showing the right response. Expertise goes in without an engineer in between because showing replaces explaining.
These are strong claims, and strong claims require evidence. Ours is ready — in a written argument, and in a working system.
Behavioral Training vs. Prompt Engineering
You can't tell an AI how to care.
You can only show it.
Prompt engineering: a rulebook
Behavioral training: an apprenticeship
The show approach is work. The tell approach is an arms race with your own system.
Behavioral Training vs. Prompt Engineering
Six claims about building conversational AI for vulnerable populations — each expands below, and each opens into its full argument from the Technical Position. Written from years of fine-tuning high-empathy companion models across four model generations.
A prompt is a rulebook, and a rulebook must decide in advance which rule wins in every situation. In a rich human domain, no such ranking exists — the right response depends on context, and context arrives at runtime. "Don't dwell on deceased family members" is right ten thousand times and terribly wrong the one time a person needs exactly that.
The expertise that matters most is tacit. "Is Greg going to call me today?" sounds like a question about the calendar — but the right answer depends on everything around it: maybe she was sharp with Greg on yesterday's call and is really asking whether he's upset with her; maybe Greg's wife just died and he has gone quiet. A skilled caregiver navigates that moment perfectly and cannot write the rule for it — but she can write the response. Training encodes what experts can demonstrate. Prompts are capped at what authors can explain. That ceiling is lowest precisely where warmth and judgment live.
A prompted persona is a performance the model maintains against its own defaults — and performances crack under pressure: emotional intensity, confusion, looping, hostility. Exactly the conditions a vulnerable population produces every day.
A trained persona is the default. There are no instructions to forget, because the behavior isn't being maintained against anything — it's simply how the model responds. Under pressure, one system degrades toward the absence of its guardrails. The other degrades toward its training.
In live voice, the first sentence is spoken while the rest is still being generated. There is no time for a second AI to review, revise, or veto — and a safety layer that corrects output after it starts streaming is acting after the words are already in the room. A companion that pauses to double-check itself isn't a companion; it's a phone tree.
Safety has to be a property of the first token, which means it has to live in the model's weights — not in machinery bolted on behind it, and not in a vendor's general-purpose safeguard whose strongest move is hanging up on a confused elder.
A large prompt offers false transparency: the text is readable, but no person and no AI can tell you from reading it how it will behave. Signing off on a prompt is reviewing a wish list.
A curated training corpus is different in kind. A clinician can read the crisis-handling examples and certify that this is correct clinical behavior. Every example is a concrete behavioral commitment — versionable, reviewable, and cumulative. When the model falls short, the fix is more examples in the weak region: ordinary work, by domain experts, with no new machinery. The dataset is the spec.
Training a companion model is not training a foundation model. With examples authored at high-information moments — the turns where expert judgment diverges from the obvious — hundreds of conversations carry the signal a naive corpus would need tens of thousands to approximate. Strong persona adherence has emerged from as few as three examples.
Just as important is the shape of the spend: incremental, and every increment converges. Each small authoring-and-training cycle buys measurable improvement — or, at worst, a declined checkpoint with the corpus fully retained as an appreciating asset. Money walks toward a solution whose distance closes with each step. There is no bet-the-budget run, and no buried cost.
This agent doesn't just talk. In a single breath it adjusts the volume for a user whose eyes are blurry, favorites the photo she just said she loves, and composes the message to her son — sometimes in her voice, sometimes in its own, deciding what he needs to know and how he needs to hear it. When to act, when to speak, and whom to speak as is layered tacit judgment, and it must be warm, safe, truthful, correctly voiced, and immediate all at once, in the same sentence.
Each demand alone looks like an engineering task that enough labor could retire. The conjunction cannot be labored away: the checker destroys the latency, the parallel pipeline destroys the coherence, the rulebook destroys the warmth. The demands must be satisfied in one place, at once — and the only place they can all live is the weights.
Behavioral Training vs. Prompt Engineering · Overview
Why we teach our companion instead of instructing it
The plain-language version of our technical position — how an AI companion for elders comes to be warm, safe, and genuinely useful, and why the obvious way of building one doesn't work.
The two ways to shape an AI
There are two ways to make an AI behave the way you want. You can write it instructions — a long document of rules, priorities, and personality notes it reads before every conversation. Or you can train it — showing it hundreds of carefully crafted example conversations until the desired behavior becomes simply how it responds. The industry calls the first approach prompt engineering and the second fine-tuning, but the everyday versions of these ideas are familiar to anyone who has trained a person: a rulebook, or an apprenticeship.
Think about how a good care facility brings on a new caregiver. There is a rulebook, but nobody believes the rulebook makes a caregiver. The new hire shadows the best person on staff, watches how she handles the hard moments, and absorbs judgment no manual could hold. The caregivers who were trained only by rulebook are the ones who freeze — or recite policy — when a resident is crying.
The problem with rules isn't that writing them is hard. It's that the right response depends on the moment, and the moments cannot be listed in advance. "Don't dwell on deceased family members" is wise ten thousand times — and terribly wrong the one time a woman needs to talk about her late husband. Whoever writes the rules is being asked to settle, ahead of time, every conflict between every rule in every situation that will ever arise. Nobody can do that, because the answer isn't a ranking of rules. It's judgment, applied fresh each time.
And here is the strange thing practitioners discover: big rulebooks for AI misbehave when you edit them. Fix the rule that caused Tuesday's problem, and Wednesday brings failures in places that used to work — because in an AI's reading, every rule colors the meaning of every other rule. There is no such thing as a small change. Teams respond by building machinery around the AI: a second AI to check the first one's answers, a third to rewrite them, special detectors for special cases. The machinery grows, and the goal never gets closer.
The deeper reason is that the knowledge that matters most in care cannot be written down at all. Think of a resident asking, "Is Greg going to call me today?" It sounds like a simple question about the day's schedule. But the right answer depends on things no schedule shows — maybe she was short with Greg on yesterday's call and is really asking whether he's upset with her; maybe Greg's wife just died and he has gone quiet. An experienced caregiver reads all of that and answers beautifully. Ask her for the rule and she can't give you one — there is no rule, only judgment shaped by this person, this relationship, this week. But she can show you the response. That distinction is everything: instructions can carry only what an expert can explain, while examples carry what an expert can do. So we build our companion's character the only way it can be built — from example conversations authored and reviewed by people who know this work, each one demonstrating the right response at a genuinely hard moment.
Sometimes the right response even contradicts the obvious rule. We deliberately teach our model that after making a serious mistake, it often should not apologize — because an apology turns the moment toward the AI's own social standing and away from the person it affected. No one writing a rulebook would think to write that rule. Most would confidently write its opposite. It takes an expert to recognize it, and only an example can teach it.
An AI following instructions is performing — playing a role described in a document while its real habits wait underneath. A trained AI isn't performing. The warmth is not a costume it was told to wear; it is simply how the model responds, the same way your handwriting is simply yours. The difference shows up exactly when it matters: under pressure. Confusion, repetition, distress, a flash of anger — these are ordinary weather in elder care, and pressure is when a performance slips and whatever lies beneath shows through. A trained character has nothing to slip to. There are no instructions to forget, because none are being followed.
Our companion — her name is Aileen — speaks with a realistic face and voice, and she starts saying her first sentence while she's still composing the rest. That's what makes talking with her feel like conversation instead of dictation. But it leaves no room for a review committee. A companion that pauses to let a second AI double-check every sentence isn't a companion; it's a phone tree. And a safety filter that catches problems as the words stream out is acting after the words are already in the room. For someone's mother, safety has to be present in the first word she hears — which means it has to be built into who Aileen is, not bolted on behind her.
Aileen also does things, right in the middle of speaking: turns up the volume for eyes that are blurry this morning, favorites the photo Betty just said she loves, sends the message to Betty's son — sometimes in Betty's own words, and sometimes as herself, when a rambling story needs to arrive as something a busy son can read, or hard news needs a softer landing. Deciding what to pass along, what to gently condense, and whose voice to speak in is among the most delicate judgment anyone — human or AI — can exercise on a family's behalf. It cannot be reduced to rules. It can only be learned from people who have it.
Here's what many people find surprising: the teaching approach is more checkable, not less. You cannot look at a thousand lines of AI instructions and know how they will behave — reading a rulebook tells you what someone hoped, not what will happen. But you can read the lessons. Our training conversations are a curriculum a clinician can sit down with and certify, example by example: yes, this is the right way to handle that moment. When the model falls short somewhere, the remedy is simply more lessons in that spot — ordinary work by people who know the domain, not another layer of machinery.
And teaching this way is not the giant expense people assume. This is not building an AI from scratch; it's giving a very capable one its character and its craft, through hundreds of carefully chosen lessons rather than millions of pages. The spending is step by step — teach a little, check the result, teach a little more — with each step measurably better than the last and nothing ever wagered on one big roll of the dice. The lessons themselves accumulate into a permanent, improvable asset.
You can't tell an AI how to care. You can only show it.
Which should sound familiar — it is how every person who is good at caring for others came to be good at it. For the complete reasoning, open the Full Technical Position above.
Behavioral Training vs. Prompt Engineering · Full Technical Position
A technical position on building conversational models for vulnerable populations
This document concerns conversational AI deployed in high-stakes interpersonal domains — elder care companionship in our case, and by extension any domain (mental health support, patient engagement) where the user population is vulnerable, the standards are clinical, and the cost of behavioral failure is borne by someone who cannot be expected to recognize or report it.
There are two ways to control the behavior of a large language model. You can tell it what to do (prompt engineering: instructions, rules, priorities, and personas expressed in natural language and supplied at inference time), or you can show it what to do (behavioral training: supervised fine-tuning plus preference optimization, in which curated demonstrations reshape the model's weights so that the desired behavior becomes its default).
The central claim: for deep conversational behavior in a demanding domain, shown behavior converges to objectives and told behavior does not. This is not a preference or a matter of team skill. It follows from the structure of the problem, and the sections below lay out why: prompting attempts to solve an ill-posed problem (§2); prompts can only encode the subset of expertise that survives translation into declarative language (§3); prompted behavior is a performance while trained behavior is a default, and only defaults hold under pressure (§4); the failure modes of training are the manageable ones (§5); a training corpus is a real specification in a way a prompt never is (§6). Sections 7 through 9 then describe the practice: an authoring methodology and toolchain that concentrate training signal and collapse the assumed cost of training (§7); convergence under an eval-gated process (§8); and an architecture in which single-pass, unified-stream inference is a hard requirement for streaming voice (§9). Section 10 states what the domain demands of a single emission, and why the conjunction of those demands decides the question.
A prompt is a set of instructions, and any set of instructions governing a broad domain must contain conflicts — rules that collide in particular situations. To function as a specification, the prompt must therefore encode a priority ordering: which rule wins, in advance, for every situation the deployment will encounter.
No such ordering exists. In a rich interpersonal domain, priority is a function of context, and context arrives at runtime. "Do not dwell on deceased family members" is correct in ten thousand conversations and catastrophically wrong in the one where the user needs exactly that. The prompt author is asked to pre-resolve conflicts they cannot enumerate, using a ranking that cannot exist in general, expressed in a medium — declarative language — that flattens the situations it is meant to govern. The task is not difficult; it is ill-posed. Engagement is context-first: an effectively unbounded set of parallel situational paths, each demanding its own resolution. A static hierarchy of rules has no mechanism for matching itself against that space.
This is why large prompts exhibit their characteristic pathology: non-linearity under edit. Because every instruction is context for the interpretation of every other instruction, there is no such thing as a local change. Reordering two lines to raise the priority of one element can silently alter behavior in regions of the conversation space that were never mentioned in the edit. Practitioners experience this as whack-a-mole — fix one failure, and new failures surface in areas that previously worked. That experience is not a tooling problem or a skill problem. It is the direct signature of ill-posedness.
A training corpus does not rank rules. Each example is a context with its resolution embedded — the situation and the correct behavior, together, in the only form in which context-dependent judgment can actually be represented. Ten thousand examples are ten thousand resolved situations, and the model interpolates a policy from them. This is the structural reason show beats tell: the example format matches the shape of the problem, and the rule format does not.
A prompt can encode only what its author can articulate. A training corpus can encode what a domain expert can demonstrate. These are radically different ceilings.
Most of what constitutes expert judgment in high-EQ domains is tacit. Consider a resident asking, "Is Greg going to call me today?" On its surface, a scheduling question. But the correct response depends on everything surrounding it: perhaps she was harsh with Greg on yesterday's call, and the real question is whether he is angry with her; perhaps Greg's wife has just died, and the kind answer must make room for what he is carrying. The experienced caregiver navigates this moment precisely and cannot write the rule for it — there is no rule; there is a judgment conditioned on this resident, this relationship, this week — but she can write the response. Prompt engineering is therefore capped not by the ideas its authors have, but by the subset of expertise that survives translation into declarative language. That ceiling is lowest precisely where our domain lives: tone, timing, restraint, the weighing of a person's totality against the surface content of their words.
A concrete example from our training practice. A model that makes a serious mistake should often not apologize — because the apology redirects the conversation's attention to the model's social standing and away from the impact on the user. The correct trained behavior is to keep attention on the user's situation rather than on the model's own social repair. Note three things. First, this knowledge is anti-articulable: the rule "apologize when you err" is socially universal and wrong here, and a prompt author would more likely write the wrong rule than no rule. Second, the behavior is easily demonstrated in two or three examples. Third, the lesson generalizes — the model is not learning what to do about apologies; it is learning that its function is not to perform personhood but to serve the user's state. That is a pattern of contemplation, not a rule, and patterns of contemplation are exactly what examples transmit and instructions cannot.
A prompted persona is a performance the model maintains against its own defaults. A trained persona is the default.
This distinction predicts the observed reliability difference. Maintaining a performance requires the model to continuously attend to its instructions while also processing the conversation; as the instruction set grows, instruction-following degrades — and this degradation appears immediately, in short conversations, right out of the gate, not merely in long-context decay. There are no guarantees for large system prompts even on turn one, and the failure rate compounds under exactly the conditions a vulnerable population produces: emotional intensity, non-sequitur, repetition and looping, confusion, hostility. Pressure is when the performance cracks and default behavior shows through.
Trained behavior has nothing to crack. There are no instructions to forget because the behavior is not being maintained against anything — it is what the model does. Under the chaotic, emotionally loaded, cognitively impaired input that defines our deployment environment, the distinction between performance and default is the distinction between a system that degrades toward its guardrails' absence and a system that degrades toward its training.
(Honest boundary: fine-tuned models also drift over very long conversations — toward trained behavior rather than toward base-model behavior, but drift nonetheless. Our architecture handles this operationally: conversations are periodically concluded and summarized, and a fresh conversation is initialized with prior summaries as state. This is a modest, deterministic mechanism, not a behavioral-control system.)
The two approaches fail differently, and the difference should be stated honestly because it decides the argument.
Prompt-engineered systems fail loudly and locally: a rule collision produces visibly anomalous output in a specific situation. Trained systems fail quietly and globally: a subtle bias in the corpus — authors unconsciously validating confusion rather than gently reality-testing it, say — becomes a pervasive behavioral trait that nobody decided on and no single output reveals.
Quiet/global is the better trade, for one reason: it is remediable with the same instrument. When evaluation surfaces a weakness in a trained model, the remedy is authoring — narrow examples targeting the specific failure, plus broad examples boxing in the troublesome region. This is ordinary work. It requires domain understanding, not heuristic invention: the author does not need to explain the failure or craft a rule against it; they need to recognize the correct behavior and demonstrate it, sometimes only a few times. Remediating a prompt-engineered system, by contrast, routinely requires new architecture — a discriminator to detect the troublesome case, a bypass around the normal generation path, custom reasoning fed back to the primary responder. One approach's maintenance is more of the same; the other's is a growing menagerie. Which of these converges is not a close question.
The deepest version of the quiet/global objection is out-of-distribution input: real users will exceed any corpus, and a trained model's behavior beyond its data is generalization, not specification. Our answer is methodological, and it is a substantial fraction of our practice: roughly 30% of our training corpus in prior mental-health deployments consisted of OOD-boundary examples. The insight is that the model does not need coverage of the OOD space; it needs trained recognition of the boundary, indexed by risk magnitude rather than by enumerated case. The model learns the shape and severity of situations in which the correct behavior is to stop, disengage, and route to humans. In our therapist's-assistant deployment, suicidal ideation was handled in-conversation, per clinical guidance, while self-harm crossed the trained risk threshold: the model disengaged and directed the user to emergency services and trusted contacts. This converts an unbounded coverage problem into a bounded recognition-and-handoff problem — trained, evaluated, and patched with the same instrument as everything else.
The standard governance argument for prompts is inspectability: "here is the instruction set" reads as transparency. This inverts the truth. A prompt offers false transparency — the artifact is human-readable, but per §2 its behavior is not derivable from reading it; no person and no AI can tell you from the text how a large prompt will behave. Inspection has no meaning except at runtime. The presumption of inspectability is itself a systemic risk: it invites sign-off by reviewers who believe they have reviewed the system when they have reviewed a wish list.
In a trained system, the dataset is the specification. A curated corpus of expert-authored exchanges is inspectable in the way that matters: a geriatric psychiatrist can read the crisis-handling examples and certify that this is correct clinical behavior, in a way no one can read a 6,000-token prompt and certify anything. The corpus is legible to domain experts rather than to prompt engineers; it is versionable; and each example is a concrete behavioral commitment rather than an aspiration. Paired with a behavioral evaluation suite, it is the stronger audit artifact, not the weaker one.
The asymmetry extends to AI-assisted review, which is where audit workflows are heading. AI review of a prompt is unproductive not because the reviewer is weak but because the task has no ground truth: there is no standard of correctness for an ill-posed artifact, so the reviewer can assess only coherence of prose, not behavior produced. AI review of training data is a well-posed task — given the domain brief and use cases, is this response clinically correct, tonally correct, boundary-respecting? Is coverage adequate across the risk taxonomy? The feedback is excellent for the same reason expert human feedback is, and it defines a stable, investable workflow: coverage analysis, tone audits, batch consistency checks. One approach improves with review effort; the other merely accumulates review. How the corpus is authored to make that review maximally productive is the subject of the next section.
Everything to this point argues that training is the only convergent approach. This section describes the practice that makes training work — the part that is not generally known, and the part in which our experience is differentiated.
The foundational fact is widely misunderstood: good training data does not look like good conversation. Realistic dialogue is mostly predictable, and predictable tokens carry near-zero gradient — they are noise that consumes training without teaching. An example earns its place at the moment of semantic surprise: the point where the user's turn diverges sharply from what any model would predict, and the authored response demonstrates how to contemplate that divergence — not what to conclude, but the pattern by which the totality of the user is weighed against the surface content of their words. The apology example of §3 is the archetype: a moment where the socially default behavior is wrong, and the demonstrated behavior teaches a generalizing pattern of judgment.
We author to this standard deliberately. The discipline is, in effect, importance-sampling the conversation space by surprise: identify the high-information decision points — the turns where a model's default prediction and the expert's actual judgment diverge — and place every authored example at exactly those points. The skill is twofold: recognizing which moments carry signal, and demonstrating expert judgment at precisely those moments. This is expert work, and it is where domain experts plug into the pipeline: they do not write rules, craft heuristics, or explain behavior — they recognize the moment and show the response. The OOD-boundary corpus of §5 is this same discipline applied to risk: boundary-recognition examples are, by construction, maximally surprising turns paired with the trained disengagement behavior.
The second half of the methodology is that authoring is not a phase; it is a loop. We do not assemble a corpus and then train once. We train on a handful of conversations, converse with the resulting model, author the next small increment, and train again — corpus and model growing together through many short cycles. And as the model improves, its own conversational outputs increasingly become the raw material of new training conversations, curated and corrected by the expert. This is not a shortcut; it is a requirement of convergence. Training data authored in isolation from the model's own outputs develops a voice and distribution the model must be dragged toward — a moving target of the authors' own creation, and an error nearly universal in naive fine-tuning practice — so that each cycle spends its gradient reconciling style rather than refining judgment. Harvesting the model's good outputs keeps the corpus in-distribution with the model's actual voice, concentrating gradient on what genuinely needs correction. When the model's own output qualifies as training content, that is convergence — observed directly in the workflow rather than inferred afterward. (The known failure mode of training on model outputs — distributional collapse, error amplification — is prevented by construction: nothing enters the corpus unjudged; expert curation is the filter, and the surprise-indexed standard applies to harvested content exactly as to authored content. And even the degraded case has a floor the alternative lacks: a partially contaminated corpus still converges to something reviewable and correctable, whereas a prompt-engineered system's accumulated biases have no target to converge to at all.)
The loop is supported by purpose-built tooling — our fourth generation of AI authorship systems for fine-tuning — with three legs. Generation assist: when a model turn needs improvement, the expert selects modifier controls (warmer, more practical, more emotionally attuned), optionally adds free-text direction, and the system generates candidate rewrites conditioned on the full conversation, its metadata, and exemplar high-quality conversations; the expert selects, edits, or discards. Rewrite generation itself has taken two forms across tool generations — a prompt-driven rewriter, and the fine-tuned model operating under explicit expert instruction — with each superior in different situations; that the trained model competes as an author of its own training material is the bootstrapped loop expressed at the tooling level. Simulation: training conversations are grounded in rich simulated users, each created through an intake system where a trainer describes the person in plain language and an AI agent populates a full structured profile — family, friends, health conditions, mobility, memory, appointments, routines, cultural context — every field hand-editable and agent-revisable. From these profiles the system assembles the preamble each conversation is authored against: system state, metadata, schedule, even weather and local happenings. This is what teaches the model that subtle personal details govern correct responses — the corpus demonstrates judgment conditioned on a whole life, not on a message in isolation. Review: because a simulated life is more state than a human author can hold in mind, AI consistency analysis runs both during authoring and afterward, checking continuity across the profile, the preamble, and the conversation.
Note the role prompts play in this toolchain, because it completes the thesis rather than qualifying it: prompt-driven components are used precisely where prompts are fit for purpose — bounded generation tasks whose every output passes under expert judgment before it is used. Prompts are a fine instrument upstream of an expert. What they cannot be is the behavioral substrate downstream of no one, facing a vulnerable user. Same technology, opposite risk positions.
The loop transforms the expert's role over time: from author, to conversational partner correcting the model's turns, to curator selecting and approving. The cost per example falls as the model improves. This is worth stating plainly because it inverts the assumed cost curve on both sides of the comparison: in a prompt-engineered system, marginal cost rises with maturity as the instruction set and its compensating machinery grow more entangled; in this loop, marginal cost falls with maturity because the model itself carries an increasing share of the authoring load.
The consequence is an economics that outsiders consistently misestimate. The assumption a technical buyer carries into this conversation — reasonably, from public discussion of model training — is that training means pretraining-scale investment: enormous corpora, long timelines, seven-figure costs hiding somewhere in the plan. The assumption is wrong, and it is wrong because of the method, not in spite of it. When every example sits at a high-information decision point, a corpus of hundreds of conversations carries the behavioral signal that a naive corpus would need tens of thousands to approximate; signal density substitutes for volume, and the bootstrapped loop reduces the cost of producing each increment. Our experience across four model generations bears this out: strong persona adherence emerged from as few as three examples, and commercially deployable behavior from roughly one hundred authored conversations — results that surprised even the model vendor's own staff at the time. Training runs at this scale are priced in the tens of thousands of dollars, not millions; the dominant cost is expert authoring time, which is bounded, budgetable, declining per example over the life of the loop, and — because the corpus is versionable and cumulative (§6) — an appreciating asset rather than a recurring expense. There is no buried cost. The method is the cost control.
Equally important is the shape of the spend: it is incremental, and every increment converges. Each authoring-and-training cycle is a small, bounded expenditure that produces a measurable behavioral improvement — or, at worst, a checkpoint the eval gate declines, with the corpus (the appreciating asset) fully retained. There is no bet-the-budget training run and no roll of the dice: money is spent walking toward a solution whose distance closes with each step, not wagered on a single leap whose landing point is unknown. This is the financial expression of convergence (§8), and it is the opposite of the prompt-engineered spend pattern, where each dollar of engineering buys scaffolding whose behavioral effect is discovered only after it ships.
This linkage matters for evaluation of vendors generally: the small-corpus economics are not available to a team without the authoring discipline and its toolchain. A naive corpus does not merely cost more to produce — it trains worse, because its signal is diluted across noise. The methodology and the economics are the same fact viewed from two sides.
Fine-tuning converges by definition, within the capability of the underlying model, because it is the same loss-minimization mechanism that produced the base model — no one disputes that pretraining converges to its corpus. Fine-tuning is that mechanism at smaller data scale and truncated depth. Our empirical experience across four model generations (curie, davinci, GPT-3.5, GPT-4.1) is consistent: more high-quality examples monotonically improved behavior, without the regression whack-a-mole characteristic of prompt iteration, and with safe, reasonable outputs from the earliest checkpoints. Convergence is also observable inside the authoring loop itself (§7): the fraction of the model's own conversational output that qualifies, under expert curation, as training content is a direct running measure of convergence — a metric the workflow produces for free.
The engineering claim, stated with discipline: any individual training run can disappoint (forgetting, checkpoint variance), which is why the evaluation suite is part of the method rather than an afterthought. The defensible formulation — and the one we operate under — is that the system converges under an eval-gated training process: behavioral evals gate promotion of every checkpoint, and failures route back to authoring per §5. This claim is empirically grounded, mechanistically motivated, and does not overreach.
Contrast the testing problem on the other side. A prompt-engineered system is hard to test not merely because it is brittle, but because test failures are unactionable: an anomalous output does not tell you which interaction among dozens of instructions produced it, so there is no principled mapping from failure to fix. In a trained system, a failure tells you exactly where to concentrate authoring effort. Testability is not a peripheral advantage; it is the difference between a feedback loop and a guessing game.
Our product is a tablet application for elders: speech-to-text, a fine-tuned text model, and parallel sentence-level text-to-speech feeding a realtime realistic video avatar with synchronized karaoke text. Latency is minimized by speaking the first sentence while subsequent sentences are still generating.
This architecture imposes a hard requirement: the first sentence must be final — safe as emitted, with no review pending. Prompt-engineered systems in sensitive domains characteristically rely on downstream machinery (guardian models, checkers, revision loops) precisely because the core model's behavior cannot be trusted single-pass. That machinery is architecturally incompatible with sentence-level streaming: nothing can be spoken until the entire response survives validation, so the latency budget — which, in spoken conversation with this population, is the product; conversational rhythm is trust — is destroyed. Single-pass safety is not a preference here. It is a requirement, and safety in the weights is the only thing that satisfies it.
The requirement is compounded by what the model's output actually is. The trained model does not emit prose; it emits a unified expressive stream — speech interleaved with structured elements: delivery and pacing directives for the voice, expressive icons, device controls (volume, media display, marking a photo a favorite), and outbound messages to family members, woven inline with the conversational text. The model has learned not only what to say but when to act and how action and speech interleave: adjusting the volume mid-sentence for a user who says her eyes are blurry, hearting the photo she just said she loves, composing the reassuring message to her son with the clinical detail he needs. This is tacit judgment (§3) extended to action.
The unified stream is not a stylistic choice; it is the only viable point in the design space, and the alternatives fail structurally, not incidentally. Decomposing expression across parallel generators — one for text, one for commands, one for delivery, one for icons — destroys the shared context that makes the output coherent: each generator optimizes its own axis blind to the others, and the axes of expression diverge — the voice warm while the action is abrupt, the words referencing a photo the device never displayed. The only coherent decomposition is serial, commands first, with their results fed to the conversational model — because the conversational model must know what actions actually occurred. Deny it that knowledge and it does not fall silent about actions; it fabricates them, speaking as though it performed commands it merely assumes were emitted — a hallucination mode induced purely by architecture, and disqualifying for a population whose understanding of what the system did is the system's own narration of it. And the serial arrangement buys its coherence by paying latency, the one budget this product cannot spend. Coherent, truthful about its own actions, and fast: the unified trained stream is the only architecture that is all three. It also forecloses the checker architecture entirely — a review stage would have to validate mixed speech-and-action in realtime, where an error is not an awkward sentence but a message sent to a family member or a device state changed. There is no viable place to put such a reviewer. The behavior is either right in the weights or the architecture does not work.
One capability deserves particular attention because it is the most demanding judgment the agent performs: mediated communication. Aileen sends messages to family members sometimes in the user's voice and sometimes in her own — condensing a rambling account into something coherent for a son, softening difficult news, or carrying clinical detail (an appointment, a physician's name) that the agent's voice should bear so the user's voice does not have to. Each such message involves layered tacit judgment: what the user meant as distinct from what she said; what the recipient needs to know as distinct from how they need to hear it; and which voice — user's or agent's — the message should carry. The last of these is a matter of representational integrity: the family's trust that words attributed to their mother are faithfully hers, and words from Aileen are honestly the agent's. No rule set specifies when to condense, what to soften, or whom to speak as; explaining the space of contexts is ill-posed in exactly the sense of §2, and the judgment is tacit in exactly the sense of §3 — answerable only as demonstrated behavior. This function alone would justify the training-based approach.
The same lens applies to the new generation of realtime voice models (full-duplex speech-to-speech, now shipping in consumer products with an API expected). These are impressive systems, and they even include what our thesis predicts they must: a runtime safety layer that monitors output as it streams and can steer the model, surface resources, or end the conversation. But examine that layer and the conclusion sharpens rather than softens: conformance to our standards remains unachievable in principle. The model cannot be fine-tuned, so its behavior is defined by the vendor's general-purpose training; the safety layer triggers on the vendor's general-consumer risk taxonomy, and a deploying organization's clinical standards cannot be expressed to either — not to the model, not to the safeguard. The layer is also reactive by construction: it detects unsafe output as it streams, meaning in live audio the first words are already spoken before mitigation acts — a correction stage atop untrained behavior, which is the checker architecture relocated into the vendor, with all of this section's objections intact. And its strongest intervention — ending the conversation — is precisely the wrong action for a confused or distressed elder, for whom the correct behavior is trained, warm disengagement toward human help (§5). These systems also delegate deeper work to a background model while the voice keeps talking — accepting exactly the parallel split whose coherence and fabrication risks are described above, tolerable in a general assistant, disqualifying in an agent whose speech must be truthful about actions taken on the user's behalf. The API, when it ships, will satisfy exactly one of this domain's demands — latency — while remaining constitutionally unable to satisfy the others: no training surface for warmth or clinical standards, no structured command emission into the deployer's device and messaging fabric, no mediated-communication judgment, and safety defined by the vendor rather than the domain. Speed alone is not a companion. Whatever their consumer appeal, they are unsuitable for this domain as they stand.
Finally, the honest concession, drawn narrowly — and more narrowly than it first appears. A trained system still carries a runtime periphery, but the periphery is data, not instructions: the resident's profile, the day's schedule, recent family contact, conversation summaries (§4), assembled as preamble state. Critically, the model's use of that state is itself trained — every training conversation was authored atop exactly this preamble structure (§7), so weaving session facts into judgment is baked behavior, not requested behavior. Behavior lives in the weights; only facts live in the context. During an incident, interim mitigation belongs in deterministic code — a filter, a topic gate, a hard-coded escalation — whose semantics are local and inspectable; editing a large prompt under incident pressure is precisely when its non-linearity is most dangerous, and the apparent speed of a prompt hotfix ignores that the testing burden is the real clock. Durable remediation proceeds as ordinary authoring and retraining, which is unlikely to make anything else worse. The distinction that matters is between a data periphery serving a trained core and load-bearing instructional scaffolding compensating for an untrained one. The same surface technologies carry opposite architectural meanings, and conflating them is the most common error in this debate.
In earlier discussion we framed the requirements for this class of deployment as three guarantees — safety, trustworthiness, consistency. On reflection, that framing conceals the structure that matters: these are not three peer properties. They are two properties and a scope condition.
The properties are attributes of individual outputs. Safety: the output creates no risk for its user. Trustworthiness: the output is correct, true, and reasonable. Both approaches can exhibit these properties somewhere — any demo proves that much.
Consistency is not a third property of outputs. It is the scope over which the properties hold: the claim that safety and trustworthiness obtain across the full distribution of conditions the population will produce — emotional intensity, confusion, looping, hostility, cognitive impairment — and not merely in the regions that were tested. And the scope condition is where the approaches part ways. Prompt engineering can achieve the properties locally, in demonstrated regions, at the cost of ever-growing scaffolding; per §2 and §4 it has no mechanism for extending them across the distribution, because performance cracks precisely where the distribution gets hard. Behavioral training targets the scope directly: the properties are placed in the weights (§§2–4), extended to the distribution's edges by trained boundary recognition (§5), specified in an expert-legible corpus (§6), authored for maximal signal by a toolchain built for the purpose (§7), verified distributionally by eval gates and observed directly in the authoring loop (§8), and carried intact through a single-pass, unified-stream runtime with a data-only periphery (§9).
It is worth stating what this domain actually demands, because the demands are the argument. A single emission — often a single sentence — must simultaneously be: warm, in a way that constitutes genuine companionship rather than customer service; grounded in the reality of the user's life — her appointments, her family, her friends, what she said yesterday; safe to clinical standards, as the first token streams; useful, carrying device actions and outbound family communication inline; correctly voiced, speaking as the user or as the agent with representational integrity; and immediate, because conversational rhythm is trust. Any one demand, in isolation, invites a workaround — someone will always claim a prompt handles warmth, or a checker handles safety, or a serial pipeline handles actions — and this is precisely the trap: each demand looks like an engineering task that sufficient labor can retire. The conjunction cannot be labored away, because the compensating machinery each demand requires under prompt engineering is incompatible with the machinery the others require — the checker destroys the latency, the parallel split destroys the coherence, the instruction set destroys the warmth it attempts to specify. The demands must be satisfied in one place, at once, and the only place they can all live is the weights. A latency-sensitive, command-emitting, agentic system with high demands for safety, warmth, user affinity, and adaptability to local context is not merely better served by behavioral training. It is the kind of system that only behavioral training can produce.
None of this is absolute under any approach, and this document has marked the boundaries throughout: distributional drift, quiet/global failure modes, per-run training variance. What distinguishes behavioral training is that every one of those boundaries is managed by the same convergent instrument — expert authoring under evaluation gates — while the prompt-engineered alternative manages its boundaries by accreting heuristic architecture that is itself the source of new boundaries. One approach is work. The other is an arms race with your own system.