DEV Community: Mixture of Experts

AI Engineer World's Fair 2026 Highlights

Mixture of Experts — Sun, 05 Jul 2026 00:38:33 +0000

Checkout our highlights below for the AI Engineer World's Fair 2026 Conference in SF!

We cover the latest on software factories, loop engineering, Fable 5 prompting guide, hardware improvements, and more!

Mixture of Experts with Alex & Norin Lavaee - YouTube

Short videos on coding agents and AI engineering. What actually works for developers, what's breaking the news, and how to best use coding agents. From siblings Alex and Norin Lavaee. Alex is at Microsoft Research building agentic systems and Norin is in AI/ML product ex Microsoft, Cisco, and some start-ups (founder + product manager). Connect with us on X: https://x.com/norlava Mixture of Experts Blog: https://alexlavaee.me/blog/

youtube.com

Ranking HumanLayer and Sakana AI Fugu-Ultra w/ Codex on the same issue

Mixture of Experts — Mon, 29 Jun 2026 03:55:41 +0000

Lots of new releases lately so thought it'd be nice to compare some new ones. Let's walk through an example real world issue comparing HumanLayer using GPT 5.5 Codex High and Codex using Sakana AI Fugu-Ultra. I show how each works, when to use each, and how to leverage workflows to test issues for correctness and code quality.

For how to improve prompting and workflows, you can check out our open-source playbook: github.com/bastani-inc/atomic/blob/main/docs/workflow-playbook.md

AI Research Engineer Open-Sources His Entire Workflow and Prompts

Mixture of Experts — Wed, 17 Jun 2026 00:18:59 +0000

Fable 5 came and went. And because it was taken away so quickly, developers wanted it back even more. Scarcity has a way of making things feel more valuable.

Reviews during its short tenure described a model that was very capable and great at churning on long-running, ambiguous tasks. But it was too expensive. The model was also intelligent enough that, on large work and overhauls, it tended to overthink. Most likely because of its size. For iterative work like implementing a feature or change, Fable 5 was comparable head-to-head with GPT 5.5, except Fable 5 would run for 10x as long: a larger model, more overthinking, and more time. The other issue was fallback behavior. If you hit a case where the model needed to call the fallback Opus model, you would not necessarily know it happened, and you would be billed at the higher charge.

Nonetheless, it was a noticeable change compared to existing models. It was good at churning on a specific, goal-oriented problem. For example, optimizing a slow path by repeatedly profiling, tracing call sites, tightening hot loops, and validating the regression budget. For architecture design, it was still not remarkable. So it was good at that goal-oriented push, but even within that you needed to run it in sessions, review its code, and steer or compact to get the results you wanted.

It is a good model to use for planning, research, and review, which is where I had adopted it. I saw real benefits. However, when it came to orchestration or running workflows, I still believe GPT 5.5 is better and more cost-effective on both tokens and time. Personally, I care about token spend, but I care immensely more about my time.

The bigger problem Fable 5 exposed

Model capability aside, I still think we are missing a bigger problem, and Fable 5 put a magnifying lens on it because of the nature of its capabilities. AI adoption in organizations is still a challenge for many developers because there are not enough good examples of how power users of coding agents are prompting, running workflows, reviewing outputs, and taking action.

So I am turning my process into a public workflow playbook: how I prompt, how I run workflows, how I steer them, and how I handle the edge cases that show up when agents are doing real work.

Here is the prompt I asked my coding agent to run:

Workflow usage guide generator

A privacy-preserving prompt for turning private workflow usage into a public developer guide.

<prompt>
You are helping me turn my private Atomic workflow usage into a public, developer-facing guide.

Your job is to analyze my workflow behavior, steering patterns, prompts, and decision-making style without exposing any private information.

<privacy_rules>
- Do NOT quote private session text verbatim unless it is completely generic.
- Do NOT include names, company details, repository names, customer data, file paths, secrets, strategy, internal roadmap details, or private implementation specifics.
- Replace concrete/private details with neutral placeholders like [project], [bug], [workflow], [internal tool], [customer], or [repo].
- Prefer synthesized examples over copied examples.
- If a useful example depends on private context, rewrite it as a safe fictionalized version.
- Flag anything that may be unsafe to publish instead of including it.
</privacy_rules>

<task>
Analyze my workflow usage and produce a practical guide for other developers showing how I use workflows effectively.
Focus on concrete behaviors, reusable prompts, steering moves, and examples developers can copy.
</task>

Look for:
1. The types of workflows I run most often.
2. How I define objectives and done criteria.
3. How I break down complex work into stages.
4. How I steer workflows when they go off track.
5. How I respond to workflow prompts or blocked stages.
6. How I use verification, tests, reviews, or acceptance criteria.
7. How I decide when to interrupt, resume, pause, or rerun.
8. Prompt patterns I reuse.
9. Mistakes or anti-patterns I avoid.
10. Lessons that would help another developer get better results.

<output_format>
Produce the following:

# Workflow Usage Guide

## 1. Executive Summary
A short overview of my workflow style.

## 2. Core Principles
List 5-10 principles I seem to follow when running workflows.

## 3. Common Workflow Patterns
For each pattern:
- Pattern name
- When I use it
- What the workflow usually does
- Why it works
- Safe public example

## 4. Steering Patterns
For each steering behavior:
- Situation
- What I usually say or do
- Why it helps
- Reusable public prompt

## 5. Prompt Templates
Create reusable prompt templates based on my behavior.
Do not copy private prompts directly. Generalize them.

Include templates for:
- Starting a workflow
- Tightening scope
- Adding acceptance criteria
- Redirecting a stage
- Handling a failed validation
- Asking for synthesis
- Turning results into implementation steps

## 6. Concrete Public Examples
Create 3-5 fictionalized but realistic examples showing how a developer could use these patterns.

Each example should include:
- Scenario
- Initial workflow objective
- Steering message
- Validation step
- Final outcome

## 7. Anti-Patterns
List behaviors I avoid or correct, such as vague objectives, missing validation, overbroad prompts, or accepting unverified output.

## 8. Publishability Review
Create a table with:
- Section
- Safe to publish? yes/no
- Risk
- Suggested redaction or rewrite

Important: prioritize usefulness for developers while preserving privacy.
</prompt>

The final asset is a workflow playbook you can hand to your own coding agent. It open-sources how I run workflows and prompt effectively, including how I define scope, set done criteria, steer blocked stages, verify results, and recover when a workflow goes off track.

Workflow playbook

Workflows are just my process made repeatable

The workflows I run are not the dynamic workflows or loops you see in Claude Code, Codex /goal, or Hermes Agent. They are literally programmatic automations of the work I already do, with human-in-the-loop checkpoints, review gates, and the ability to steer agents mid-run.

I do not manually prompt much anymore.

A good example: say you are doing a refactor. You probably find yourself running a prompt, then /compact, then running the same prompt again. Repeat that three times, compact again, and keep going. You probably do this very frequently.

It turns out that can just become a workflow. You repeat and micromanage less without giving up human autonomy. You also reduce slop because the workflow design handles the piping: what gets passed forward, what gets reviewed, what gets rejected, and where the human needs to make a decision.

Cost, time, and quality

In terms of cost, I spend more than regular Codex but significantly less than using Claude Code. In terms of timed runs, it is about the same as Codex at first glance, and much less again than Claude Code.

The quality of the result is where it shines. The workflow approach has a win rate of 75% against both Codex and Claude Code on the exact same issues, which means I actually spend way less time than I would be using Codex alone.

I tried solving real problems, not oversaturated benchmarks. I asked it to work through different kinds of tasks in a real-world codebase: a migration, a new feature, and a bug fix. The point was not to find one cherry-picked issue where a coding agent looked good. The point was to see whether a workflow-first approach stayed useful across different shapes of software work.

The migration required moving embedded PNG metadata from an older latin1-oriented chunk format to a UTF-8-compatible format while preserving legacy fallback behavior. The new feature required surfacing collaboration connection failures in the UI, which meant tracking transient connection state, wiring lifecycle events, cleaning up listeners, preserving accessibility, and adding tests. The bug fix required correcting arrow-curve behavior inside closed shapes without changing the expected behavior outside those shapes.

Across the migration and new-feature issues, the workflow-generated PRs consistently landed the safest technically correct change compared with the Claude Code and Codex PRs. For the PNG metadata migration, the Workflows PR wrote spec-correct UTF-8 iTXt, selected Excalidraw-keyed metadata, preserved legacy tEXt fallback, and validated emoji and on-disk chunk behavior; the other PRs had subtle compatibility bugs where unrelated or malformed iTXt chunks could shadow valid legacy metadata. For the collaboration-status feature, the Workflows PR had the best transient non-persistent state model, Socket.IO lifecycle handling, listener cleanup, accessibility, and targeted tests, while the alternatives had shared error-indicator state bugs or narrower lifecycle and UI coverage.

The bug-fix case showed the same pattern: the Workflows PR solved the actual arrow-curving bug with the narrowest safe behavioral change. It prevented premature auto-finalization while drawing inside the same start-bound shape, preserved normal binding and finalization for other targets, and added meaningful regression coverage. The rejected Claude Code and Codex alternatives either introduced a high-severity regression where simple click-created arrows no longer auto-finalized on bindable targets, or had weaker coverage around binding gaps, different target shapes, and finalization edge cases. Overall, workflows reduced AI slop by producing changes that were tighter in scope, safer for compatibility, better tested, and more careful about edge-case behavior than the competing agent-generated PRs.

That is why I am sharing the workflow playbook instead of only writing about the idea. The goal is for another developer to copy the patterns, adapt the prompts, and run a similar workflow-first process on their own codebase without needing my private context.

Personally, I see reliability and improved model capability exceed expectations when we keep the developer in the loop, not cut them out. I live this thesis daily.

Why I am sharing this

I think we need good examples of how to work with coding agents: what each person's workflow looks like, how they prompt, where they intervene, where they trust automation, and where they refuse to give up control.

The playbook is meant to make that concrete. It covers the workflow moves that matter in practice: starting with a tight objective, adding acceptance criteria, redirecting a stage, responding to blocked agents, handling failed validation, deciding when to pause or rerun, and turning the final synthesis into implementation steps.

The point is to demystify the work and make it easier for all developers to build. Let's make the bar as low as possible to get good results.

References

Build reliable long running agents w/ verification, worktrees, skills, subagents, & HIL/review gates

Mixture of Experts — Tue, 09 Jun 2026 21:36:49 +0000

There’s been a lot of buzz and discussion around loops and workflows in the past few days. There have also been many people chiming in that they’ve been doing this all along, posts about how it works, but less code examples that work for production codebases. At the end of the day, the goal is really around making long running agents reliable and steerable inside of real codebases. This article shows how to do that and how to build your own with the actual code provided.

You’ll see how an engine was built to power these loops or workflows. These terms are used interchangeably because it doesn't matter what word is used to churn hype, it's about how it works and what result it drives for agent reliability. You’ll also see the path to this architecture and why it was built the way it was and then the code (skip to whatever part you want).

There’s been good work to properly define what a loop is, but how do you just build one, and how do you build it in such a way that it doesn’t burn tokens and is reliable? @mvanhorn had a good writeup on the history of the concept, how developers are employing it, and how there is still such a major gap between AI used in real-world deployments because you do need a “production” version of a loop:

Which is why every serious 2026 write-up on loops converges on the same three hard stops: a maximum iteration count, no-progress detection, and a token or dollar budget ceiling. The romantic version of loops is that you write the loops and a thousand agents build your company overnight. The production version is that you write the loops, and most of your job is making sure they halt. Gartner puts agentic AI at the peak of inflated expectations, with only about seventeen percent of organizations actually deploying agents. The gap between the timeline and the receipts is the real state of play.

Additionally, @dexhorthy clearly pointed out that if you were to hypothetically start looping through everything without a care, you’ll end up in the zone of not understanding your codebase and slop:

Here’s what’s gonna happen:

you replace your code review with feedback loops (sentry, datadog, support tickets, etc)

you stop reading the code

software factory fixes everything

one day something breaks at 3am, agent can’t fix it

nobody’s read the code in 3 months

you have 3 weeks of downtime trying to re-onboard and fix it

you lose significant % of your contracts and users

your company is now dead.

If you’ve been trying to figure this out, you have probably noticed that coding agents don’t scale when it comes to work that is complex and ambiguous. You may also disagree with the sentiment that all you need is the model and for it to delegate its own orchestration. Real production code needs management across dependencies and teams, and you don’t have infinite tokens to burn. We feel the same.

We started with a harness that orchestrated multiple agents into workflows powered by the Opencode, Claude Code, and GitHub Copilot CLI SDKs. This approach didn't scale well because the SDKs all have slightly different interfaces, each has its own limitations for what you may want control over, and, lastly, as these teams are shipping fast, they frequently introduce bugs.

Then we learned about Pi and started exploring it as a minimal coding agent implementation. Pi is great because it is a simple harness and still fully extensible. The benefit of Pi is that you can leverage its large ecosystem of extensions/tools/MCPs, and it is a well-maintained project. We took Pi and used it as the runtime with control over its functionality and security, so we could focus on building a powerful engine for the coding agent to execute autonomously rather than worry about supporting multiple interfaces, squashing bugs, and managing three separate backends. The migration to Pi was the third rewrite of the system, but well worth it.

The next challenge we ran into are around traditional orchestration, reliability, and observability. The coding agent is an incredibly powerful primitive, but it becomes clear that it needs proper scaffolding with observability to work. From working with coding agents, you know that you need to be able to pass the proper context, steer, and have an easy way to observe what is going on so you can interrupt if things go wrong.

You also probably know that a lot of coding agent work feels reactive instead of proactive. It gets just close enough to what you want, then falls apart in the last 30% of the work, or worse, completely goes off track. You, like most, probably still spend most of your efforts manually prompting, writing markdown programs, or running the same skills in repetition. From all of this, it naturally makes sense to look at a way to automate this process.

After spending many hours thinking about problems around testing, intent alignment, the software development lifecycle, and speaking to developers about what they saw, experienced, and, very importantly, felt, we ended up with the following features to solve these challenges: review gates, support for parallel execution, human-in-the-loop gates, resume/pause capability for any stage in a loop, being able to steer mid-run, verbatim compaction (not what you see in coding agents today), and defining the workflow with any model that you desire so you can measure and manage your costs. Honestly, each part of the system has been specifically fine-tuned to work exceptionally for long-running coding-agent loops and deserves a blog post of its own for the architecture and how it was conceived. (Let us know if that is interesting, by the way).

This is not trivial to construct. There is a reason Claude Code dynamic workflows doesn’t have any of these features, because frankly it’s hard to build, and you have to go back to software engineering principles. Sorry, but the model won’t save you here. Secondly, there is a reason Peter, who shared the loops heard round the world tweet, didn’t share his setup. He has likely heavily optimized the OpenClaw ecosystem, and it would require serious reworking to generally work on all codebase shapes. So you need a solution that has good DX and works across different codebases and teams.

So that is what was built called Atomic. You can call it a workflow engine, a loop, loop engine, workflows, it doesn’t matter. The point is how it works and how easy it is to build your own.

The inner loop is the traditional ReAct loop where a model will execute until it finishes making tool calls. In contrast, the outer loop is organizing more complex/long-horizon tasks like software engineering into atomic units (like GH issues) and delegating each to a separate instance of an agent. You can take it a step further and even ensure your inner loop is consistent and verifiable. This is where static and dynamic workflows come in. This is not through simple prompts, but rather by giving the model a workflow meta-tool in the inner loop: the ability to define its own subroutines through subagent chaining and tool calling.

Atomic treats the coding agent as the inner loop and the workflow runtime as the outer loop.

The inner loop is still the normal agent loop: model reads context, calls tools, observes results, repeats until it produces an answer. Atomic does not replace that. The workflow engine wraps it with a typed, observable, resumable execution layer that decides which agent session runs, with what context, on what model, with which tools, in what order, and with what validation or human gate before continuing.

A workflow in Atomic is a TypeScript module, not just a prompt. See code at the bottom of the post for what the public API looks like.

The important part is the boundary it creates. Every ctx.task, ctx.chain, ctx.parallel, ctx.stage, ctx.workflow, and ctx.ui.* call creates explicit runtime structure. Atomic can see the graph, persist the state, attach to a stage, pause it, resume it, steer it, kill it, inspect transcripts, and preserve artifacts. That is very different from asking one model to “please do the following steps.”

Atomic supports both static and dynamic workflows.

A static workflow is the versioned TypeScript definition of a workflow. It has declared inputs, declared outputs, stage names, model choices, fallback chains, concurrency limits, human gates, worktree options, and artifact paths. You can commit it to .atomic/workflows, ship it through an Atomic package, or bundle it into the product.

A dynamic workflow is when the agent uses the workflow tool at runtime to create a tracked one-off task, chain, or parallel fan-out without a saved workflow file. That gives the model a workflow meta-tool inside its normal ReAct loop. Instead of merely saying it will ask three agents, it can actually spawn three tracked stage sessions, give each one clean context, collect their outputs, and synthesize them. If the pattern proves useful, you can promote it into a real TypeScript workflow.

The execution model is a DAG, but the developer does not need to manually draw the DAG. Atomic infers it from runtime control flow. Sequential awaits become dependent stages. ctx.parallel or Promise.all creates concurrent branches. Loops can create repeated stage groups. Child workflows called with ctx.workflow(...) are nested under the parent and shown in the same expanded graph. This matters because the graph is not just visualization, it becomes the control plane.

The runtime tracks:

stage name and status
input/output contracts
session file and transcript path
model and reasoning effort
fallback model attempts
errors and warnings
artifacts and output files
live pause/resume/interrupt handles
pending human input
nested workflow boundaries

The core design principle is that large context moves through files and artifacts, not through the model prompt. Small handoffs can use previous or {previous}. Large handoffs should be written to files with outputMode: "file-only" and passed forward with reads. This avoids the common failure mode where every stage inherits the full transcript of every prior stage and token usage explodes.

Atomic also separates context modes. Implementation stages can use forked context when continuity matters. Reviewer stages should usually use fresh context so they are not biased by the implementation agent’s reasoning. That distinction is one of the simplest ways to make review loops more reliable, where the reviewer reads the diff, artifacts, tests, and criteria, not the implementer’s biased thinking.

Self-verification is also a key part of the design. Atomic’s built-in Goal Runner and Ralph loops do not let the worker declare completion by itself: the worker leaves receipts, then fresh-context reviewers inspect the actual diff, spec, implementation notes, artifacts, and validation expectations. Those reviewers can run or delegate focused validation and must return structured review decisions; malformed decisions, reviewer errors, or unresolved validation gaps fail closed instead of approving. The review round is saved as an artifact, and the loop only stops when the structured verdict or reducer says the work is clean. That turns “the model says it checked its work” into a verification stage another agent or a human can inspect.

Human input is also part of the runtime. A workflow can call ctx.ui.input, ctx.ui.confirm, ctx.ui.select, or ctx.ui.editor at the exact point where a decision is needed. The run enters an awaiting-input state, the prompt appears in the workflow UI, and the answer is routed back to the correct stage. This is how you build approval gates, review gates, release gates, and “stop before destructive action” behavior without relying on the model to remember a markdown instruction.

Reliability comes from making the outer loop explicit. You can set a max iteration count. You can require structured reviewer outputs. You can run independent reviewers and reduce their decisions deterministically. You can fail closed when declared outputs do not validate. You can retry provider failures with fallbackModels. You can isolate work in git worktrees. You can cap output size. You can pause or interrupt a runaway stage and resume it with a steering message. These are boring software engineering controls, but they are exactly what makes long-running agent work survivable.

The model and cost are also prioritized. A workflow can use a cheap model for classification, a stronger model for implementation, a different model for review, and a fallback chain for critical stages. Model strings can include reasoning effort, e.g. openai/gpt-5.5:high or anthropic/claude-haiku-4-5:off, so cost and latency are controlled per stage instead of globally. Parallelism is explicit too, so a broad fan-out is a deliberate choice rather than the model deciding a path and burning tokens.

Observability is also a core mechanism. Atomic gives you /workflow status, /workflow connect, /workflow attach, /workflow pause, /workflow interrupt, /workflow resume, and /workflow kill. You can inspect the graph, attach to a single stage, send a steering message, answer a pending prompt, or resume paused work. The system keeps run history and terminal state around for inspection. A failed workflow is not just a giant lost chat transcript. It is a run with named stages, artifacts, errors, and receipts that you can analyze, measure, and improve.

So the architecture is:

Use TypeScript to define the outer loop.
Use separate agent sessions as atomic stage units.
Use fresh or forked context intentionally.
Use artifacts for large handoffs.
Use typed inputs and outputs as contracts.
Use parallel branches where independence is real.
Use review/human gates where correctness matters.
Use model selection and fallback per stage.
Persist everything needed to inspect, resume, debug, and measure ROI.
Let the model operate inside the loop, but do not let it be the loop.

Why not just skills? Skills are useful, but they are instruction bundles. A skill can teach the agent how to do something: how to review code, how to write tests, how to use Bun, how to follow a release process. But a skill does not give you durable execution state. It does not create a graph. It does not create independent sessions. It does not enforce typed inputs or outputs. It does not give you concurrency, pause/resume, stage-level model choices, human gates, artifacts, fallback models, or run inspection.

In Atomic, skills and workflows are complementary. A workflow decides when and where work happens. A skill improves how a specific stage performs its work. For example, a review stage inside a workflow can invoke a code-review skill. But the skill itself is not the orchestration engine.

Why not just markdown? Markdown is good for instructions, specs, and documentation. It is bad as a runtime. A markdown checklist cannot validate input schemas. It cannot schedule parallel branches. It cannot persist stage state. It cannot enforce output contracts. It cannot pause a running model call and resume it later. It cannot route a human approval answer to the correct stage. It cannot automatically keep large artifacts out of model context. It cannot expose a graph of what is happening.

Most markdown “workflows” are really prompts asking the model to simulate a workflow. That works for short tasks, but it degrades as soon as the task becomes long, ambiguous, or failure-prone. The model forgets steps, over-compresses context, repeats itself, hides uncertainty, or claims completion too early. Markdown can describe the process, but something else needs to execute the process.

Why not any other harness or hooks? You may have seen plenty of lightweight hook examples. This is not sufficient. You can build this on top of any harness, but this would require you to own the provider adapters, tool calling, sessions, transcript persistence, UI, MCP, extension loading, model configuration, auth, permissions, package discovery, and runtime controls. If you try the route of orchestrating several external CLIs and SDKs, it does not work well because every backend has slightly different semantics, failure modes, streaming behavior, context handling, and bugs.

Atomic builds on Pi because Pi is already a small, extensible coding-agent harness. That means the workflow engine can focus on orchestration instead of the agent runtime. Atomic gets the extension ecosystem, MCP/tools, model/provider plumbing, TUI surfaces, sessions, and package system, then adds the missing outer loop: typed workflow definitions, tracked stages, graph execution, human gates, artifacts, live control, and resumability.

The reason this matters is that production agent work is not just “call a better model.” It is systems engineering. You need boundaries, contracts, state, observability, failure handling, and cost controls. The model is powerful, but the model should be inside a system that constrains and verifies it. Atomic is an attempt to make that system open, inspectable, and easy to modify.

This is not necessary for every feature or bug fix. It’s most useful for large, ambiguous, long-running tasks where the difficulty is in managing the process, validation, and context. A GitHub-issue-to-PR run was recorded for you to review as well, so you can see a canonical example of how you can use it.

It’s not perfect, but it’s a shift toward less prompting and more designing the process for the agent to coordinate, validate, and reduce cognitive load. This is especially important for messy, large codebases. Atomic (bastani-inc) has a public implementation of this style of architecture. You can ask your coding agent to inspect and explain it.

There is no "right way" to build a scaffold or a system as we're all experimenting, but there are principles that are key to making sure that it does scale inside of any codebase shape. You should try it out on a scenario where a coding agent has failed you in the past, whether that be because your context was too large or because the agent misunderstood your intent and generated slop. Don’t take anyone’s word for it. Try it and see if this method can make it better.

Public API:

import { defineWorkflow, Type } from "@bastani/workflows";

export default defineWorkflow("review-change")
  .description("Research, review, and synthesize a change")
  .input("target", Type.String({ description: "Diff, PR, issue, or task" }))
  .output("result", Type.String())
  .run(async (ctx) => {
    const scoutPath = ".atomic/workflows/runs/review-change/scout.md";

    await ctx.task("scout", {
      prompt: `Map the relevant context for: ${ctx.inputs.target}`,
      context: "fresh",
      output: scoutPath,
      outputMode: "file-only",
    });

    const reviews = await ctx.parallel(
      [
        {
          name: "correctness-review",
          prompt: `Read ${scoutPath} and review correctness, regressions, and tests.`,
          reads: [scoutPath],
          context: "fresh",
          model: "openai/gpt-5.5:high",
        },
        {
          name: "maintainability-review",
          prompt: `Read ${scoutPath} and review maintainability and edge cases.`,
          reads: [scoutPath],
          context: "fresh",
          model: "anthropic/claude-sonnet-4:high",
        },
      ],
      { concurrency: 2 },
    );

    const final = await ctx.task("synthesis", {
      prompt: [
        "Synthesize the reviewer findings.",
        "Keep only evidence-backed issues.",
        "Separate blockers from optional suggestions.",
      ].join("\n"),
      previous: reviews.map((r) => r.text).join("\n\n"),
    });

    return { result: final.text };
  })
  .compile();

As with any writing, it’s important to know the background of the authors so you can decide how to weigh their observations and thoughts. Alex is an AI researcher at Microsoft Research, and he's spent time building and working on coding agents and developer tools over the past couple of years for MSR and Windows, solving challenges for using coding agents inside of a codebase that is 1 billion+ LoC. Prior to that, he's worked on uncertainty estimation at an MIT startup, and he has a research background in 3D vision and world models. Outside of his job, he's an open source builder on Atomic, where he's spent many hours refining, building, and working on coding agents. Norin's worked on AI/ML products at big tech and start ups on areas of productivity, hospitality, netdevops, and healthcare having shipped to 1B+ users worldwide. Norin is now working on better reliability for coding agents, search, and other interesting projects, including contributing to Atomic. Despite our profiles reading as quite AGI-pilled, we more often than not will exclaim how these models are being incredibly dumb. So hopefully we came across at least somewhat level headed, but you can decide that.

-Norin & Alex

References

Microsoft Build’s Developer Story Is the Agent Stack

Mixture of Experts — Wed, 03 Jun 2026 17:38:33 +0000

The story is the stack.

Microsoft Build’s most relevant developer announcements were not really about one better Copilot button. Microsoft appears to be turning Copilot into an operating layer for agentic software development: the model, desktop app, CLI, SDK, GitHub workflow, sandbox, Windows runtime, cloud dev environment, enterprise controls, and even local AI hardware.

That is useful. It is also a lock-in path.

tl;dr

GitHub Copilot is moving from autocomplete toward a control plane for multiple agent sessions, issues, PRs, worktrees, and merges.
Copilot CLI added terminal-native agent features: a rubber-duck critic, scheduled prompts, local voice input, and an experimental TUI.
MAI-Code-1-Flash matters less as a benchmark headline and more as a cost, latency, and supply-chain move.
Windows is being positioned as managed infrastructure for agents through MXC, WSL containers, Developer Configurations, and Windows 365 dev environments.
Early developer reaction is practical, not anti-AI: worktrees help, but Docker state, databases, secrets, pricing, and review burden remain hard.

What changed for working engineers

Announcement	Why engineers care	Caveat
GitHub Copilot app	A desktop hub for agent sessions, issues, PRs, “My Work,” worktrees, and Agent Merge.	Worktrees isolate branches, not databases, ports, secrets, or Docker state.
Copilot CLI	Rubber duck, `/every`, `/after`, local voice input, and an experimental TUI make agent work more terminal-native.	Long-running CLI agents still need recovery, logging, and trust.
Copilot SDK GA	Teams can build internal agents on Copilot’s runtime across Node/TS, Python, Go, .NET, Rust, and Java.	It ties agent architecture closer to GitHub/Copilot.
Copilot sandboxes	Local and cloud sandboxes give agents constrained places to run tools and code.	Sandboxing is necessary, not a complete safety model.
MAI-Code-1-Flash	A 5B coding model optimized for Copilot and VS Code workflows.	Microsoft’s benchmark claims need independent validation.

The Copilot app is the clearest signal. GitHub says each session runs in its own git worktree and that Agent Merge can watch CI, reviews, and merge conditions. That is a response to a real problem: once you run several coding agents at once, normal branch discipline stops being enough.

The CLI changes for /every and /after turn the terminal into a scheduler for recurring agent work. Rubber duck gives you a built-in critic. Copilot is spreading across every surface where engineers already make decisions.

Windows is becoming agent infrastructure

The Windows announcements matter if you think of coding agents as processes that need identity, filesystem access, networking, containers, and policy.

Microsoft announced Coreutils for Windows as generally available, WSL containers coming to public preview, Windows Developer Configurations as generally available, Windows 365 Developer configuration in public preview, an experimental Intelligent Terminal, and Microsoft Execution Containers, or MXC, in early preview.

MXC is the OpenClaw-relevant piece. Microsoft describes it as a policy-driven execution layer for agents across Windows and WSL, with declared access to files and networking enforced at runtime. Microsoft also says OpenClaw can run natively on Windows using MXC containment for the node and gateway.

That does not make Windows the best dev platform for every team. It does show Microsoft wants Windows to be a managed local and cloud runtime for agents.

The hardware signal

Surface RTX Spark Dev Box is not just another developer PC announcement. Microsoft says it uses NVIDIA RTX Spark, offers up to 1 PFLOP of FP4 AI compute, includes 128 GB unified memory, and ships with Windows 11 Pro, WSL 2 GPU passthrough/CUDA, VS Code, GitHub Copilot, Git, Python, and Node.js preinstalled.

Microsoft expects more agent development to be hybrid. Some inference, prototyping, evaluation, and parallel agent work moves local to reduce latency and cloud spend. The question is price and who this is really for: individual developers, platform teams, or enterprise AI labs.

What developers are worried about

The skeptical reaction is operational.

In technical Hacker News threads around the Copilot app, commenters liked the direction of worktree isolation but immediately raised the harder parts: Docker Compose, local databases, ports, secrets, migrations, and shared state. One recurring theme was that agents do not remove integration work; they can move it later, into review and merge cleanup.

That matches GitHub’s own framing. GitHub explicitly says agentic development has created disjointed workflows, more context switching, and too much review time. The Copilot app is a proposed answer to that problem, not proof the problem is solved.

Pricing is another early concern. Long-running agents consume tokens, cloud runtime, Actions minutes, and human attention. If agent-generated PR volume grows faster than review quality, “human in control” can degrade.

The New Stack’s Rayfin coverage frames the enterprise version of the same issue: AI-generated apps need governed production paths, not just fast generation.

Microsoft’s strategy read

Coding agents are moving out of chat boxes and into full development environments.

Microsoft’s guiding policy seems to be to own the default surface where enterprise engineers already work. That means GitHub for collaboration, Copilot for agent interaction, VS Code and the terminal for daily work, Windows and Windows 365 for managed execution, Entra/Intune-style controls for governance, and Microsoft’s own models where cost and latency matter.

Copilot becomes more like an operating layer across the software lifecycle.

The more your agents depend on GitHub sessions, Copilot SDK primitives, Windows execution policy, cloud sandboxes, and Microsoft model routing, the harder it becomes to move the workflow elsewhere.

Practical bottom line

Try the new functionality now if your team already lives in GitHub, Copilot, VS Code, or Windows-managed environments. Watch MAI-Code-1-Flash for real-repo latency and cost, not necessarily for high benchmark performance. Watch MXC and OpenClaw if you are building local or Windows-hosted agents.

These releases may not be as valuable to adopt if your workflow depends on open harnesses, local control, or flexible model routing, but can be interesting to learn from.

And treat every agent PR as untrusted work until your validation and review practices catch up. The tools are getting better but the bottleneck is still there.

References

Claude Opus 4.8 Is About Reliability

Mixture of Experts — Fri, 29 May 2026 18:59:50 +0000

Anthropic shipped Opus 4.8 into Claude Code with a familiar promise: better agentic coding. Does it make real developers more confident leaving Claude Code alone on production-shaped work?

TL;DR

Anthropic calls Opus 4.8 a “modest but tangible improvement.” That is the right frame.
The coding numbers are better, especially on harder agentic benchmarks, but they do not settle the model-ranking argument by themselves.
Claude Code quality still depends on the harness: effort level, context compaction, prompt cache behavior, tool permissions, and launch stability.
Pricing is premium. The right metric is not dollars per million tokens. It is dollars per accepted engineering outcome.
My read: use Opus 4.8 for hard, multi-step work where a failed agent loop costs real time. Do not use it for cheap bulk edits by default.

What changed technically

The model details are developer-relevant. Anthropic lists Opus 4.8 at a 1M token context window on Claude API, Bedrock, and Vertex AI, with 128K maximum output tokens. Microsoft Foundry is capped lower at 200K context.

The Messages API now accepts system entries inside the messages array, which means instructions can be changed mid-task without breaking the prompt cache in the same way. That sounds small, but it is exactly the kind of feature that matters for long-running coding agents: “plan first,” “now patch,” “now review your patch under stricter rules.”

Claude Code also gets dynamic workflows in research preview for Max, Team, and Enterprise plans. Anthropic describes this as Claude planning work and launching many parallel subagents. The headline example is Jarred Sumner using it on the Bun Zig-to-Rust port: roughly 750,000 lines of Rust, 99.8% of the existing test suite passing, and 11 days from first commit to merge.

What developers are reporting

Simon Willison highlighted the mid-conversation system prompt feature as practically interesting, and posted a small cost example where the best result used 25 input tokens and 17,167 output tokens, costing about 43 cents.

Hacker News reaction is mixed in the usual useful way. Some developers see benchmark fatigue: Opus 4.6, 4.7, and 4.8 all claim improvements, but day-to-day coding gains are harder to feel. Others argue the current coding benchmarks miss the parts of software engineering that hurt: unclear requirements, repo-specific conventions, migrations, flaky tests, and review cost. A recurring practical tip was to set Claude Code effort to xhigh for serious work. Another thread reported launch-day Claude Code breakage around thinking blocks.

Theo Browne’s developer-focused take is that Opus 4.8 is a “modest but tangible improvement,” especially for TypeScript-heavy work and “Claude special” UI tasks, but not a reason to ignore the old Claude Code risks. He treats benchmark wins like SWE Bench Pro cautiously, still sees GPT-5.5 xhigh as stronger in his mini-SWE-agent harness, and warns that dynamic workflows / “Ultra Code” can turn Claude into a powerful parallel coordinator for audits, bug hunts, and migrations while also burning money absurdly fast. His practical advice is to write detailed prompts up front, keep a root CLAUDE.md, monitor spend with CC usage, resume from summaries when limits hit, and verify everything, because Opus 4.8 can still hallucinate details like CLI flags.

Pricing: what it costs in reality

The obvious objection is price.

Model/path	Sticker price	Practical read
Claude Opus 4.8	$5 input / $25 output per MTok	Expensive, plausible for hard agent loops
GPT-5.5	$5 / $30 short context; $10 / $45 long context	Similar frontier tier, output can cost more
Gemini 3.5 Flash	$1.50 / $9	Better default for cheaper high-volume work
DeepSeek V4	Much cheaper	Strong cost pressure; workflow quality varies

Anthropic also offers batch pricing at half price: $2.50 input / $12.50 output per MTok for Opus 4.8. Prompt caching is $6.25/MTok for five-minute cache writes, $10/MTok for one-hour cache writes, and $0.50/MTok for cache hits. Fast Mode for Opus 4.8 is $10 input and $50 output per MTok for up to 2.5x higher output tokens per second, which is cheaper than the $30 input / $150 output Fast Mode pricing listed for Opus 4.6 and 4.7. But there is a catch: Anthropic says Opus 4.7 and later may use up to 35% more tokens for the same fixed text because of the tokenizer.

The real pricing question is not whether Opus 4.8 is expensive per token. It is whether it reduces failed or supervised loops enough to justify being on the critical path. If it prevents one botched refactor pass, it can be cheaper than a lower-priced model that burns context, leaves a half-correct diff, and hands the cleanup back to you.

Dynamic workflows complicate this. Parallel subagents can multiply progress. They can also multiply spend. Anthropic’s own docs warn that a workflow can use “meaningfully more tokens” than a normal conversation, counts against plan usage and rate limits, and can fan out to as many as 16 concurrent agents and 1,000 agents total per run. Public Claude Code issue reports make the downside less theoretical: Max users have reported hitting “out of extra usage” after one task and 155 tool uses in 9.5 minutes, and another Opus report claimed the limit arrived in roughly 10 minutes after about 20 prompts. Use workflows where the work decomposes cleanly and the result can be verified with tests, not as the default path for every substantial request.

Where Opus 4.8 fits

Artificial Analysis reports Opus 4.8 as a top-tier model, with a high Intelligence Index score and unusually heavy token usage during evaluation.

I would route Opus 4.8 to:

multi-file planning and risky refactors,
hard debugging across services,
codebase exploration before architectural decisions,
security-sensitive review with strict instructions,
long Claude Code sessions where recovery matters.

I would route cheaper models to:

rote edits,
test scaffolding,
formatting,
classification,
bulk summarization,
low-risk subagents.

The split is simple: use Opus where failure is expensive. Use cheaper models where retrying is cheap.

Practical verdict

Try Opus 4.8 immediately if you already pay for Claude Code and have high-value work that currently fails because the agent loses the plot. Set effort deliberately. Demand tests. Review diffs like you would review a fast junior engineer with infinite stamina and uneven judgment.

Wait if your work is mostly small patches, hobby automation, or batch code cleanup. Gemini, DeepSeek, Sonnet-class models, and cheaper paths may get you most of the value for much less.

If you are already getting good results from GPT-5.5, I would not switch by default. Opus 4.8 looks better, but not enough to justify moving a working coding workflow unless your own repo evals show a clear reduction in failed loops, review time, or total cost per accepted change.

References

Workflows Are the New Interface for Coding Agents

Mixture of Experts — Thu, 28 May 2026 22:11:53 +0000

Claude Code Dynamic Workflows are the clearest signal yet that the coding-agent market is moving past chat.

That is good news. From our own experience using workflows with Atomic for the past few months, it is the only way we work now. A single agent turn is the wrong shape for a migration, a security audit, a repo-wide bug hunt, or a plan that needs adversarial review before anyone trusts it.

That shift matters more than the specific product announcement. The future is not just better models. It is better control planes around models.

Why workflows matter

Software engineering is not one action. It is a sequence of judgment-heavy phases:

understand the system,
choose the work surface,
write or update a plan,
implement in bounded chunks,
verify with tests and reviewers,
leave artifacts the next engineer can trust.

Chat can imitate that sequence. A workflow can enforce it.

Subagents and skills are useful building blocks, but the goal is a workflow that owns the loop: branching, retries, review gates, and intermediate state. Intermediate results should not all be dumped into one context window. Reviews should be independent. Long-running work should be observable while it runs.

But once the plan becomes code, the next question is: who owns that code?

Claude Code Dynamic Workflows: impressive, but Claude-centered

Dynamic Workflows are impressive because they make orchestration feel native: describe a task, let the runtime fan out work in the background, and inspect progress through /workflows. The headline use cases are exactly where workflows shine: codebase-wide audits, large migrations, cross-checked research, and critical plans that need multiple attempts and adversarial review.

But the product shape is still Claude-centered. Claude writes the workflow, Claude runs it, and Claude decides a lot of the orchestration. Public docs also describe real boundaries: research-preview status, higher token use, session-scoped resume, limited mid-run user input, and workflow scripts that coordinate agents without direct filesystem or shell access.

For many teams, that will be enough. For engineers who want the workflow layer to be their own infrastructure, it leaves an opening.

Atomic: workflows as developer-owned infrastructure

Atomic starts from a different premise: the workflow is not an implementation detail of the assistant. It is the interface the developer should own.

The repo describes Atomic as “the workflow layer for coding agents” and a programmable control plane where the model-backed session does the work, but Atomic makes sure it follows the process. Under the hood, Atomic is a TypeScript/Bun monorepo built on Pi packages. The CLI bundles first-party packages for workflows, subagents, MCP, web access, and intercom. That matters because Atomic is not just a prompt convention. It is an extensible runtime.

A workflow in Atomic is a TypeScript module:

import { defineWorkflow } from "@bastani/workflows";

export default defineWorkflow("review-changes")
  .input("target", { type: "text", required: true })
  .run(async (ctx) => {
    const research = await ctx.task("research", {
      prompt: `Map ${ctx.inputs.target}`,
    });
    const reviews = await ctx.parallel([
      {
        name: "correctness",
        prompt: "Review for regressions",
        previous: research,
      },
      { name: "risk", prompt: "Review edge cases", previous: research },
    ]);
    return { reviews };
  })
  .compile();

The important part is not the syntax. It is the contract. Atomic exposes tracked stages, parallel branches, context handoffs, artifacts, human input through ctx.ui, resumable run control, model fallback chains, reusable worktrees, and package distribution. Workflows can live in .atomic/workflows/ for a project, ~/.atomic/agent/workflows/ for a user, settings, or packages. They are inspectable files, not just successful conversations you saved after the fact.

The built-in Atomic loop

Atomic already ships with the workflows engineers usually end up rebuilding by hand:

Workflow	Use it when
`deep-research-codebase`	You need a broad repo investigation with scout, specialist waves, aggregation, and durable research artifacts.
`goal`	You have a bounded change with explicit done criteria, validation, receipts, and reviewer quorum.
`ralph`	You want a larger plan-to-PR loop: RFC, implementation, simplification, infra discovery, review, and handoff.
`open-claude-design`	You are doing UI/design work that benefits from generation, critique, live preview, and quality gates.

The canonical Atomic flow is straightforward, and you can invoke it conversationally instead of memorizing slash commands:

Run deep research to map payment retry behavior across this repo.
Create a spec from research/payment-retries.md.
Use goal to implement the spec and run the focused retry tests.
For larger work, run ralph to plan, implement, review, and prepare a PR for the spec.

That gives engineers a process they can inspect: research files, specs, ledgers, worker receipts, reviewer decisions, final reports. If the work fails, you are not left with “Claude tried.” You have artifacts that explain where it failed.

And if that is not your process, you write your own. Incident response, release readiness, dependency audits, migration scoring, accessibility review, docs QA, benchmark triage: the workflow surface is general-purpose.

The deeper difference: control, visibility, confidence

Claude Code Dynamic Workflows make orchestration easier to ask for. Atomic makes orchestration easier to own.

That distinction shows up in four places:

Concern	Claude Code Dynamic Workflows	Atomic
Workflow authoring	Claude dynamically creates orchestration scripts for the current task; successful runs can be saved back into Claude Code.	Developers can ask Atomic to use a workflow, describe new workflows in natural language for Atomic to scaffold, or version explicit TypeScript workflows as repo-owned code.
Human gates	No mid-run user input; split stages into separate workflows when sign-off is needed.	Developers can define explicit human-in-the-loop gates, attach to running sessions to steer them, and pass or reject gates before the workflow continues.
Cost and scale	Designed for large fan-outs, including tens to hundreds of subagents; Anthropic notes this can consume substantially more tokens than a typical Claude Code session.	You choose the graph and concurrency. Atomic can stay small and deterministic, or scale out when you intentionally design a broader workflow.
Provider choice	Built for Claude Code and Claude-supported surfaces.	Model/provider agnostic through Pi: Anthropic, OpenAI, Gemini, Bedrock, OpenRouter, local OpenAI-compatible servers, custom providers, and more.
Extension surface	Workflow runtime plus Claude Code ecosystem.	Pi packages can add extensions, tools, slash commands, skills, prompt templates, themes, TUI components, and workflows.

There is also a practical supply-chain detail worth saying carefully. Atomic’s published CLI package does not require install lifecycle scripts, and the README explicitly says you can install it with --ignore-scripts. That is a safer default for a tool you install globally.

It does not mean arbitrary third-party Atomic packages are magically safe; Atomic’s own docs warn that packages and extensions run with full system access. The point is narrower and useful: the base tool keeps the core install simpler, while still letting teams review and choose the extensions they trust.

What engineers should internalize

Workflows are not only for giant rewrites. Use them whenever process fidelity matters more than conversational flexibility:

broad research where findings should become durable memory,
risky changes that need independent review,
migrations with repeated file-level work,
tasks where validation must be captured as evidence,
team processes you want every agent run to follow the same way.

Use chat for exploration. Use subagents for delegation. Use workflows when the process is part of the product.

Claude Code Dynamic Workflows validate the category. They show that serious agentic coding requires scripts, background execution, parallelism, and cross-checking. Atomic pushes the same idea one layer closer to the engineer: workflows as open, inspectable, model-agnostic infrastructure you can keep in the repo, modify, package, review, and run again.

That is where coding agents are going. The winners will not be the tools that hide the workflow best. They will be the tools that make the workflow visible enough for engineers to trust.

References

The New Shape of Supply-Chain Trust

Mixture of Experts — Thu, 28 May 2026 15:40:38 +0000

One poisoned extension, one package install, one CI workflow. Any of them can now be the first domino.

That is the uncomfortable lesson from the latest Shai-Hulud activity and GitHub’s recently confirmed internal-repository breach. The scary part is not only the number of affected packages, tokens, or repositories. Counts move fast. The scarier part is where the attacker code ran: inside the trusted developer and CI path.

The modern supply chain is not just “the dependencies we ship to production.” It is your IDE, your package manager, your GitHub Actions runner, your cache keys, your OIDC flow, your local gh auth, your AI coding tool config, and the cloud account that quietly pays the bill when something goes sideways.

What happened, briefly

CISA described the original Shai-Hulud wave as a self-replicating npm worm that compromised more than 500 packages and targeted GitHub personal access tokens plus AWS, GCP, and Azure keys. GitHub later said it removed 500+ compromised packages and began pushing npm toward shorter-lived credentials, 2FA enforcement, and trusted publishing.

The later waves got more CI-aware. Instead of only stealing npm tokens from maintainers, they looked for credentials inside build environments, abused publishing workflows, and used the build system itself as distribution.

Microsoft’s May 2026 reporting on the @antv ecosystem described a “Mini Shai-Hulud” style campaign that targeted GitHub Actions environments and stole GitHub, AWS, Vault, npm, Kubernetes, and 1Password secrets. Microsoft said GitHub removed 640 malicious packages and invalidated 61,274 npm granular access tokens with write permissions and 2FA bypass.

Then GitHub confirmed an incident involving a compromised employee device and a poisoned third-party VS Code extension. GitHub said the attacker’s claim of roughly 3,800 internal repositories was “directionally consistent” with its investigation, while also saying its current assessment was exfiltration of GitHub-internal repositories only.

The Nx Console advisory gives the developer-tooling angle teeth: malicious version 18.95.0 was available for about 18 minutes in the Visual Studio Marketplace and about 36 minutes in OpenVSX. Nx later estimated roughly 6,000 VS Code activations and one Cursor activation.

Eighteen minutes was enough.

Why normal controls did not fully save us

The lesson is not “security controls are useless.” The lesson is that every control has a boundary.

Control	What it helps with	What it can miss
2FA	Account takeover	Legitimate workflow publishing malware
Provenance/OIDC	Long-lived npm tokens	Compromised build runtime
Secret scanning	Finding leaked keys	Damage before detection
Lockfiles	Version drift	Already-poisoned dependency paths

2FA helps when the attacker needs to log in as you. It helps less when malicious code runs inside a workflow that is already allowed to publish.

OIDC and trusted publishing are good. Use them. But provenance is a receipt, not a sandbox. It can prove where an artifact was built. It cannot prove that the runner, cache, script, or workflow context was clean when the build happened.

Secret scanning matters too, but it is often reactive. If a token was already copied, the clock has started.

The developer workstation is production-adjacent

Developers used to think of laptops as local machines with local risk. That model is dead.

A typical engineering workstation now aggregates source code, GitHub auth, npm credentials, cloud CLIs, database tunnels, SSH keys, package-manager caches, editor extensions, AI assistant configs, and sometimes production-adjacent environment variables. That is not “just dev.” It is a credential hub with a keyboard.

If the package ran on your laptop, assume the laptop’s reachable secrets were in scope.

Package lifecycle scripts make this worse because install-time code execution is easy to forget. IDE extensions make it worse because they run close to code and credentials. CI makes it worse because runners often hold the exact permissions attackers want: publish, deploy, fetch secrets, assume roles, and write artifacts.

That is the break. Not npm. Trust.

The vibe-coding angle

AI coding tools are not the villain here. Fast, invisible execution with broad credentials is the villain.

Vibe coding often means moving through dependencies, extensions, MCP servers, generated config, local dev servers, and shell commands quickly. That speed is useful. It is also a larger trust surface. If an agent suggests a package, installs it, edits config, and runs a script in the same environment where your cloud credentials live, you have collapsed experimentation and authority into one place.

JFrog reported Shai-Hulud-like activity targeting developer and AI-tooling configuration surfaces. Treat that as the direction of travel, not as proof that AI caused the incidents.

Vibe coding with long-lived credentials is supply-chain roulette with better autocomplete. The answer is not to stop using AI tools. The answer is to stop giving every tool the same blast radius.

Boring controls that actually work

For engineers, the practical response is operational hygiene:

Pin dependencies and commit lockfiles.
Add a release-age cooldown for new package versions where your tooling supports it.
Disable or restrict package lifecycle scripts when feasible.
Run risky installs in dev containers, Codespaces, or disposable sandboxes.
Pin GitHub Actions to commit SHAs, not floating tags.
Require signed commits on protected branches so pushed changes are cryptographically tied to trusted developer keys.
Audit pull_request_target, cache restore paths, workflow permissions, and publishing jobs.
Prefer OIDC and trusted publishing, but treat the CI runtime itself as sensitive.
Delete long-lived tokens. For the ones you cannot delete, shorten expiry and rotate automatically.
Use WebAuthn/MFA and secret scanning with push protection.
Monitor npm publishes, CI egress, cloud/API usage, and billing anomalies.
After suspected compromise: isolate hosts, rebuild runners, invalidate caches, then rotate credentials.

The best teams will not be the ones that never touch a bad package. That bar is fantasy. The best teams will be the ones where a bad package gets a tiny window, a tiny credential scope, and a loud billing or usage alert.

Proactive beats reactive because by the time you are rotating everything manually, the worm has already learned your org.

References

Alignment is moving into the agent control plane

Mixture of Experts — Tue, 26 May 2026 17:03:53 +0000

tl;dr - Plan Mode, Outcomes, Skills, and agent-as-judge workflows point toward a shared pattern: reliable coding agents depend less on a single prompt and more on the planning, steering, memory, and verification systems around the model.

A coding agent can be safe and still produce the wrong work.

A typical failure is not catastrophic behavior. It is a smaller mismatch between the requested change and the implemented change: an issue asks for a sliding-window rate limiter on /api/upload, and the agent implements a token bucket on /api/files, adds an unnecessary configuration flag, and updates the docs around that mistaken interpretation. The tests may still pass.

The problem is not model safety in the broad sense. It is intent alignment inside a specific repository, under incomplete requirements, with constraints that may not have been written into the prompt.

The current tooling suggests that the fix is no longer just waiting for a smarter model. Plans, skills, persistent instructions, rubrics, judge agents, review agents, tasks, and memory are all becoming part of the same system.

Taken together, these tools suggest that alignment is becoming less concentrated in the model itself and more dependent on the control plane around it: the artifacts, rubrics, reviewers, memories, and human decision points that shape the agent's work.

The old prompt loop is too narrow

The default workflow still treats intent as something that can be captured in one exchange:

Give the agent a long prompt, a /goal, or a bundle of instructions.
Let it edit files, run tests, and possibly spawn reviewers.
Review the resulting diff.
Explain what it misunderstood.
Repeat until the result is acceptable.

That loop made sense when the unit of work was one chat session and one assistant. It starts to break once agents can run for hours, touch many files, write tests, and produce changes faster than a human can review them.

A final pull request is not a large enough channel for intent in that setting.

By the time the diff exists, the agent has already made several important decisions: which files matter, which constraints are optional, which existing pattern to copy, what "done" means, and how to behave when tests are missing. If those decisions are wrong, review becomes a reconstruction exercise rather than a steering mechanism.

The newer tools address that problem by making the agent externalize its assumptions before, during, and after the work.

First, make the plan editable

Cursor's Plan Mode makes the agent research, ask clarifying questions, and write an editable Markdown plan before it changes code. Cognition's Devin 2.0 puts a preliminary plan and the relevant files in front of the user early. JetBrains Junie, GitHub Spec Kit, and AWS Kiro are all moving toward a similar sequence:

requirements.md → plan.md → tasks → code

The important part of this sequence is that it moves misunderstanding earlier in the process.

If the agent misunderstands the request at the plan stage, the correction is usually a sentence in a Markdown file. If it misunderstands the request during implementation, the correction requires diff review, rework, and cleanup from side effects that may already have spread across the codebase.

A useful plan makes the important constraints inspectable before code exists: use /api/upload, not /api/files; avoid a new configuration flag; reuse the existing limiter; add the regression test first.

The plan is the first alignment surface.

Steering has to continue during the run

A plan does not remove drift from long agent runs.

Anthropic's Measuring AI agent autonomy in practice reported that Claude Code now interrupts itself for clarification on hard tasks more often than human reviewers interrupt human pairs. That behavior is not only a UX detail. It is a control mechanism.

A useful agent should be able to identify when it is guessing.

Task lists serve the same purpose. They are not only progress reporting. They expose the agent's decomposition while the work is still in progress:

- [ ] Add upload rate-limit middleware
- [ ] Create new limiter config flag
- [ ] Update /api/files tests

The second and third items show the misunderstanding while it is still cheap to correct. Waiting until the final diff makes the same issue harder to isolate.

Parallel skills make this more important. A frontend skill, migration skill, test-writing skill, and reviewer agent can all run at once. That can increase throughput, but it also creates more places where the system can choose a different definition of done unless each worker exposes its assumptions, tasks, and intermediate state.

Once a workflow involves multiple agents, chat and PR review are not enough. The system needs visibility into what each agent believes it is doing while the work is still happening.

Intent has to survive the session

The next problem is memory.

This is not memory as user personalization, and it is not only a library of reusable skills. Procedures are useful, but the more important layer is actionable memory: what the system learns from what happened in previous runs.

Every serious agent run leaves evidence behind. The plan it wrote, the files it opened, the assumptions it made, the commands it ran, the reviewer comments it ignored, and the human correction that finally made the work acceptable are all useful signals.

That evidence should not disappear into chat history. It can become a learning loop:

run logs → candidate lessons → evaluator → behavior updates → future runs

After the rate-limiter failure, the lesson is not simply "write a rate-limiter skill." The useful lesson is narrower: when an issue names an endpoint, verify the route before editing; do not introduce product-facing configuration unless the plan explicitly asks for it; if the requested algorithm and the existing pattern disagree, stop and ask.

Those are behavior updates. They can land in project instructions, planner rubrics, reviewer checks, interruption policies, or sometimes a skill. They should also be evaluated before they change future behavior. The evaluation should ask whether the lesson is supported by the logs, scoped narrowly enough to be safe, and likely to prevent the same class of mistake.

This also changes how improvement can be measured. Keeping logs, lessons, and evaluation outcomes makes it possible to ask whether scope drift is decreasing, whether reviewers are catching fewer repeat mistakes, whether human corrections are getting smaller, and whether a memory update reduced errors or only added prompt noise.

Memory without evaluation doesn't hold as much value. Memory tied to logs and evals becomes an improvement system.

Verification has to check intent

Tests describe whether the code behaves according to the cases that were written down.

They do not necessarily show whether the agent built the requested thing.

That gap is why Anthropic's Outcomes primitive is interesting. An Outcome is a Markdown rubric that a separate agent can use to grade the result in a fresh context. The planner can loop until the rubric is satisfied. The relevant shift is that the system does not only ask whether a command passed. It asks whether the result satisfies criteria that were written before implementation started.

For the rate limiter example, a useful rubric might say:

The implementation is successful if:
- /api/upload enforces a sliding-window limit per authenticated user.
- No new product-facing configuration is introduced.
- The change does not affect /api/files.

That gives the reviewer a contract. The review is no longer based only on whether the diff looks reasonable.

The Agent-as-a-Judge survey points in the same direction: judge agents become more reliable when they observe intermediate steps instead of grading only the final answer. Observation matters because the review agent needs to understand how the work happened, not only inspect the final diff.

One agent builds. Another checks. A rubric defines the target. The human still decides which failures matter.

The stack is converging

Plan. Steer. Remember. Verify.

These used to look like separate research and product threads. They are now becoming the standard shape of the agent stack.

Layer	Artifact	What it protects
Plan	`plan.md`, `.cursor/plans/`, Spec Kit, Playbooks	The agent's understanding before code
Steer	Tasks, clarification interrupts, live progress	The trajectory during work
Remember	Run logs, evaluated lessons, behavior updates, memory systems	Learning from previous work across sessions
Verify	Outcomes, rubrics, judge agents, review agents	Whether the result matches intent

The important shift is that agent reliability becomes a systems problem, not only a prompting problem.

The plan is an interface. The skill is an interface. The task list is an interface. The rubric is an interface. The reviewer prompt is an interface. Each one carries intent from one part of the system to another.

That work is software design applied to a different set of components.

What this means for engineering teams

Model providers can ship better models. Tool vendors can ship better planners, spec workflows, playbooks, and review systems.

Those tools still do not know what correctness means inside a specific codebase.

They do not know that the billing system treats retries differently for enterprise customers. They do not know that the migration tool must be run through drizzle:generate, not raw SQL. They do not know which product constraints are implicit because everyone on the team has internalized them.

That knowledge has to live somewhere durable and usable.

If it lives only in a person's head, the agent will miss it. If it lives only in chat, it will disappear. If it appears only in final PR review, it will arrive after many decisions have already been made.

The practical work is straightforward and valuable:

Write plans the team can edit.
Preserve run logs, reviewer findings, and human corrections.
Turn repeated failures into scoped candidate lessons.
Evaluate those lessons before changing the agent's behavior.
Make success criteria explicit before implementation.
Measure whether memory updates reduce drift, repeat mistakes, and human correction.

This is the control plane for coding agents.

The control plane is becoming the main editing surface

For years, the editor was where most software work happened. Code changed, the compiler or test suite responded, and the feedback loop stayed local and visible.

Coding agents move part of that loop up a level.

Important edits are now often made outside handler.ts: in plan.md, SKILL.md, CLAUDE.md, task lists, rubrics, and reviewer instructions. Those files decide what the agent sees, what it is allowed to change, how it reports progress, and how the result gets judged.

The model is still important, but it is not the whole product. The product is the system around it: artifacts, reviewers, memories, checks, and human decision points that convert model capability into reliable work.

The practical advantage comes from designing that surrounding system well.

How to align coding agents with your plans better than markdown, without burning tokens

Mixture of Experts — Thu, 14 May 2026 22:14:54 +0000

The expensive moments in a coding-agent session are not the model's tokens. They are the seconds you spend skimming a markdown plan and missing a subtle misalignment. You approve, then watch the implementer solve a slightly different problem than the one in your head.

We have started treating that gap as a UI problem, not a model problem. And the UI we have, for coding agents specifically, is bad.

Thariq Shihipar at Claude Code has been making this case publicly for a while: agents should be emitting HTML, not markdown, for most non-trivial output. His thread is the right primer on why, and we're not going to try to re-derive it here. What we want to add is the piece that has been missing for us. We needed a way to use HTML at every plan stage without the token cost stacking up across the session. That way is a screenshot, borrowed from how DeepSeek-OCR handles context compression.

Thariq's article.

The case Thariq makes, in three parts. We will not reproduce Thariq's thread in full. We suggest reading it. The arguments worth restating here are the ones the rest of this post leans on:

Markdown won by inertia. It rendered everywhere, was easy for a human to hand-edit, and the kinds of plans agents used to produce were short. None of that still binds. Most people are no longer hand-editing agent-generated specs, they are prompting the agent to edit them. Plans have grown into full RFCs. And every modern reviewer has a browser tab open.
HTML carries information markdown cannot. Tables with real column alignment, SVG diagrams drawn to scale, before/after panels rendered side by side at the same visual weight. In the absence of those, agents fall back to ASCII boxes and unicode block characters approximating colors. That fallback is what most markdown plans actually look like at length, and it is why nobody reads past line 100.
Information density matters most at the plan stage. This is where the gap between what the agent thinks you want and what you actually want is widest. Forcing the plan through a flat-text encoding is a lossy compression step you do not need to be performing.

Thariq catalogs the use cases: plan stages with branching options, design and prototype reviews, PR walkthroughs, code and architecture explainers, throwaway custom editors that end with a "copy as JSON" button. We have ended up using HTML for all of those. Our experience matches his closely enough that the right move is to point you at his thread rather than re-list them.

Where this landed for us: design work with a coding agent

The plan-stage argument is the one that converted us, and design work is where it shows up most starkly.

The last time we were iterating on a UI change with Claude Code, we asked for the plan as a single-file HTML artifact instead of the usual markdown. Two columns, BEFORE on the left, AFTER on the right, rendered with the real tokens and chrome the UI actually ships.

The point is not the specific feature. The point is that one artifact got us to high-fidelity comprehension in a single round trip. The markdown equivalent would have been a paragraph of prose and a bullet list. Readable, but lossy in exactly the ways that matter for a visual change. Getting to the same level of confidence through markdown would have taken three or four back-and-forth turns of "what does this look like next to X" and "show me the spacing," each one re-tokenizing the conversation and giving us a worse mental picture than the rendered comparison did instantly.

The expensive operation is reading the spec and noticing what the agent got wrong. Spending model tokens on rendered HTML pays for itself the first time it replaces three turns of "what does this look like next to X" with one look.

Where Thariq's argument gets harder: token cost on long sessions

HTML is not free. A single artifact comparing two design approaches with inline styles, SVG, and full content runs roughly four to six times the tokens of the equivalent markdown plan. Generation also takes two to four times longer. On a one-shot artifact that's fine. On a long coding-agent session, the plan gets re-read by the implementer, then the reviewer, then the follow-up planner. The HTML keeps getting re-tokenized into context, and the cost stacks up across the session.

This is the part Thariq's posts don't fully address, and it's why HTML stayed a sometimes-tool for us instead of a default. The fix came from a different research direction.

DeepSeek-OCR is the missing mechanism

DeepSeek-AI's paper DeepSeek-OCR: Contexts Optical Compression makes a simple claim: a page of text rendered as an image and processed by a vision encoder can be encoded into far fewer tokens than the same text processed as text. Their model card lists the encoding modes. A 1024x1024 image of a full page becomes 256 vision tokens. Their Tiny mode does it in 64. For content that has visual structure, the image channel encodes more per token than the text channel by a wide margin.

Paper: https://arxiv.org/abs/2510.18234
Model card: https://github.com/deepseek-ai/DeepSeek-OCR

You do not need to run their model to borrow the mechanism. Once you have an HTML artifact you are happy with, you do not need to keep the HTML itself in context for subsequent agent calls. Render it, screenshot it, feed the PNG back as an image. The vision tokens encode the same spec at a fraction of the text-token cost, and the human-readable HTML is preserved on disk for the next time you need to iterate.

The workflow we have settled into:

Agent generates the HTML artifact as part of the plan stage.
We open it in a browser, review, edit if needed, approve.
A small wrapper renders the artifact and captures a PNG.
Subsequent agent calls receive the PNG as part of the spec, not the raw HTML.

The trade is asymmetric. Our review happens against the rendered HTML, where spacing, alignment, and color do the work of catching the misalignments. The model's re-reads across the implementer and reviewer stages happen against the screenshot, which costs a fraction of the text tokens. Iteration cost stays close to a markdown plan. What we can see in one glance goes way up.

This is what moved HTML artifacts from "nice when I remember to ask for one" to "default at every plan stage" for us.

Why coding-agent TUIs have not shipped this yet

Claude chat ships artifacts. ChatGPT canvas ships canvas. The chat side of the ecosystem worked this out a while ago: prose-only loses information at exactly the moments that matter most.

The coding-agent TUIs (Claude Code, Codex, Opencode, etc.) are still markdown-first across every stage of the loop. Part of the reason is that TUIs render in terminals, and terminals do not render HTML. But the artifact does not need to live inside the TUI. A hook that drops the file in a browser tab or a side panel solves the rendering problem. The harder constraint is that the agent has to know when an HTML artifact is the right tool, and most plan-stage prompts never ask for one. The default is markdown, the path of least resistance is markdown, and you find out about the misalignment after the implementer is halfway done.

In the short term the fix is one line in your plan-stage prompt: ask for a single-file HTML artifact when the problem is comparison-heavy, visual, or architecturally branching. Then add the screenshot step before the artifact gets re-read by downstream agent calls. In the longer term we want the agents to reach for HTML on their own, the way Claude already does in chat.

Try it on the next ambiguous plan

The pattern is cheap to try in one session. The next time an agent hands you a markdown plan for something you would want to compare, draw, or render, ask for a single-file HTML artifact instead. Open it in a browser. Read the rendered comparison rather than the prose abstraction of it. If the HTML changes your read on the plan, that is what markdown was hiding.

Then screenshot it before the next agent stage reads it back. The screenshot is what makes this the default at every plan stage, instead of a tool you only reach for when the artifact feels important enough to justify the tokens.

References

[1] Thariq Shihipar (Claude Code), The Unreasonable Effectiveness of HTML: https://x.com/trq212/status/2052809885763747935 — The case for HTML over markdown as the default agent output format, with a catalog of use cases.

[2] DeepSeek-AI, DeepSeek-OCR: Contexts Optical Compression. arXiv: https://arxiv.org/abs/2510.18234 — GitHub: https://github.com/deepseek-ai/DeepSeek-OCR — The mechanism behind the screenshot trick: visual tokens encode page-structured content at a fraction of the text-token cost.

Atomic's Ralph Loop: a deterministic, plan, orchestrate review for long-running, ambiguous work

Mixture of Experts — Thu, 07 May 2026 22:52:30 +0000

Geoffrey Huntley's original Ralph essay introduced a primitive I keep coming back to: a coding agent in a while true loop reading the same prompt over and over until the work is done. The pattern is genuinely powerful, and the ecosystem around it has grown a lot since. Huntley's own follow-upgeneralizes it well beyond coding.

The official Claude Code ralph-wiggum plugin ships a Stop-hook variant. Wiggum CLI checkpoints distinct phases with a TUI on top. Vercel's ralph-loop-agent adds completion verification and token-budget stops. Adjacent tools push the same idea from neighboring angles: Aider's architect/editor mode splits planning and editing across two models and posts SOTA numbers on its own benchmark, Cline's Plan & Act keeps a human approving every diff, OpenHands wraps an action-observation loop with critic models and stuck-loop detection, and recent essays on patterns like ASDLC's Ralph Loop sketch out adversarial dual-review approaches that closely match where I ended up. I've learned a lot from all of this, and Atomic's Ralph borrows openly from the lineage.

What I personally wanted — and didn't quite see assembled in one place for my own workflow — was a loop I could leave running unattended on a 30-file refactor overnight where every step is inspectable in the morning: the RFC, the task DAG, the captured diff, both reviewers' transcripts. This post is the design of the Ralph loop that ships in Atomic, what it inherits from the work above, and the small set of choices that make it a little different.

What goes wrong with a naive Ralph

A while true over one prompt has three structural problems, and all three show up around iteration four:

The reviewer is the same brain that wrote the code. It signs off on its own bugs. Self-review converges on confidence, not correctness.
There's no plan that survives the session reset. Each iteration starts cold, constraints drift, later iterations contradict earlier ones.
Symptoms get patched instead of root causes. The reviewer finds five errors in five files. The next iteration fixes five places. The shared underlying defect ships unchanged.

A lot of tools handle a subset of these well. Aider's architect/editor pair separates the planning model from the editing model. Claude Code's plan mode persists a plan that survives /clear and supports iterative re-planning. Cline's Plan & Act keeps a human approving every diff. Devin loops autonomously inside its sandbox. What I wanted on top of these foundations was an unattended loop with two independent reviewers gating termination and a captured artifact for every step — so I could walk away for hours and still reconstruct exactly what happened when I came back.

The shape

Atomic's Ralph is one outer loop with five stages per iteration. Three are visible (you can attach to the tmux session and watch); two are headless because the SDK enforces structured output and there's nothing for a human to steer.

Flow:
spec or RFC path -> Planner (visible) -> Orchestrator (visible, RFC -> DAG -> parallel workers) -> Code Simplifier (visible) -> Infra Discovery (3 headless sub-agents, parallel) -> Dual Reviewer (2 headless, schema-enforced) -> both say "patch is correct"? -> if yes, done. If no, findings grouped by file -> planner triages root causes -> back to Planner.

The loop terminates on one of two conditions: both reviewers return overall_correctness: "patch is correct", or max_loops (default 10) elapses. There is no third "looks fine" branch.

Determinism is wired in, not prompted

The two design decisions that buy the most reliability:

Schema-enforced dual reviewers. Each iteration spawns two reviewers in parallel, each using its provider SDK's structured-output mode (Claude Agent SDK outputFormat: { type: "json_schema" }, OpenCode format: json_schema, Copilot via defineTool). The schema is a Zod object I compile to JSON Schema once:

export const ReviewResultSchema = z.object({
  findings: z.array(ReviewFindingSchema),
  overall_correctness: z.enum(["patch is correct", "patch is incorrect"]),
  overall_explanation: z.string(),
  overall_confidence_score: z.number().min(0).max(1).optional(),
});

The merge rule is conservative: either reviewer flagging "patch is incorrect" fails the iteration, and either reviewer failing to produce schema-valid output is treated as "needs another pass." This sounds obvious. The first version had a bug where a missing structured output defaulted to "correct" and the loop exited after one pass. Nothing was actually verified, but the workflow happily reported success. The fix wasn't in the prompt; it was in the merge function.

A captured branch changeset, injected. Before the reviewers run, the workflow shells out and captures the full diff, name-status, and uncommitted state relative to the parent branch. That string lands in the reviewer prompt verbatim. Reviewers don't need to discover what changed; they read it. Both reviewers on the same iteration see the same input.

These two choices remove most of the iteration-to-iteration variance. Either the reviewer sees the diff and the schema accepts the verdict, or the loop keeps running.

Re-planning, not re-prompting

The interesting part of the loop is what happens between iterations.

When the merged review fails, findings are grouped by file_path and rendered into a markdown brief. Clusters of related symptoms surface together. That brief becomes the only new context the planner gets on the next iteration. The planner is explicitly instructed to:

Validate each finding by reading the cited file (drop stale ones).
Cluster findings that share a module or underlying defect.
Root-cause the actual defect rather than the surface symptom.
Fold the corrected approach into specific RFC sections (Detailed Design, Alternatives, Test Plan).

The output is a revised RFC, not a new prompt. The orchestrator on the next iteration decomposes that RFC into a fresh task DAG. Tasks aren't carried across iterations; the design is.

This is where most DIY Ralphs diverge from this one. They feed reviewer findings back as a comment list, the agent fixes the comments, and the defect ships. Here, the next iteration is forced to revise the design first.

Decomposition is part of the loop, not a one-shot

The orchestrator stage takes the RFC and runs three phases:

Decompose into tasks with a gerund subject, an imperative description, and an explicit blockedBy dependency list. Persisted via the SDK's task tool (TaskCreate, todowrite, etc.).
Dependency-graph integrity check. Every dependency reference must point to a real task ID. Dangling references are dropped before any worker spawns. Otherwise tasks block forever.
Execute. Ready tasks (pending, all deps completed) fan out as parallel sub-agents. As workers finish, newly unblocked tasks dispatch immediately. Worker failures retry up to three times with the error in context, then mark error and unblock the rest of the graph.

A few opinionated rules baked into the prompt: tasks should be small enough that a single sub-agent finishes one in one session, test tasks come after the code they cover, foundations (schema, shared utils) come first. Decomposition is data. Bad decomposition is the leading cause of merge conflicts in long-running runs, and the prompt is where that data quality is enforced.

Three more details that matter

Infra discovery before review. Three sub-agents (codebase-locator, codebase-analyzer, codebase-pattern-finder) run in parallel and surface the exact build, test, lint, and CI commands for the repo. The reviewer is then required to run them before writing findings. Type errors and test failures become P0/P1 findings with the actual command and exit status quoted in the body. The reviewer cannot declare correctness without verifying against the project's own gates.

P3 nits get filtered. The merge step drops priority-3 findings before they reach the planner. If only nits remain, the loop stops. I don't want eight iterations debating a variable name.

A "caveman" response-style directive is appended to every prompt: drop articles, drop pleasantries, technical terms exact, code blocks unchanged, schema literals unchanged. Across ten iterations the token savings are real, and the structured outputs the loop actually depends on are explicitly carved out so they survive intact.

Try it on something hard

atomic workflow -n ralph -a claude ""

It runs against your existing Claude Code, OpenCode, or Copilot CLI install. Atomic wraps a deterministic outer loop around your agent rather than replacing it. The whole workflow is a small set of TypeScript files you can read in one sitting: https://github.com/flora131/atomic/tree/main/packages/atomic-sdk/src/workflows/builtin/ralph. MIT-licensed.

The honest claim is modest: this Ralph fails in ways you can debug. When the loop gets something wrong, I can read the RFC, the task DAG, the captured changeset, and both reviewer transcripts and tell you why. That's the bar I want for any agent loop running for hours unattended on real work.

If you try it and it breaks on something, the issue tracker (https://github.com/flora131/atomic/issues) is open.

Three Things I Learned Using Coding Agents with 1M-Token Models

Mixture of Experts — Thu, 07 May 2026 02:35:21 +0000

Key Takeaways

The effective context window is far smaller than advertised. Even with 1M-token models, performance degrades noticeably past ~100K tokens — worse coherency, more hallucinations, and planning drift. Treat the full window as a capacity limit, not an operating target.
Sub-agents are essential for long-horizon work. Delegating scoped tasks to sub-agents keeps each agent in its "smart zone" and prevents context pollution. Watch for the "impatience problem" where the main agent duplicates work already delegated.
Skills + CLIs beat MCP servers for context control. Skills offer progressive context disclosure and dynamic filtering. MCP servers push opaque context with limited filtering — a critical difference when every token counts.
Context is the scarce resource, not capability. Compaction strategy, sub-agent architecture, and tool selection should all be designed around keeping context lean, scoped, and fresh.

I've been using coding agents heavily — primarily Copilot CLI and the SDK, but also Claude Code and other agentic tools — alongside the 1M-token context models (Codex 5.4 and Opus/Sonnet 4.6). While the examples below are drawn from my Copilot CLI workflow, these patterns apply to any coding agent that operates on long-context models: Claude Code, Cursor, Windsurf, Aider, or whatever you're using. The underlying constraints are model-level, not tool-specific.

My workflow has evolved significantly from where most people start. Most developers see "1M tokens" and think "I can throw everything at the model." The results are predictably bad. Worse coherency. More hallucinations. Plans that drift until they're unrecognizable. The full context window is a capacity limit, not an operating target.

Here are three patterns that fundamentally changed how I work with these tools.

1. The "Smart Zone" Is Much Smaller Than You Think

Even though these models support context windows of up to 1 million tokens, the effective performance zone is significantly smaller — and the reasons are architectural, not incidental.

Why the limitation exists

Most 1M-token models aren't fundamentally larger or smarter than their shorter-context predecessors. They achieve extended context through mathematical techniques like YaRN (Yet another RoPE extensioN — https://arxiv.org/pdf/2309.00071) that stretch the model's sequence length without adding parameters. The context window grows, but the model's core reasoning capacity — what HumanLayer calls the "instruction budget" (https://www.hlyr.dev/blog/long-context-isnt-the-answer) — stays the same.

The instruction budget is the number of instructions a model can reliably follow before adherence starts to drop. It's strongly correlated with the model's parameter count and instruction tuning quality, not with its context window size. When you extend the context 5x without scaling the instruction budget, you can fit more information in, but the model isn't actually better at attending to it. HumanLayer found this firsthand when they tested Claude Opus 4.6 (1M context): instruction adherence degraded not just at capacity limits, but across all context lengths compared to the shorter-context Opus 4.5.

Think of it this way: your context window is a haystack where tool calls, documents, and files are the hay. The quality of the agent's next action depends on its ability to find the right needle — the most relevant instruction for the current state. Expanding the haystack 5x without improving the model's needle-finding ability just buries the signal deeper.

What degradation looks like in practice

Through experimentation across different prompt and context sizes, model performance starts to noticeably degrade past approximately 100K tokens. This shows up as:

Worse task coherency — the model loses track of the overall objective
Reduced reasoning reliability — logical chains break down
Increased hallucination rate — the model confidently fabricates details
Planning drift in long-horizon tasks — multi-step plans veer off course
Instruction disobedience — the model ignores design documents, misunderstands simple instructions, or makes trivial mistakes it wouldn't make in a leaner context

This isn't theoretical. I've watched agents produce clean, well-reasoned output at 80K tokens, then fall apart at 150K with the same task and codebase. The degradation isn't binary — it's a gradient. But the inflection point is consistent enough that I've built my workflow around it. HumanLayer observed the same pattern — they shifted their context warnings to trigger at 100K tokens rather than at a percentage of the usable window.

What works

Trigger auto-compaction earlier. Don't wait until the context window is full. Set compaction thresholds well below the model's maximum capacity.
Periodically clear the context window. Persist progress to disk — research docs, specs, task lists — then start fresh sessions that load only what's needed for the current phase.
Stop max-packing prompts. The fact that the model allows 1M tokens doesn't mean you should use them. Treat the full window as headroom for unexpected context growth, not as the target operating point.

The practical rule: treat the full 1M window as a capacity limit, not an operating target. More context isn't more capability. Design your workflows around staying well under it.

2. Use Sub-Agents to Offload Long-Horizon Work

One of the most effective patterns I've found is spawning sub-agents to balance the main agent's context and handle complex or long-running tasks.

The concept is straightforward: instead of stuffing everything into one agent's context window, delegate scoped work to sub-agents that operate in their own context windows. The orchestrating agent receives condensed results. Its context stays lean. Each sub-agent gets only the information it needs.

This directly addresses the context degradation problem. If you can keep each agent under 100K tokens by distributing work across multiple agents, you stay in the "smart zone" even for tasks that would otherwise require 300K+ tokens of total context.

The Orchestrator Pattern

Below is a template I use for an orchestrator sub-agent (adapted from HumanLayer's work on sub-agent orchestration, with modifications for my workflow):

---
name: orchestrator
description: "Orchestrate sub-agents to accomplish complex long-horizon tasks without losing coherency by delegating to sub-agents."
tools: ["execute", "agent", "edit", "search", "read"]
---

You are a sub-agent orchestrator. The most important tool available to you
is the one that dispatches sub-agents: either `Agent` or `Task`.

All non-trivial operations should be delegated to sub-agents.

Delegate research and codebase understanding tasks to codebase-analyzer,
codebase-locator, and pattern-locator sub-agents.

Delegate running bash commands (particularly ones likely to produce lots
of output) to Bash sub-agents.

Use separate sub-agents for separate tasks, and launch them in parallel —
but do not delegate tasks with significant overlap to separate sub-agents.

The key design decisions:

Separate sub-agents for separate tasks — prevents context pollution between unrelated work
Parallel execution — sub-agents can work simultaneously on independent tasks
No overlapping delegation — avoids duplicate work and conflicting outputs

The Impatience Problem

There's a behavioral quirk worth calling out. The post-training behavior of these models tends to favor smaller-model-style execution patterns. In practice, this means the main agent becomes impatient — it attempts to complete a task that's already been delegated to a sub-agent.

This defeats the purpose of sub-agents entirely. You get:

Context pollution — the main agent duplicates work happening in a sub-agent
Duplicate work — wasted compute and potentially conflicting outputs
Planning drift — the main agent's plan diverges from the sub-agent's execution
Loss of orchestration coherency — the delegation structure breaks down

That's why I explicitly include this instruction in every orchestrator prompt:

"IMPORTANT: Sometimes sub-agents will take a long time. DO NOT attempt to do the job yourself while waiting for the sub-agent to respond. Instead, use the time to plan out your next steps, or ask the user follow-up questions to clarify the task requirements."

This isn't specific to any one tool. It's a model-level behavioral tendency — the post-training optimization makes models want to "do something" rather than wait. I first noticed it in Copilot CLI, but the same pattern shows up in Claude Code, Cursor, and other agentic systems. The explicit instruction overrides that default regardless of which agent you're using.

3. Prefer Skills + CLIs Over MCP Servers

In practice, I consistently favor Skills + CLIs over MCP servers for agent tool integration.

The reason is context control. Skills and CLIs support:

Progressive context disclosure — you control exactly what context enters the prompt window, when, and in what form
Dynamic filtering — you can scope the retrieved context based on the current task

MCP servers, by contrast, often:

Push opaque context — the server decides what to include, and you have limited visibility into what enters your prompt
Provide limited filtering — the architectural design of MCP makes it harder to control the granularity of context injection

This distinction becomes critical once you're operating near the 100K+ token regime. When every token of context matters, you need tight control over what the agent "knows" at any point in time. Skills give you that control. MCP servers often don't.

Skill Registries for Discoverable Capabilities

To ground coding agents with capabilities they can dynamically discover and download, two registries are worth knowing:

The Agent Skills Directory — a curated directory of reusable agent skills: https://skills.sh/
microsoft/skills — Microsoft's open-source skill repository: https://github.com/microsoft/skills

These registries let agents find and adopt capabilities without ballooning the primary context with skill definitions that aren't needed for the current task. The skill gets loaded when it's needed, used, and then the context is reclaimed.

The Pattern

All three tips point to the same underlying principle: context is the scarce resource, not capability.

The models are capable enough. The context window is large enough. But the effective operating zone is much smaller than the theoretical maximum. Everything you do — compaction strategy, sub-agent architecture, tool selection — should be designed around keeping context lean, scoped, and fresh.

Treat context like memory in a constrained system. Allocate carefully. Free aggressively. Never assume that having more headroom means you should use it.

References

HumanLayer, "Long-Context Isn't the Answer": https://www.hlyr.dev/blog/long-context-isnt-the-answer
Peng et al., "YaRN: Efficient Context Window Extension of Large Language Models": https://arxiv.org/pdf/2309.00071
The Agent Skills Directory: https://skills.sh/
Microsoft Skills Repository: https://github.com/microsoft/skills