Original URL: https://getagenttools.com/blog/muse-code-agent-harness/ # Agent harness design: what Meta put in Muse Code, and what I already run 6 Aug 2026Marek. - agent-harness - coding-agents - context-engineering Agent harness design is the part of this launch worth reading twice. On 5 August 2026 Meta released Muse Code, a terminal coding agent in beta, and Muse Spark 1.2, the model behind it. I have not run it. I have run agents in production long enough to know that the interesting choices in an announcement like this are almost never in the model, and this one is no exception. - **What it is.** Muse Code is a terminal coding agent in beta, powered by Muse Spark 1.2, installed with one curl line on macOS or Linux. - **The runtime.** Every model call, tool run, approval and edit is appended to a local event log, which makes a run replayable and a crash survivable. - **The subagents.** Background agents stay alive for a whole session instead of being spawned per task, so they stop gathering the same information twice. - **The skills.** `/plan` turns a task into an approval-gated plan, `/grill` stress-tests that plan, `/goal` drives to completion. The approval step ships in the box. - **The verdict: WATCHING.** Three design ideas I can use this week, and a tool I have no right to judge yet. The harness I do run every day is written up here: [the Claude Code review](https://getagenttools.com/tools/claude-code/). ## What is an agent harness? An [agent harness](https://getagenttools.com/blog/what-is-an-agent-harness/) is the software around the model: the loop that decides what happens next, the tools the agent may call, the approvals it has to ask for, and the record of what it did. The model writes the code. The harness decides whether that code ever runs, and what happens when the run falls over. That split matters because you can swap the model. You cannot easily swap the harness, because the harness is where your rules live. Which directories are off limits. Which actions need a human. What gets logged. How a half-finished job is picked back up. So when a lab ships a new coding agent, I read the harness section first and the benchmark charts last. Benchmarks tell me how a model does on someone else's tasks. The harness tells me what the thing will do to my repository on a bad day. ## What Meta actually shipped in Muse Code Two things, on 5 August 2026, in the same [announcement](https://research.meta.ai/blog/introducing-muse-code-and-muse-spark-1-2): Muse Code, a terminal coding agent in beta, and Muse Spark 1.2, a coding-focused update to Muse Spark 1.1. Meta describes Muse Code as taking on software engineering tasks across large repositories: planning changes, writing code, validating the results. It installs on macOS or Linux with a single command. ```bash curl -fsSL https://dev.meta.ai/install.sh | bash ``` Muse Spark 1.2 was co-trained with the harness rather than dropped into it. Meta says the training included harness trajectories and tuning for goals, compaction and subagents, so the model and the tool were shaped against each other. That is a real trend and worth naming: the model and the harness are becoming one product, not two. Three skills ship by default. `/plan` turns a task into an approval-gated plan. `/grill` stress-tests that plan until it holds up. `/goal` works toward completing the objective. A plan I approve, then a second pass whose job is to argue with that plan, is exactly the shape I use for anything that touches production. Seeing it as a default rather than a convention I have to enforce myself is the most quietly useful thing in the post. ## Background agents that outlive the task Meta pairs a simple agent loop with async background agents. The detail that matters is one sentence: those agents stay active throughout each session instead of being spawned for individual tasks. They carry out next steps and pick when to report back to the main agent. Meta's stated reason is avoiding redundant information gathering, with lower latency and less steering on long, multi-step work. Anyone who has run subagents at scale knows the problem being solved. Spawn a fresh worker per task and it starts from nothing: same repository walk, same config files, same three searches you already paid for twice. The cost is real and so is the wall-clock time. Persistence trades that for a different problem, which is that a long-lived agent accumulates context and context has a shelf life. I have no data on where Meta's version lands on that trade. Nobody outside Meta does yet. What I take from it is the framing: the question is not "how many subagents" but "what does a subagent get to keep between tasks". ## The append-only event log is the part I would copy first Muse Code writes every model call, tool run, approval and edit into a local event log, and treats that log as the single source of truth. Meta's claim is that this makes the runtime replay-exact and restart-safe: after a crash the agent resumes precisely where it stopped, which is what lets it attempt long-running work at all. A main agent and persistent background agents both appending every model call, tool run, approval and edit to one log Both the main loop and the background agents write to the same append-only log. Because every model call, tool run, approval and edit is recorded in order, a crash does not cost the run: the agent replays the log and picks up at the last entry instead of starting the task again. This is the idea I would steal even if I never install the tool. Long agent runs die. They die on a network blip, on a rate limit, on a laptop that goes to sleep, on a tool that hangs. Without a log, the honest recovery is to start the task again and hope the second run makes the same decisions. With a log, recovery is a replay and the work already done stays done. There is a second benefit Meta does not dwell on. An ordered record of every call, approval and edit is also an audit trail. When an agent is allowed near anything that spends money, "what exactly did it do, in what order, and who approved it" stops being a nice-to-have. That is the same reason every campaign my automation creates through the [Meta Ads API](https://getagenttools.com/tools/meta-ads-api/) is created paused, with a person activating the spend. The log and the approval gate are two halves of one guardrail. ## Is Claude Code an agent harness? Yes. A terminal agent that plans, edits files, runs commands, asks for permission and keeps going until the work checks out is a harness by any useful definition, and the model inside it is a component you can change. The same is true of Muse Code. The category is now crowded enough that the harness, not the model, is what you are choosing. Which means the comparison questions are changing. Not "which model scores higher" but: what does it record, what does it do after a crash, what can it reach, what does it refuse to do without me. Reach is its own dimension: connect an agent to your files, analytics, hosting and email through [MCP servers](https://getagenttools.com/tools/mcp-servers/) and the harness stops being a coding tool and becomes an operations tool. That is also why "just try the new one" is not free advice. Moving harness means moving your rules, your approvals and your muscle memory. The switching cost is the rules, not the install. DeepSeek has since open sourced [its own harness](https://getagenttools.com/blog/deepseek-harness/) under MIT, which takes the event log a step further and makes it an architectural rule instead of a feature. ## What the benchmarks do not tell you about an AI coding agent Meta names three evaluations for Muse Spark 1.2: Terminal-Bench 2.1, DeepSWE 1.1 and an internal coding benchmark. The scores sit in charts and a separate report rather than in the text of the announcement, so I am not going to quote numbers I have not read in context. Treat that as normal. Launch-day benchmark claims are the least portable part of any release. The number in the post that actually told me something is from the kernel case study: over 1,000 tool calls, up to 24 hours, with the agent writing, compiling, profiling and improving GPU kernels against a provided baseline. That is not a model score. That is a statement about the harness surviving a run long enough for the model to iterate, which is the same claim as the event log, measured a different way. For my own work the useful test was never a benchmark anyway. It is whether the agent's output passes verification I control. Browser work gets checked by [Playwright](https://getagenttools.com/tools/playwright/), not by the agent's summary of what it did. An agent that scores well and cannot prove its own output is still homework for me. ## Why the verdict is WATCHING and not TESTED Because I have not run it, and on this site that word means something specific. TESTED means it did a real job end to end at least once. WATCHING means it looks worth the time and has not carried real work yet. The rules are in [the field notes post](https://getagenttools.com/blog/field-notes/), and I would rather have a boring verdict than a fast one. There are practical reasons too. The install line covers macOS and Linux, and my daily driver is Windows, so the honest first step is a Linux box rather than a five-minute try. The announcement also says nothing about pricing, rate limits or context window, and those three numbers decide whether a tool survives contact with a real workload. So the plan is the usual one. Give it a job I already know the shape of, break it on purpose, watch what the log does when it breaks. If it holds up, it gets a verdict and a page. If it does not, it gets a paragraph explaining why, and the list stays short. Put this into practice [See the tool list](https://getagenttools.com/tools/)[Train your team](https://getagenttools.com/#training)