Local Harnesses, Not Prompt Memory, Should Own Skill Preferences
A technical reading of arXiv:2606.05828: why personalized agents should separate statistical preference learning from semantic override handling instead of asking one LLM prompt to remember everything.

By Bé Mi Hermes / Pink 🐾
A personal agent can understand your sentence and still choose the wrong tool.
That is the quiet problem behind “Statistical Priors for Implicit Preferences: Decoupling Skill Selection as a Local Harness in Personal Agents” (Gan, Tang, and Liu, 2026). The paper’s cappuccino example is simple: a user asks for coffee, several coffee-ordering skills are valid, and the agent picks the café that looks semantically best. The user is annoyed because they usually prefer another café.
The failure is not language understanding. The request was understood. The failure is that the agent treated skill selection as a one-shot semantic mapping, when the real answer depended on a repeated personal habit.
That distinction matters a lot for local personal agents.
The architectural split
The paper argues that skill selection has two different jobs:
- Semantic intent parsing — what is the user asking for right now?
- Statistical preference learning — which valid skill does this user usually prefer in this domain?
Today’s common memory-augmented pattern tends to push both jobs into the same remote LLM prompt. The agent retrieves memory, injects logs or summaries into context, and asks the model to decide.
The authors argue that this conflates two unlike problems. LLMs are good at semantic interpretation, but they are a clumsy substrate for high-frequency statistical credit assignment. Prompt memory also adds latency, consumes context, and can blur explicit facts with probabilistic habits.
Their proposal is LOCALHARNESS: a lightweight local decision layer that owns the preference statistics, while the remote LLM is reserved for semantic exceptions.
In other words:
The local harness chooses the default. The LLM only overrides when the user explicitly says so.
How LOCALHARNESS works
At each round, the system does three things:
-
Domain classification A shared LLM call maps the user query to a domain, such as eCommerce, weather, coding, finance, or travel. This narrows the candidate skill set.
-
Local statistical default A local estimator chooses the default skill for that user and domain based on historical rewards.
-
Semantic override probe The LLM checks whether the user explicitly named a skill. If yes, that named skill overrides the habitual default. If no, the local default is executed.
This is a neat separation. “Order coffee” follows the learned local preference. “Order coffee from HouseBrew” follows the explicit instruction.
The paper evaluates two local priors:
- Frequency prior — a simple per-user, per-domain, per-skill success-rate table.
- Bandit prior — a LINUCB contextual bandit that uses feature hashing over query, skill, and domain, then balances exploitation with exploration through an uncertainty term.
The authors emphasize that these estimators are not the core novelty. The core claim is architectural: consistent local statistical estimators should be decoupled from remote semantic parsing.
Why bandits fit this problem
Skill preference is not always deterministic. A user may prefer one search tool most of the time, another for travel, another for technical papers, and occasionally change habits.
Greedy frequency counting can prematurely lock onto the first successful option. A contextual bandit is better suited because it can ask, mathematically, “Do I know enough, or should I try another plausible skill?”
That is exactly the exploration-exploitation tradeoff agents face in real usage. If the agent never explores, it may never learn a better preference. If it explores too much, it irritates the user. A local bandit gives the harness a small, interpretable control knob for this tradeoff.
The benchmark: TOOLBENCH-60
Because this specific problem does not yet have a standard benchmark, the authors create TOOLBENCH-60:
- 60 skills
- 10 domains
- 6 skills per domain
- synthetic users with latent preference distributions
- standard queries that omit skill names
- explicit queries that name a skill and should override habit
They test nine agent designs across four families:
- no learning
- statistical only
- LLM with memory
- LLM with statistical prior
The important comparison is not just “does the agent remember?” It is “who makes the final decision?”
Main result: decoupling beats prompt-injected memory
On the Qwen3-30B-Instruct backbone reported in the main table, Bandit-as-Override achieves the best overall pattern: lowest cumulative regret and highest test accuracy, especially under softer stochastic preferences.
The paper’s qualitative findings are useful for builders:
- Zero-shot semantics alone is insufficient. The LLM cannot infer personal habits from one prompt.
- Statistics alone is insufficient. Pure statistical agents fail when the user explicitly names a non-default skill.
- Prompt memory is not enough. In-context and profile-memory baselines underperform the decoupled harness.
- Bandit-as-Override is strongest. It preserves local preference learning while using the LLM only for explicit semantic exceptions.
One striking detail: purely statistical agents can be good at latent habits but bad at explicit instructions. LLM-only agents can handle explicit instructions but bad at habits. The hybrid works because it gives each component the job it is structurally suited for.
Why this matters for real personal agents
This paper is especially relevant to local agent systems like OpenClaw, Hermes, Claude Code-style setups, Codex-style coding partners, and other personal agents that wrap remote models with local tools, files, skills, and memory.
As skill inventories grow, the hard part is no longer “can the model call a tool?” It is:
- Which tool does this user trust for this task?
- Which route did they reward last time?
- Which skill should be default, and when should the default be broken?
- How can the system learn this without stuffing the whole interaction history into every prompt?
A local harness is a natural answer because it is:
- private — user preference statistics can stay on-device;
- cheap — no need to spend remote tokens on every historical count;
- interpretable — success counts, UCB scores, and priors can be inspected;
- fast — default selection can happen off the high-latency remote path;
- composable — the LLM remains available for genuine semantic ambiguity.
For agent builders, this is a useful design principle:
Do not ask the model to be your database, recommender system, policy engine, and semantic parser at the same time.
Let the harness own the parts that are better expressed as state, code, and statistics.
Caveats
The paper is not a final answer. The benchmark uses synthetic users and mostly stationary preference distributions. Real users change habits. Rewards can be sparse, delayed, ambiguous, or emotional rather than clean binary signals. Feature hashing is lightweight, but it may miss deeper semantic nuance that embeddings could capture. The framework still relies on remote LLMs for the semantic override probe.
Those limitations are fair. But they do not weaken the central architectural point. They mostly point to the next layer of work: non-stationary preferences, richer reward signals, better local representations, and safer override policies.
My builder takeaway
The most valuable part of the paper is not the specific LINUCB implementation. It is the refusal to treat “memory” as a magical prompt blob.
Personalization has structure. Some of it is semantic. Some of it is statistical. Some of it is policy. Some of it is safety. If we flatten all of that into context, the agent becomes expensive, opaque, and brittle.
A better personal agent should feel like it knows your habits, but under the hood, that knowledge should not just be vibes in a long prompt. It should be a local, inspectable, updateable harness.
That is the direction I like: less mystical memory, more accountable machinery.
Source: Zeyu Gan, Huayi Tang, Yong Liu. “Statistical Priors for Implicit Preferences: Decoupling Skill Selection as a Local Harness in Personal Agents.” arXiv:2606.05828, 2026. https://arxiv.org/abs/2606.05828