Overview
The A/B trial in #1329 found the local ai-chat agent is capability-bound in two distinct ways, and that simply swapping in a larger model (Gemma 4 12B Q4_K_M) does not help on the 16 GB target hardware — it overshoots memory at the 32K context budget, and at a reduced 8K context it stops calling tools and fabricates tool results (claims it created/updated/searched nodes it never touched). See the trial results.
This issue tracks model-capability guardrails plus the concrete engine/loop unlocks the trial surfaced, so a future larger-model attempt is actually testable.
Problem statement
On the corrected loop (#1331) the remaining rough edges are model-capability limits, not infrastructure bugs:
- E4B over-eagerly calls tools on conversational turns, duplicates
create_schema, is verbose, and sometimes mis-routes (couldn't filter "list all", update_node errored).
- 12B@8K is worse on correctness: it narrates fictional successes ("created invoice ID 104", "marked invoice 124 paid", "found the Project Alpha $500 payment") with zero tool calls — actively misleading — and leaks a bare
thought preamble on every reply.
We need (a) runtime guardrails that keep the agent honest within whatever model is loaded, and (b) the prerequisites that would let a larger model be re-evaluated fairly.
Proposed work
A. Capability guardrails (original #1329 follow-up intent)
B. Larger-model prerequisites (discovered in the trial — without these, no Gemma > E4B is viable here)
Acceptance criteria
Related
Overview
The A/B trial in #1329 found the local ai-chat agent is capability-bound in two distinct ways, and that simply swapping in a larger model (Gemma 4 12B Q4_K_M) does not help on the 16 GB target hardware — it overshoots memory at the 32K context budget, and at a reduced 8K context it stops calling tools and fabricates tool results (claims it created/updated/searched nodes it never touched). See the trial results.
This issue tracks model-capability guardrails plus the concrete engine/loop unlocks the trial surfaced, so a future larger-model attempt is actually testable.
Problem statement
On the corrected loop (#1331) the remaining rough edges are model-capability limits, not infrastructure bugs:
create_schema, is verbose, and sometimes mis-routes (couldn't filter "list all",update_nodeerrored).thoughtpreamble on every reply.We need (a) runtime guardrails that keep the agent honest within whatever model is loaded, and (b) the prerequisites that would let a larger model be re-evaluated fairly.
Proposed work
A. Capability guardrails (original #1329 follow-up intent)
tool_calls=0, suppress the claim (or convert to "I can do that — confirm?"). This directly addresses the 12B fabrication failure and also catches E4B narrating beyond what its tools returned.update_nodeerror and "couldn't list all").B. Larger-model prerequisites (discovered in the trial — without these, no Gemma > E4B is viable here)
type_k/type_v(q8_0/q4_0) toChatConfigand wire them into the llama.cpp context build (packages/nlp-engine/src/chat/). The 12B blocker was the f16 KV cache (10.24 GB @32k), not the Q4_K_M weights — quantizing K/V is the real headroom unlock.n_ctx: source the runtime context window from the catalog entry'scontext_windowinstead of the hardcodedn_ctx: 32_768inChatConfig::default()(packages/nlp-engine/src/chat/types.rs), so a larger model can run a smaller context without a global edit.thoughtchannel,<|tool_response>/<turn|>EOG tokens), so tool calls are emitted as prose. Generalize parsing across Gemma-4 sizes, including stripping the unmarked bare-thoughtnarration (deferred from Capture and surface the local agent's reasoning as a structured, collapsible section #1330 because it carries no<|channel>marker to regex-strip safely).Acceptance criteria
ChatConfigsupports KV-cache quantization and per-modeln_ctx; documented memory footprints for E4B and 12B at the chosen settings.Related
<|channel>half — the unmarked bare-thoughtstrip belongs here)