The experiment had three arms: Claude Code's dynamic workflows, Pallium with its default Codex workers, and Pallium driving Claude models through a provider contract. Same tasks in every arm, outputs judged blind. The result that mattered most was one the test was never designed to find.

It comes at the end of this piece, and everything before it explains why it matters.

Disclosure up front: I built Pallium. What follows is as fair as I can make it, because the two systems answer the same question in different ways, and the differences say something about where agent tooling is heading.

The question both systems answer

When an AI agent needs to coordinate twenty other agents, where should the coordination logic live?

The default answer has been "in the model's context." The model plans, spawns a subagent, reads the result, decides the next step, and holds all of it in chat history. That works for small jobs and degrades as the plan grows.

Loops drift, intermediate results crowd out thinking room, and step fifteen executes against a compacted memory of step two.

Both systems reject that answer the same way: orchestration becomes a JavaScript program. The model writes a script once, a runtime executes it, and subagents do the thinking inside well-defined slots. Loops are `while` loops. Fan-out is a function call. Intermediate state lives in variables instead of chat history.

Two teams, one blueprint

Anthropic shipped dynamic workflows in Claude Code in May 2026. You opt in with the keyword "ultracode" or by asking for a workflow outright. Claude authors the script, the runtime executes it in the background while your session stays responsive, and saved scripts become slash commands.

Pallium is openly modeled on that design: a Go binary executing the same shape of script, async JavaScript with `agent()`, `parallel()`, and `pipeline()`, where each item in a pipeline advances the moment its previous stage completes instead of waiting for the slowest item at a barrier.

The degree of agreement between the two is the first interesting finding, and it required no experiment at all. Both cap concurrency around 16 workers. Both cap a run at 1,000 agents. Both cache completed agent calls so a resumed run replays its unchanged prefix instantly.

random()` inside scripts, because cached resume only works if a replayed script makes the same calls in the same order. Anthropic's public docs describe only part of this surface, so some of the agreement shows up in runtime behavior rather than in any manual.

When two independently maintained runtimes converge on the same numbers and the same prohibitions, the constraints are coming from the problem rather than from taste.

Four choices that split them

1. Where run state lives

Claude Code persists the workflow script, but the run is a feature of the session: the documentation states resume works within the same session only, and exiting mid-run means starting fresh. Pallium writes every run to SQLite.

A run can be paused, resumed days later, inspected, or stopped from the command line, which is also what makes an HTTP API, cron-style triggers, and a fleet view across runs possible. Claude's workflows are something a session does. Pallium's runs are records that a session happened to start.

2. Who the workers are.

Claude's workers are Claude subagents inside Claude Code's permission system, with the session's tool allowlist and the full MCP ecosystem behind them. Pallium defines a worker as a shell command: the default is Codex, and one environment variable wires in any CLI, including Claude itself.

One run can mix vendors, and agents can target other repositories. Claude's design treats the model as the product. Pallium's treats it as a socket.

3. How edits land.

Claude's workflow subagents run in an auto-approved edit mode and write to your working tree directly. Pallium's edit workers run in disposable git worktrees; patches are held until the run finishes clean, scanned for leaked secrets, then applied, with one command to revert. The difference is assumed presence.

Claude's design expects an operator watching the session. Pallium's expects nobody watching, because a trigger may have started the run at three in the morning.

4. What surrounds the runtime.

Claude Code wins on integration: progress UI, permission prompts, plan-level size controls, zero configuration. untilGreen()` loop that owns the check-fix-recheck cycle, and gates that run a verifier agent before the workflow proceeds. Claude's runtime knows more about the conversation.

Pallium's knows more about the repository.

What the test found

On the fix task, parity. Given the same four verified bugs and the same spec, both harnesses fixed all four, both left the full test suite green, and the production diffs were functionally near-identical.

The clear failures were Pallium's. A hung worker stalled one run for over 25 minutes because there was no per-agent timeout, and custom providers could return prose where the script expected structured JSON. Both fixes are in review. Claude's runtime never hung.

Then the result the test was never designed to find. In an adversarial verification stage, agents were asked to refute candidate findings before accepting them. Claude-backed skeptics refuted 4 of 12 with concrete reachability reasoning. Codex-backed skeptics confirmed every one of the 8 claims they were shown.

And when Claude workers ran inside Pallium, the discrimination came back. Judgment quality tracked the worker model. The harness contributed almost nothing to it.

Which one to use

If you work inside Claude Code on a paid plan and the job fits inside a session, use the native tool. It is better integrated, better instrumented, backed by first-party models, and needs no setup.

Pallium occupies the space outside that boundary: runs that outlive a session, triggers instead of prompts, an API instead of a chat window, workers from more than one vendor, and edits that arrive as reviewable, revertible patches. It is MIT-licensed and everything stays on your machine.

Both systems, though, agree on the finding that matters. Scripts should own control flow. Models should own judgment. The harness decides the shape of the work: its cost, its persistence, its safety posture. The model decides whether the work is any good.