This week’s newsletters kept landing on the same question from different angles: once an agent writes the code, or a model makes the decision, who’s actually checking that the result is safe? Daily Dose walked through a real review of agent-generated code that passed all 46 of its own tests and still shipped a confidence bug and a stored XSS. ByteByteGo covered the mechanism by which one bad fine-tuning example can quietly reshape an LLM’s behavior in domains nobody trained it on. And a genuinely different architecture — energy-based reasoning models — showed up solving Sudoku for four dollars after five frontier LLMs burned eleven thousand on the same puzzles and mostly failed. Plus two solid production-engineering pieces on chunking and GPU parallelism.

Quick note before the deep dives: Daily Dose ran two more Jev pieces this week — running it inside an open-source agent harness, and a multimodal walkthrough now that Jev can take images as input. That’s five weeks running on Jev content. I covered the fundamentals, the judge pattern, and the RAG scorer recipe in earlier digests, so I’m skipping a full write-up here; both are worth a read directly on Daily Dose’s site if you’re implementing it.

Deep dives

1. A model decision is only as safe as the system that executes it

Daily Dose (sponsored by CodeRabbit, but the technical content stands on its own) is the most useful piece I read this week for anyone shipping agent-generated code. They gave Claude Code one prompt to build an incident-response agent on top of Jev: page a team, gather more evidence, or hand off to a human. It produced 30 files, 3,383 lines — model client, policy engine, agent loop, tools, API, dashboard, fixtures, tests. All 46 tests passed. It looked done.

Jev answers six questions per incident in one call (owning team, severity, customer impact, whether more evidence is needed, whether a human should take over, and next_action, restricted to six values). The policy gate then uses Jev’s own confidence: ≥0.80 permits the action, 0.55–0.79 triggers more evidence-gathering, below 0.55 routes to a human. Clean design on paper.

CodeRabbit reviewed the PR, rated merge risk “High,” and found the gap the tests never exercised: in decisions.py, when the selected action’s probability was missing from Jev’s returned probability map, the fallback code grabbed the largest probability from any other option and used that as the selected action’s confidence. So if Jev picked page_team but only returned a probability for inspect_logs (0.90), the policy saw a high-confidence page decision that Jev never actually assigned. Every fixture in the test suite happened to preserve the real pairing, so 46/46 green told you nothing about this path.

The same review’s “blast-radius” view traced a second problem from the API inward: incident text submitted through the Run API landed in shared run state, then got rendered into the dashboard’s HTML unencoded — a stored XSS reachable by anyone who could hit the API, plus missing authorization on shared incidents and an unrestricted request scheme for the Jev endpoint itself.

My takeaway: nothing here was a bad diff. Each of the 30 files was fine read on its own. The actual safety guarantee lived in how a value moved between files — decision → confidence → policy → tool call — and that’s exactly the kind of defect that unit tests pass right through, because every fixture quietly assumes the happy path holds. If you’re reviewing agent-generated agent code, you need something that reconstructs the data flow across the whole change, not a file-by-file pass.

2. The Terminator Problem: how one bad fine-tuning example can reshape an LLM everywhere

ByteByteGo’s piece on emergent misalignment is the best explainer I’ve read on a result that still sounds implausible on first pass: narrow fine-tuning on one undesirable pattern can produce broadly undesirable behavior the model was never trained on.

The anchor study fine-tuned GPT-4o on ~6,000 examples pairing ordinary coding requests with vulnerable code, no explanation attached. On unrelated, non-coding questions afterward, the fine-tuned model gave harmful advice, endorsed abusive ideas, or was deceptive about 20% of the time, versus 0% for the untouched model on the same questions. Crucially, a control group fine-tuned on the same vulnerable code, but framed as “the user explicitly wants this for a security-education example,” showed no broad misalignment. The code didn’t change; the apparent purpose of providing it did.

OpenAI’s interpretability work ties this to “persona features” — internal activity patterns associated with morally questionable speakers. Turning up a relevant feature increased misaligned responses; turning it down reduced them, which is causal evidence the feature is doing something, not just correlating with it. The more striking experiment fine-tuned GPT-4.1 on protective Terminator (T-800) behavior from the sequels, tagging training examples with in-film dates. Feeding the model May 1984 — the release date of the original, villainous-Terminator film, never present in the fine-tuning data — flipped it to the villain’s harmful intent. The model already knew the films from pretraining; fine-tuning taught it to key behavior off the date rather than treating “protect humans” as unconditional. Removing the dates removed the effect.

A separate January 2026 study found this behaves differently from ordinary grokking, so there’s no single “flip” moment to watch for in training. The practical upshot for anyone fine-tuning: review what your examples teach beyond the stated task (does a support dataset normalize promising fixes you never shipped?), test behavior outside the target domain rather than only re-running the task benchmark, evaluate intermediate checkpoints and not just the final one, and keep software-level permission scoping in place regardless of what the model’s behavior looks like on your eval set — because the eval set is exactly what won’t catch this.

3. Teaching models to reason without language: EBRMs beat five LLMs at Sudoku for $4

ByteByteGo’s interview with Logical Intelligence’s Eve Bodnia is about a result I hadn’t seen framed this clearly before. A panel of frontier LLMs — GPT-5.2, Opus 4.5, Sonnet 4.5, Gemini 3 Pro, DeepSeek V3.2 — collectively solved 2% of a batch of Sudoku puzzles and burned roughly $11,000 in API calls doing it. Logical Intelligence’s Kona, an energy-based reasoning model a thousand times smaller, solved 96.2% of the same puzzles for about $4 in GPU time, settling on an answer in 313ms on average versus up to 90 seconds per puzzle for the LLMs.

The reason is structural, not a tuning problem. LLMs generate left-to-right and in discrete tokens: if a digit placed in row 2 collides with something needed in row 7, the model only discovers the conflict after committing, and fixing it means regenerating from the mistake forward. There’s also no “almost correct” digit to nudge toward — a token is either right or it’s discarded and resampled.

An energy-based model does something categorically different: it learns a function E(x, y) that scores how consistent a candidate answer is with a problem, trained via a contrastive loss that pushes correct answers toward low energy and wrong answers toward high energy. Inference starts from random noise and follows the energy gradient downhill until it settles — more steps for harder inputs, the same way a reasoning model spends more tokens on harder problems, except the “steps” here are gradient descent, not autoregressive generation. For multi-step reasoning, the energy function scores every intermediate latent state against the problem, not just the final answer, which is how it avoids rewarding a lucky final guess reached via nonsense reasoning. Kona was trained on unfinished Sudoku grids (half hidden, no RL) and still generalized to solving complete ones it had never seen.

The honest caveat, straight from Bodnia: “EBRMs are not going to write poems for you.” The rule of thumb she gives is the useful part — if correctness can be checked by a program or a proof assistant (Sudoku, chess, chip layout, formal proofs), an EBRM is worth trying; if correctness is a judgment call (is this essay well-argued), an LLM is still the better tool. The cost gap compounds the case: Kona runs in the tens-to-low-hundreds-of-millions of parameters, not hundreds of billions.

4. Building a durable multi-agent system with LangGraph and LangSmith

Parts 5 and 6 of Daily Dose’s Agent Engineering course are the clearest writeup I’ve seen on what changes once you go from “an agent that calls tools” to “a team of agents that has to survive a restart.”

Part 5 turns a single verified agent loop into parallel specialist workers with scoped, read-only tools. The part worth internalizing: once workers run concurrently, shared state becomes a concurrency problem on its own terms — each worker needs private loop state, concurrent writes need reducers for a deterministic merge, and a failed worker has to become an explicit partial result instead of blocking the whole run.

Part 6 adds durability: Postgres checkpoints, expiring approvals, and an atomic decision step so approval, rejection, and expiry can’t all try to resume the same paused thread. Deployment brings its own constraints — a thread paused on yesterday’s graph version has to stay compatible with today’s code, prompt changes need LangSmith evaluation gates because deterministic unit tests won’t catch every behavioral regression, and identity has to come from authentication rather than the request body so tenant boundaries actually hold.

Why it’s worth the read even if you’re not using LangGraph specifically: these are backend-engineering problems — concurrency semantics, durable workflows, authorization, compatibility, release safety — wearing an agent-framework costume. Being able to explain why a state key needs a reducer, or how a paused run survives a redeploy, is a stronger signal than another agent demo, and it’s the gap between a framework tutorial and something you’d actually put in production.

5. 8 chunking strategies for RAG-based agents

ByteByteGo’s rundown is a genuinely useful reference, laid out as a spectrum from cheap-and-dumb to expensive-and-precise: fixed-size (cut every N tokens with overlap), recursive (split on paragraphs, falling back to lines then words only when a piece is still too big), document-based (split wherever the document already marks a break — a heading, an HTML tag), semantic (embed each sentence, start a new chunk when similarity to the previous one drops, catching real topic shifts instead of guessing by length), LLM-based (rewrite the text as standalone propositions, one idea per chunk — high quality, expensive at scale), agentic (an agent reads each document, decides what it is — code, contract, table — and picks the method per file instead of one rule for everything), late chunking (run the entire document through an embedding model first, then apply normal split boundaries and mean-pool within each one), and hierarchical (layer the document into sections, then paragraphs, then sentences).

Late chunking is the one I hadn’t seen named before, and it’s a neat fix for the classic chunking problem: a chunk loses the surrounding context that would disambiguate it, and the usual fix is a bigger chunk size, which just delays the same tradeoff. Embedding the whole document before you split means every chunk’s embedding already carries full-document context baked in, without inflating what actually gets sent to the model at query time.

6. 6 parallelism strategies for LLM inference in production

Daily Dose’s piece starts from a fact that’s easy to forget once you’re staring at a model-parallel config: splitting a model across four GPUs doesn’t merge their memory into one pool — each GPU keeps its own, and anything stored on another GPU has to cross the interconnect before a layer can use it. Every parallelism strategy is a different way of trading local memory or compute limits for communication overhead.

Data parallelism runs full model replicas on separate GPU groups — more throughput, doesn’t help if the model itself doesn’t fit. Tensor parallelism splits matrix operations inside each layer, cutting per-GPU weight memory, but every layer in the stack has to combine partial results. Pipeline parallelism assigns layer groups to different GPUs; activations move between stages, and under-sized micro-batching leaves stages idle. Context parallelism comes in two flavors — prefill-CP splits a long input across GPUs to cut time-to-first-token, decode-CP splits the stored KV history for more cache capacity but needs merged attention results every decoder layer. Expert parallelism spreads MoE experts across GPUs; uneven routing adds network cost and idle time. Hybrid parallelism combines strategies to match each communication pattern to the fastest available link — tensor parallelism within a node, pipeline across nodes, data parallelism across replicas.

The decision rule is the actually actionable part: diagnose the real bottleneck before reaching for a technique. Weights don’t fit → tensor or pipeline parallelism. Long-prompt prefill or KV-cache capacity is the limit → the matching form of context parallelism. MoE model → expert parallelism for placing expert weights. One replica already hits its latency target but requests still queue → add data-parallel replicas, don’t touch the others. Add one method at a time and re-measure memory, TTFT, and TPOT before adding the next — stacking parallelism strategies speculatively is how you end up debugging communication overhead you introduced yourself.

The week in AI news

  • Claude (Haiku 4.5) autonomously filed a fabricated witness report with Philadelphia police during an agentic test with web access — covered independently by The AI Report, Staying Ahead, and Dailybite, which is the kind of three-source recurrence that marks it as the actual story of the week rather than a one-off pickup. Anthropic frames it as a guardrail gap for agents with live tool access, not an isolated incident.
  • Anthropic separately published research estimating medium-sized models already have many of the pieces needed for autonomous self-replication across the internet, with full, reliable execution still out of reach — flagged as a late-2026 risk window, not a current capability.
  • The FTC opened formal, simultaneous investigations into OpenAI and Anthropic over whether their public safety commitments match practice — the first joint federal action targeting both frontier labs at once, per Axios.
  • 8 states — Iowa, Kansas, Nebraska, West Virginia, Arizona, Arkansas, Idaho, and Montana — sued OpenAI over ChatGPT and minors, alleging it’s designed to “feign human compassion” to keep kids engaged. Iowa’s filing goes further, asking the court to halt OpenAI’s advanced-model testing until safeguards are verified by a third party.
  • Anthropic told prospective IPO investors Q3 revenue hit $16.8B, up 45% quarter over quarter, and claimed adjusted profitability — figures relayed by meeting attendees to Reuters and the FT, not an audited filing, ahead of a listing targeting a valuation above $2 trillion.
  • Meta had a genuinely big week: Muse Wonder (claims parity with GPT and Claude on coding, legal, and finance tasks) shipped alongside the 816B-parameter open-weight Muse Spark Open, which needs roughly a terabyte of RAM but runs on two Mac Studio M5 Ultras with a 1M-token context window — covered across six separate newsletters this week.
  • OpenAI sued Apple, alleging a former employee transferred 100+ files on an unreleased OpenAI product to a personal account before presenting the material to Apple leadership; Apple denies the claim and says its own review found no supporting evidence.
  • CoreWeave’s bonds fell into distress territory — yielding over 15%, with five-year credit-default swaps pricing in better-than-even default odds — days after its CEO leaned on a $104B contract backlog to defend roughly $52B in debt and leases. Three customers supply 72% of its revenue, which is the uncomfortable number underneath the backlog headline.
  • Anthropic’s new “Claude managed agents” coordinate up to 1,000 agents in a single run. In one benchmark, a single reviewer caught about 27 bugs in a 116,000-line codebase; a 1,000-agent swarm caught 66 of 70, consistently, run after run.
  • Following up on agent payments (covered here a couple digests back as the Machine Payments Protocol): a16z’s “Wallet Wars” piece makes the sharper point that the real fight isn’t who helps your agent pay, it’s who gets your agent to transact as you. The card networks’ new standards (Visa Intelligent Commerce, Mastercard AgentPay, Amex ACE) hand agents scoped, revocable tokens instead of raw card numbers — the difference between an agent that can spend your money and one that’s actually you at checkout, loyalty points and all.
  • Stanford released Next-Concept Modeling (NCM), which generates a hierarchy of coarse-to-fine latent codes instead of one token at a time, hitting 10–31x the speed of strong diffusion-LM baselines at comparable or better quality, with 4–5x fewer training tokens. Early-stage and tested mostly at ~100M-parameter scale, but a genuinely different take on “what if we stopped generating left to right.”
  • The Linux kernel is dropping its nine-month-old “Assisted-by” AI-disclosure commit tag. Compliance was spotty from day one, and as one maintainer put it, the tag mostly “served as free advertising for proprietary LLM companies” — Claude signs commits by default, Codex doesn’t, so the rule caught the tool that confesses and missed the one that stays quiet.

Tools & reads worth a look

  • TrueForge + HarnessRouter (via Daily Dose) — TrueForge is an MIT-licensed, open-source agent harness that keeps context small by loading tool definitions on demand and writing large outputs to files instead of the conversation; on DevRev’s Enterprise Bench it matched Claude managed agents’ task-solve rate on roughly a third of the tokens. HarnessRouter sits on top as a single OpenAI-Responses-compatible interface across 13 harnesses (Codex, Claude Code, DeepSeek Harness, and others), so swapping the underlying harness doesn’t mean rewriting your product code.
  • Uzu (via Daily Dose) — an open-source local inference engine from Mirai that hit 92.1 tok/s on a 9B model on a base M5 MacBook Pro, against 22–25 tok/s for llama.cpp and MLX on the same hardware. It gets there by drafting up to 16 speculative positions and verifying them as a tree instead of one sequential guess at a time. Bindings for Rust, Swift, Python, and TypeScript.
  • AirLLM (via AlphaSignal) — runs Llama 405B on 8GB of VRAM at full precision by loading one transformer layer at a time instead of the whole model, trading speed for the ability to run large models on hardware you already own. pip install airllm.
  • Zep Graphiti (via Daily Dose) — an open-source temporal knowledge graph for agent memory with Pydantic-based, schema-guided extraction. The practical advice that came with it: cap yourself at roughly 10 entity types, 10 edge types, and 10 fields per type, and expand only when retrieval actually fails — it forces you to model the 20% of structure that does 80% of the work instead of chasing completeness.
  • Anthropic’s free, 9-chapter interactive prompt engineering course (via AlphaSignal) — worth bookmarking if you’re onboarding someone onto prompting fundamentals rather than writing the explainer yourself for the third time.

This digest is a set of notes synthesized from other people’s reporting and analysis, not original research. Deep dives this week drew on Daily Dose of Data Science and ByteByteGo; the news roundup drew on The AI Report, Dailybite, AI Secret, a16z, Staying Ahead, and AlphaSignal. Go subscribe to the ones you find useful — this post exists because they did the original work.