Most fine-tuning failures we see in the field are not optimization failures. The loss goes down, the held-out task metric goes up, the model ships — and three weeks later it is quietly wrong in ways the task eval never measured, because the task it was tuned on is not the task the organization actually needed. The organization needed a role filled, and it got a function fitted. This page describes how we came to tune models to organizational roles rather than tasks inside Luca AI Express, our production AI operating system, why role-tuning generalizes where task-tuning overfits, and where the approach genuinely hurts.
Task-tuning fits a sample; roles are the generator
A task fine-tune treats the job as a conditional distribution: inputs of shape X, outputs of shape Y, minimize error on pairs drawn from last quarter's traffic. This works exactly as long as production keeps drawing from the same distribution — and in an operating business it never does. Ticket formats change, upstream tools change their outputs, a new product line introduces vocabulary the tuning set never contained. The task-tuned model has no resources for any of this, because nothing in its training data expressed why the outputs were correct, only that they were.
The deeper problem is proliferation. An organization does not have one task; it has hundreds, arriving and mutating continuously. Tuning per task gives you N narrow checkpoints, N eval suites, N drift problems, and a routing problem on top. This is the same dead end the NLP community hit with per-task BERT heads before instruction tuning showed that training on the meta-distribution of instructions generalizes to unseen tasks (the FLAN and InstructGPT line of work). Instruction tuning, though, aims at universality — every instruction, any register, no standing commitments. Production roles are the opposite: sharply scoped, opinionated, accountable.
Our observation, after operating a fleet of cognitive personas in production, is that the useful unit of alignment sits between those extremes. A role is a stable generator of tasks. The intake reviewer, the release-train conductor, the grant-compliance analyst — each will face an unbounded stream of concrete tasks, but the stream is generated by a small, slowly-changing specification: what the role owes the organization, how it speaks, what it may operate, and what it must refuse. Tune to the generator and unseen tasks arrive in-distribution, because the role that generates them was the training target all along.
What a role actually is: duties, tone, tools, boundaries
We decompose a role into four contract surfaces, and we treat this decomposition as the schema for both training-data construction and evaluation:
ROLE (slow-changing; the tuning target)
├─ Duties obligations the role must discharge — the task generator
├─ Tone register, escalation style, how uncertainty is voiced
├─ Tools which affordances the role operates, and calling discipline
└─ Boundaries what the role must refuse, defer, or hand upward
TASKS (fast-changing; arrive at inference time — never the tuning target)Each surface trains a different behavior class:
- Duties teach goal recognition: given an ambiguous situation, which of the role's obligations is engaged, and what does discharge look like? Duty examples are deliberately varied in surface form so the model learns the obligation, not the template.
- Tone teaches register invariance: the role sounds like itself across good news, bad news, escalation, and refusal. Tone is the surface people notice first and, as we discuss below, the one that overfits first.
- Tools teach operational discipline: when to reach for an affordance, how to sequence calls, how to react when a tool fails or returns something surprising. Tool traces are the highest-value training data we capture, because tool errors in production are far more expensive than phrasing errors.
- Boundaries teach the refusal surface: recognizing the requests that are shaped like the role's work but fall outside its mandate — the adjacent-plausible request is the hard negative that defines a role's edges. A role-tuned model that cannot say "this is not mine, here is whose it is" is not role-tuned; it is a task model with a costume.
Boundaries deserve emphasis because they are what task-tuning structurally cannot learn. A task dataset contains only in-scope examples by construction; the model's behavior off-distribution is whatever the base model improvises. Role datasets are built with the out-of-scope region as a first-class label, so the model's competence has a shape, with known edges, rather than a peak with undefined slopes.
Where the training signal comes from
Role-tuning is only as good as the evidence that a role was performed well, and this is where the method stops being a data-formatting trick and becomes an organizational system.
In Luca, personas run a PERCEIVE→REASON→PLAN→ACT→REFLECT loop, and every duty discharged in production leaves a phase-structured trace: what the persona saw, what it inferred, what it planned, which tools it operated, and what it concluded on reflection. Our personas also follow a wake/attention/sleep doctrine for long-term memory: during sleep-phase consolidation, episodic traces are distilled into durable role memory — recurring situations, resolved ambiguities, corrected mistakes. That consolidation step turns out to be a natural curation gate for tuning data: what survives consolidation is, almost by definition, the role-relevant regularity rather than the episodic noise. The same mechanism the persona uses to remember its job is the mechanism that teaches the next model generation the job.
Two more corpora anchor the duties and boundaries surfaces. Every change in our platform ships with an executable blueprint/playbook/runbook triple seeded into the Codex, our governed institutional-knowledge corpus (440+ entries, browsable with dependency and knowledge graphs at ticket.lucaexpress.com). Playbooks are, in effect, duty specifications written for execution — so role datasets can be derived from governed documents rather than reverse-engineered from behavior, and when a playbook changes, the diff tells you which training examples went stale. This is the property we care most about: the training set has provenance, and provenance makes drift detectable instead of mysterious.
The lifecycle runs through Model Forge, our capture→fine-tune→serve→evaluate pipeline for small models:
production traces ──► sleep-phase consolidation ──► role corpus
▲ (+ Codex playbooks, │
│ boundary probes) ▼
serve role model ◄── role evals gate ◄──── fine-tune small modelEvaluation is where "role, not task" must be enforced or the whole argument collapses. Our role evals are deliberately not held-out task samples. They are: unseen duties within the role (does the generator generalize?), boundary probes (adjacent-plausible requests the model must decline or route), tone-consistency checks across emotional registers, and tool-discipline scenarios including injected tool failures. We score these with deterministic, versioned scoring engines, with AI-assisted passes admitted only when they cite extractable evidence — because an eval that drifts with its judge model cannot gate a training pipeline.
Why this favors small models
Role-tuning and small models are complementary in a way we did not fully anticipate. A role restricts the support of the behavior distribution: bounded vocabulary of situations, finite tool set, a characteristic register. Small models fail at open-ended generality but are entirely capable of narrow depth — and a role is precisely a specification of narrow depth. In our experience the role frame converts "small model can't do the job" into "small model can do this job, once the job is actually specified." We will not quote benchmark numbers here — role evals are role-specific and cross-organization numbers would be meaningless — but the qualitative pattern has been consistent enough to shape our roadmap: the economically interesting deployment is many small role-tuned models, coordinated, rather than one large generalist prompted into each role per request.
There is also an architectural division of labor that role-tuning makes explicit. Weights are the slowest memory tier, so only slow-changing content belongs there: disposition, judgment, discipline, boundaries. Facts that change live in retrieval and in the persona's consolidated memory; procedures that change live in Codex playbooks the model consults. Tune the disposition, retrieve the knowledge, look up the procedure. Task-tuning routinely violates this layering by baking current facts into weights, which is another reason it rots: the model's knowledge is welded to a training date.
Failure modes, candidly
Role-tuning has sharp edges. The ones that have actually cut us:
- Caricature collapse. Tone is the lowest-loss surface, so an unbalanced corpus produces a model that sounds like the role at increasing fidelity while its judgment quietly regresses — the costume without the competence. The countermeasure is compositional: cap tone-dominant examples, and gate on judgment evals scored independently of style.
- Boundary drift under helpfulness pressure. RLHF-descended base models want to help; a role's mandate says "not yours." Without continued hard negatives at the edges, successive tuning rounds sand the refusal surface down. Boundary probes must be a permanent eval fixture, not a launch-time checklist.
- Stale roles. Organizations reorganize. A role model tuned to last quarter's mandate is confidently wrong in a way a prompted model is not, because a prompt can be edited in minutes and weights cannot. We mitigate by versioning roles against their Codex entries — an org change is a governed document change, which flags the affected corpora — but the update latency is real and is the honest cost of putting role in weights.
- Identity bleed in multi-agent settings. When several role models collaborate, transcripts of other roles enter each model's context, and a weakly-tuned role starts imitating its interlocutors. Duty and boundary training must include multi-party traces where staying in-role while others speak is the labeled behavior.
- The evaluation temptation. The moment a role eval is reduced to a convenient task metric, the pipeline silently reverts to task-tuning with extra steps. Keeping the eval role-shaped requires institutional discipline more than technical machinery.
The honest trade-off summary: role-tuning buys generalization within a mandate, consistency, token economy (the role no longer rides in the prompt), and small-model viability. It costs update latency, an eval program that must be built rather than downloaded, and a dependency on governed role specifications — if your organization cannot write down what a role owes, no pipeline can tune a model to it. That last dependency is why our fine-tuning engagements so often begin as knowledge-governance engagements.
Where this is heading
Three directions occupy us now. First, tightening the loop between sleep-phase memory consolidation and corpus refresh, so a role model's training data ages at the rate the role changes rather than at the rate someone remembers to retrain — parts of this capture-consolidate-tune loop are covered by our patent-pending work. Second, transfer across roles: duties differ but tool discipline and boundary-recognition look like shared substrates, suggesting a staged curriculum — organizational common sense first, role specialization second. Third, role portability: whether a role specification (duties, tone, tools, boundaries) plus its eval suite can transfer across base models as a durable organizational asset, so the role outlives any particular checkpoint. Early signs on all three are promising; none is finished work, and we intend to publish as results firm up.
Gus IT Research takes on external research engagements in fine-tuning, small-model deployment, and AI memory systems — if your organization is trying to teach models roles rather than tasks, we have walked this road in production and consult on it.