System Capability Vs Model Capability
Most arguments about “agent capability” blur at least two different objects: what the underlying model can do under a fixed interface, and what the assembled software system can do once it has tools, memory, evaluators, runtime control, and human oversight. This entry argues that the distinction between Model Capability and System Capability is one of the most useful conceptual separations in 2025–2026 AI engineering, because agent benchmarks, product demos, and deployment outcomes are usually measurements of the second object, not the first. In practice, there is often a third object as well—Deployment Overhang, or the gap between what a model-system could do and what a real product is allowed to do under permissions, guardrails, and human supervision. (Anthropic)
Coverage note: verified through April 6, 2026.
System Capability vs Model Capability
Why this distinction matters
A large fraction of confusion in AI discourse comes from treating benchmark numbers, model releases, agent demos, and real production outcomes as though they all report the same underlying thing. They do not. Anthropic’s evaluation guidance explicitly frames agent evals as tests for systems that act over many turns, call tools, modify state, and adapt to intermediate results; OpenAI’s agent guidance defines agents in terms of models plus tools plus instructions; and Anthropic’s infrastructure-noise study shows that even resource configuration can move agentic benchmark scores by margins larger than the gaps separating top models on leaderboards. (Anthropic)
This is not semantic housekeeping. It changes how you interpret nearly every important claim. If a team says “Model X scores higher than Model Y on an agent benchmark,” the real question is whether the comparison held constant the Agent Scaffolding, tool affordances, resource budgets, prompt structure, evaluator logic, and approval regime. If those vary, the number is telling you about the assembled stack. Anthropic’s warning is unusually direct: on Terminal-Bench 2.0, the spread between the least- and most-resourced setups in internal experiments was 6 percentage points, and small differences on agentic leaderboards deserve skepticism until the runtime configuration is documented and matched. (Anthropic)
At the same time, the distinction can be overstated if used polemically. Base-model quality still matters enormously. Anthropic’s March 2026 harness note exists precisely because better models changed which scaffold components were still load-bearing; Anthropic’s multi-agent research writeup similarly reports that model choice remains one of the main explanatory variables even when token budget explains most of the variance on a browsing evaluation. The correct view is not “the scaffold matters, not the model.” It is that practical capability is jointly produced, and the relevant unit of analysis depends on what question you are asking. (Anthropic)
A working taxonomy: model capability, system capability, deployed autonomy
The terms in this entry are a working taxonomy rather than a vendor-standard glossary. They synthesize Anthropic’s distinction between augmented LLMs, workflows, and agents; OpenAI’s model-tools-instructions framing; Anthropic’s claim that agent evals must match the complexity of the systems they measure; and METR’s attempt to quantify what a particular agent setup can do on long, well-specified tasks. (Anthropic)
Model Capability is best understood as the competence of a model under a relatively fixed inference regime: prompt format, context budget, sampling configuration, and a minimal or standardized interface. This is never a property of “weights alone,” because every measurement includes some prompt and runtime assumptions. But the aim is to hold the surrounding apparatus as constant and as thin as possible so that differences mostly track the model rather than bespoke orchestration. SWE-bench’s bash-only setup and METR’s time-horizon work are both useful approximations of this mode: they standardize the agent setup to make comparisons more interpretable, even though neither is literally a measurement of naked weights. (SWE-bench)
System Capability is the competence of the assembled model-plus-software stack: model, tools, instructions, context policy, run loop, memory/state, resource budget, evaluators, guardrails, and execution environment. Anthropic’s agent engineering guidance, OpenAI’s practical guide, and the OpenAI Agents SDK docs all point in this direction. Agents are presented not as models in isolation, but as models embedded in runtime behavior with tools, handoffs, guardrails, sessions, and tracing. Anthropic’s evaluation and infrastructure pieces then make explicit what the product docs imply: once you evaluate a tool-using, multi-turn system in an environment, you are evaluating the whole apparatus. (OpenAI)
A third term is indispensable in practice: Deployment Overhang, or the gap between what a model-system could do in principle and what a deployed product actually allows. Anthropic’s autonomy study shows this clearly. Internal Claude Code success on hard tasks rose while human interventions per session fell, but the same study also shows that product defaults, approval workflows, interruption strategies, and clarification pauses strongly shape exercised autonomy. In other words, even “system capability” can overstate what a production system will actually do once the risk model, UX, and supervision policy are turned on. (Anthropic)
| Question | Model Capability | System Capability | Deployment Overhang / exercised autonomy |
|---|---|---|---|
| What is being measured? | A model under a thin or standardized interface | The full assembled stack | The subset of stack capability actually permitted in production |
| Typical evidence | Static benchmarks, thin-harness comparisons, standardized long-task evaluations | Agent benchmarks, product evals, end-to-end task success | Live usage data, intervention rates, approval policies, production monitoring |
| Main levers | Better base model, better inference configuration | Better tools, context curation, runtime design, evaluators, guardrails, resources | Better permissioning, supervision policy, product defaults, escalation paths |
| Main confounder | Prompt and harness choices masquerading as model differences | Runtime, resources, and grader design masquerading as model differences | Organizational risk tolerance masquerading as technical limits |
Table note: this is a synthesis of Anthropic’s agent/workflow framing, OpenAI’s agent primitives, Anthropic’s eval guidance, Anthropic’s production autonomy study, SWE-bench’s bash-only standardization, and METR’s fixed-agent long-task methodology. (Anthropic)
Why agent benchmarks are usually system evaluations
Anthropic’s January 2026 eval guide states the core issue plainly: single-turn evals are comparatively simple, but agents operate across many turns, call tools, update the environment, and adapt based on intermediate results. That means agent evaluation is not just “prompt in, answer out.” It is task, environment, run loop, and grading logic taken together. For coding agents, Anthropic recommends well-specified tasks, stable test environments, and deterministic graders; for research agents, it notes that correctness becomes more contextual and evaluator design becomes harder. This is one reason public quantitative evidence is much cleaner in coding than in more open-ended domains. (Anthropic)
Anthropic’s infrastructure-noise study sharpens this from methodological principle into empirical result. Static benchmarks score a model’s output directly, but agentic coding evals place the model inside a full environment where it writes code, runs tests, installs dependencies, and iterates. In that setting, the runtime is no longer a neutral container. Anthropic held model, harness, and task set fixed on Terminal-Bench 2.0 while varying only resource enforcement and headroom; the observed lift from strict enforcement to uncapped resources reached 6 percentage points, with better headroom both reducing infrastructure failures and enabling solution paths that required more compute or memory. (Anthropic)
That result has a broader interpretive consequence. A reported agent score is not simply a statistic about the base model’s intelligence; it is a statistic about a particular bundle of software and infrastructure choices. Anthropic even argues that leaderboard gaps below roughly 3 points should be treated cautiously unless the configurations are aligned, because sampling uncertainty and infrastructure confounders stack rather than cancel. The lesson is not that agent benchmarks are useless. It is that they must be read as Evaluation Harness results, not as pure model spectroscopy. (Anthropic)
SWE-bench makes the same distinction explicitly inside one benchmark family. Its full leaderboard compares arbitrary systems, but its bash-only view uses mini-SWE-agent in a minimal environment to make language-model comparison more apples-to-apples. The site says this setup uses no extra tools and no special scaffold structure beyond a simple ReAct loop, while the mini-SWE-agent repository describes itself as a baseline system intended to put the language model rather than the scaffold at the center of attention. That is not the same as eliminating the scaffold; it is standardizing it into a very thin shell. (SWE-bench)
METR’s Task-Completion Time Horizon work is similar in spirit. It fixes an agent setup and asks what duration of well-specified task that setup can complete at a given reliability threshold. METR is careful to say that this “time horizon” is not the amount of time a system can act autonomously in the real world; it is a measure of task difficulty for a particular benchmark regime, mostly in software engineering, machine learning, and cybersecurity. That makes it useful for capability trend measurement, but it also reinforces the main point here: even seemingly direct measurements of “what models can do” are operationalized through a concrete agent setup. (Metr)
Where system capability comes from
Tool surface and Agent-Computer Interface
The most obvious source of system capability is the action surface itself. OpenAI defines tools as one of the three core components of an agent; Anthropic’s tool-design writeup goes further and treats a tool as a contract between deterministic systems and non-deterministic agents. That is a useful formulation because it explains why interface design changes measured performance so dramatically. A bad tool contract can make a strong model look clumsy; a good one can make the same model look far more competent by exposing the environment in a form it can actually use. (OpenAI)
The early SWE-agent paper is still one of the clearest demonstrations. Its thesis was not just that language models can solve software tasks, but that a custom Agent-Computer Interface materially improves their ability to edit files, navigate repositories, and execute programs. On SWE-bench, the system reached a then-state-of-the-art 12.5% pass@1, and the paper explicitly attributes a substantial part of the gain to interface design rather than raw non-interactive model performance. In other words, the “capability” was inseparable from the environment shaped for the agent. (arXiv)
By 2025–2026, that lesson had not disappeared; it had become more nuanced. Mini-SWE-agent argues that a lot of the special-purpose interface machinery that looked essential in 2024 was no longer necessary once models improved. But even its deliberately stripped-down design still makes interface choices: bash only, linear history, stateless subprocess execution, simple control flow, easy sandboxing. A thin interface is still an interface. Minimal scaffold is not absence of scaffold; it is the claim that stronger models need a smaller amount of surrounding structure to convert potential into reliable action. (GitHub)
Context Engineering and memory/state
If tool design determines what the system can do, Context Engineering determines what the system can remember, attend to, and prioritize while doing it. Anthropic’s context-engineering essay argues that agent work has moved beyond prompt engineering narrowly construed. The central question becomes what overall configuration of context—system instructions, tools, external data, message history, and state—is most likely to produce the desired behavior over many turns. The key factual premise is that context is finite and degrades in usefulness as it grows, so context handling is not accessory plumbing; it is one of the main capability levers in long-running systems. (Anthropic)
OpenAI’s current stack makes the same point from the runtime side. The Responses API is stateful by default, reducing the need to reconstruct conversation history client-side, and the Agents SDK formalizes session state, handoffs, guardrails, loops, and tracing as first-class primitives. Anthropic’s research system likewise persists the lead agent’s plan to memory because a sufficiently long context would otherwise be truncated. These are not just convenience features. They are ways of preserving competence across time. A model that forgets the plan, loses intermediate state, or reprocesses the wrong payloads is not merely less efficient; it is less capable as a system. (OpenAI Developers)
Anthropic’s November 2025 note on code execution with MCP makes the same point quantitatively. When tool definitions and intermediate results are pushed directly through the model, context usage can explode. Anthropic describes an example where exposing tools through code and loading only what is needed cut token use from roughly 150,000 to 2,000—about a 98.7% reduction—while also enabling state persistence, privacy-preserving data flow, and more efficient control flow in the execution environment. That is a striking reminder that context policy is a capability determinant, not merely an optimization after the fact. (Anthropic)
Runtime, resources, and control policy
Once you move from chat to agents, capability lives partly in the loop. OpenAI’s practical guide says every orchestration approach needs the concept of a run that continues until an exit condition is met; Anthropic’s production descriptions of workflows and agents make the same assumption. The run loop decides when to act, when to observe, when to retry, when to hand off, and when to stop. Different loop designs are not just different programming styles. They create different cognitive envelopes for the same model. (OpenAI)
Anthropic’s multi-agent research system is a strong example of system capability rising through orchestration rather than model replacement. On Anthropic’s internal research eval, a lead Opus 4 agent with Sonnet 4 subagents reportedly beat single-agent Opus 4 by 90.2% for breadth-first research queries. Anthropic’s own analysis then undercuts simplistic “multi-agent magic” narratives by reporting that token usage alone explained 80% of the variance on BrowseComp, with tool-call count and model choice as the other main variables. The useful conclusion is that orchestration can matter a lot, but often because it changes the system’s effective budget and search process rather than because “societies of agents” are intrinsically profound. (Anthropic)
Runtime resources belong in the same category. The infrastructure-noise paper shows that memory headroom and enforcement policy can change what the benchmark is functionally measuring. Below some threshold, extra resources mainly reduce spurious failures; above it, they change which solution strategies are viable. That means “resource budget” is not outside the capability discussion. It is one axis of the system. A model that cannot install a large dependency or survive a transient spike is a weaker coding agent in practice even if its weights are identical. (Anthropic)
Guardrails, tracing, and Human-in-the-Loop Oversight
The final layer is the part many capability discussions omit because it looks like governance instead of intelligence. OpenAI’s documentation treats guardrails and tracing as built-in agent-runtime concepts: input, output, and tool guardrails can block or shape execution, while tracing records generations, tool calls, handoffs, and guardrail events for debugging and monitoring. Anthropic’s product guidance and Claude Code docs similarly emphasize permission models, sandboxing, and command allowlists. These layers do not merely reduce risk. They also determine which trajectories are available and which are observable. A system that cannot be trusted to act without those boundaries will not be granted the autonomy required to realize its latent competence. (OpenAI GitHub Pages)
Anthropic’s autonomy study is especially valuable because it moves this from design principle to usage data. From August to December, Claude Code’s internal success rate on users’ most challenging tasks reportedly doubled while average human interventions per session fell from 5.4 to 3.3. Yet the same study finds that experienced users both auto-approve more often and interrupt more often, suggesting that mature oversight is not “approve every step” but “let the system run, then intervene when needed.” In production, competence is therefore partly negotiated between model, runtime, and human operator. That negotiation belongs inside the notion of system capability. (Anthropic)
A practical rule: system capability is what matters for deployment, model capability is what matters for attribution
This distinction becomes operational once you ask two different questions. If the question is what should we ship?, system capability dominates, because users and businesses experience the assembled stack rather than the isolated model. If the question is where did the improvement come from?, model capability matters more, because you need to know whether the lift came from better weights, better tools, more tokens, a different resource budget, or a new evaluator loop. Anthropic’s own documents quietly enforce this separation: the practical guides are about building stacks, while the eval and benchmarking documents spend far more time warning you about confounds and grading design. (Anthropic)
A useful engineering summary is this: judge products by system capability, judge scientific progress by carefully normalized model capability, and judge real-world risk by deployed autonomy. Collapsing these into one number is what produces both inflated claims and false skepticism. (Anthropic)
| Symptom | Mostly model-limited | Mostly system-limited | Mixed / ambiguous |
|---|---|---|---|
| Fails short, well-specified tasks under fixed interface | Usually yes | Rarely | Sometimes |
| Improves dramatically with better tool docs or ACI | Rarely | Usually | Sometimes |
| Improves dramatically with more context curation or state management | Sometimes | Usually | Often |
| Improves with more CPU/RAM/time budget despite same model | No | Yes | Often |
| Improves with better human approval and interruption strategy | No | Yes | Often |
| Collapses when scaffold is pruned after model upgrade | No | Yes | Often |
Table note: the classification is a practical synthesis of Anthropic’s ACI/tool guidance, context engineering guidance, infrastructure-noise results, autonomy study, and harness-pruning writeup. (Anthropic)
The pruning dynamic: when model gains eat the scaffold
One reason the distinction matters is that system capability is not static with respect to model quality. Anthropic’s March 2026 harness writeup gives a rare public look at this dynamic. A complex long-running harness built for Opus 4.5 used sprint decomposition, context management tricks, and an evaluator layer to keep lengthy software projects coherent. When Opus 4.6 arrived, Anthropic did not simply drop the new model into the old harness unchanged. It systematically removed components to test which ones were still load-bearing. Sprint decomposition disappeared; evaluator use became more selective; and the remaining structure was justified only where the task still sat beyond the model’s reliable solo boundary. (Anthropic)
This is the most important corrective to the stronger versions of the scaffolding thesis. The scaffold can be a major source of deployed capability, but model progress can turn yesterday’s clever orchestration into today’s overhead. Anthropic says this explicitly in effect, and OpenAI’s guidance points the same way by recommending that developers maximize a single agent’s capabilities before introducing multiple agents, and evolve toward greater orchestration complexity only when needed. The burden of proof falls on the extra layer. (OpenAI)
Mini-SWE-agent is the public benchmark-world version of the same story. Its authors contrast their 2024 emphasis on tools and special interfaces with their 2025–2026 judgment that a lot of that is no longer needed for a useful agent. The repository is explicit that the point is to keep the language model rather than the scaffold at the center of attention. But the honest lesson is not “the scaffold was a mistake.” It is that scaffold thickness is model-relative, and good engineering involves both addition and deletion. (GitHub)
This is why Pruning Principle is the right companion concept to the model-versus-system distinction. Every scaffold layer should periodically re-justify itself against the current model frontier. A layer that once converted weakness into competence can later become latency, token tax, and maintenance burden. (Anthropic)
How to measure the difference in practice
If you actually want to separate model capability from system capability rather than argue about it impressionistically, the method is straightforward: run ablations that vary one layer while holding the others fixed. Anthropic’s infrastructure paper is exemplary here because it holds model, harness, and task set constant while varying only runtime resources. Anthropic’s harness-pruning article does the complementary thing by holding the task family constant while removing scaffold components one by one around a stronger model. OpenAI’s own guidance also points toward this discipline by recommending strong baselines, incremental orchestration, and evals before optimization. (Anthropic)
In practice, four experiments answer most of the important questions:
| Goal | Hold fixed | Vary | What you learn |
|---|---|---|---|
| Estimate thin-system model capability | Standardized minimal harness, task set, budget | Model | Relative model strength under low orchestration |
| Estimate scaffold lift | Model, task set, grader, resource budget | Tools, context policy, planner/evaluator layers, memory | Which software layers are actually load-bearing |
| Estimate infrastructure sensitivity | Model, harness, task set | CPU/RAM/time limits, sandbox enforcement, network policy | Whether benchmark gains are capability or environment artifacts |
| Estimate deployed autonomy | Model, harness, task family | Approval mode, human-in-the-loop policy, guardrails | How much capability survives real supervision and governance |
Table note: this protocol is distilled from Anthropic’s eval methodology, infrastructure-noise experiments, autonomy study, and OpenAI’s baseline-first guidance. (Anthropic)
Reporting discipline matters almost as much as experimental design. For any serious claim, publish the model, prompt or instruction regime, toolset, context policy, resource limits, retry policy, stopping conditions, grader logic, and whether human interventions were allowed. Anthropic’s eval guide emphasizes that agent evals combine task design and graders, and its infrastructure note shows why resource methodology must be documented alongside the score. An uncited agent number is often less informative than a well-described lower number. (Anthropic)
There is also a subtle but important measurement choice around what counts as “model capability.” SWE-bench’s bash-only leaderboard is a good convention because it makes comparisons tractable, but it should still be described as thin-system capability rather than pure model essence. The bash shell, subprocess isolation, linear history, and evaluation harness are all part of the measured object. That does not invalidate the comparison; it makes its scope explicit. (SWE-bench)
Self-improving systems treat the scaffold as part of the capability object
The self-improving-systems literature makes the philosophical point concrete: if an agent can improve itself by editing its own code, then the scaffold is not just packaging around capability. It is part of the capability object being optimized. A Self-Improving Coding Agent defines agent systems as code that orchestrates LLM calls and tools, then shows that such a system can autonomously edit itself and improve from 17% to 53% on a random subset of SWE-bench Verified. That is only intelligible if system-level software is doing real epistemic and operational work. (arXiv)
The Darwin Gödel Machine pushes the point further by explicitly improving capabilities through changes such as better code-editing tools, long-context handling, and peer-review mechanisms, with reported SWE-bench gains from 20.0% to 50.0%. The paper is not saying that model choice ceased to matter; it is saying that once you have a capable foundation model, a meaningful fraction of additional performance comes from searching over the surrounding architecture. That is a direct argument for Mutable Scaffolds as a first-class object of study. (arXiv)
Live-SWE-agent makes the same claim at runtime rather than offline. It starts from a bash-only scaffold akin to mini-SWE-agent, then evolves its own scaffold on the fly while solving real problems. The latest arXiv version reports 77.4% on SWE-bench Verified and 45.8% on SWE-Bench Pro, while explicitly motivating the work by the difficulty of exhaustively hand-designing the scaffold space. Whether every reported number survives future scrutiny is secondary to the architectural lesson: the mutable software layer itself has become a search space. (arXiv)
AgentBreeder adds an important caution. It frames scaffold search as a multi-objective problem over capability and safety, reports strong gains in one “blue-team” mode, and also finds that adversarially weak scaffolds can emerge when optimizing capability in the wrong way. That matters for this entry because it shows that system capability is not just capability. It is capability plus risk profile, and both can move when the scaffold changes even if the base model does not. (OpenReview)
Counterarguments and unresolved questions
“Isn’t this just hidden test-time compute?”
Partly, yes. Anthropic’s research-system writeup is unusually candid that multi-agent systems often work because they spend enough tokens to solve the problem. On BrowseComp, token usage explained most of the variance; model choice and tool calls explained additional variance. So some claims about “architecture” are really claims about how much search, branching, or parallel context the system is buying at inference time. That does not make the distinction unimportant, but it does mean that “system capability” sometimes cashes out as budgeted computation rather than subtle software genius. (Anthropic)
“Are we over-generalizing from coding agents?”
Probably, if the claim is universal. Public quantitative evidence is still strongest in coding and adjacent research tasks because those domains have stable environments, deterministic graders, and repeatable success criteria. Anthropic’s eval guide explicitly distinguishes coding agents from research and conversational agents for this reason. The model-versus-system distinction is likely general, but the cleanest proof remains clustered in software engineering. Outside those domains, the evidence is more qualitative and the graders are softer. (Anthropic)
“Does system capability make model progress less important?”
No. Anthropic’s harness note is almost a case study in the opposite. Model improvements can erase the need for elaborate decomposition or criticism loops, and Anthropic’s research-system paper reports that upgrading the base model could outperform simply doubling token budget in some regimes. The better view is that model progress and scaffold design are complements with changing exchange rates. Sometimes the fastest way to raise system capability is a better model; sometimes it is a better tool contract or runtime; often it is both. (Anthropic)
“Is the permanent unit the system, then?”
For deployment, mostly yes. For scientific attribution, not entirely. Some system layers are likely durable—tool integration, state persistence, tracing, permissions, and guardrails—because they externalize properties no language model can own by itself. Other layers look transient and increasingly pruneable: brittle prompt societies, decompositions added only to compensate for weak long-horizon coherence, or evaluators that strong models no longer need on routine tasks. The likely long-run picture is not the disappearance of scaffolding, but the thinning of its cognitive choreography and the survival of its infrastructural and governance roles. (OpenAI Developers)
“What is the deepest unresolved issue?”
The deepest open question is whether future AI engineering will stabilize around a relatively fixed systems layer or keep treating the scaffold itself as an object of continual search and self-modification. The self-improvement papers lean toward the latter. Vendor production guidance leans toward a more conservative middle: start simple, iterate hard, and delete unnecessary machinery. Both could be right. Operationally, teams may converge on a stable substrate of tools, state, evaluation, and governance while continuing to evolve higher-level scaffold behavior automatically. That would make “system capability” the enduring deployment unit even as its internal composition remains fluid. (Anthropic)
Selected primary sources
Anthropic Engineering — Demystifying evals for AI agents. The clearest public explanation of why agent evaluation is system evaluation: multi-turn behavior, tool use, state changes, graders, and deployment-facing failure analysis. (Anthropic)
Anthropic Engineering — Quantifying infrastructure noise in agentic coding evals. Best primary source showing that runtime and resource methodology can change leaderboard outcomes by margins larger than the apparent model gap. (Anthropic)
OpenAI — A practical guide to building agents and Building agents. Best concise statement of the modern agent unit as model + tools + instructions, plus the current single-agent-first, eval-first, loop-based design center. (OpenAI)
Anthropic Engineering — Building effective agents, Writing effective tools for agents, Effective context engineering for AI agents, and Code execution with MCP. Best cluster of primary sources on the software levers that turn base models into useful systems: tool ergonomics, context curation, state, and efficient environment interaction. (Anthropic)
SWE-bench, mini-SWE-agent, and SWE-agent. Best public before-and-after case study for the distinction between rich scaffolds, thin standardized scaffolds, and what each benchmark setup is actually measuring. (SWE-bench)
METR — Measuring AI Ability to Complete Long Tasks / time-horizon pages. Best independent attempt to measure standardized agent competence on longer tasks while being explicit that the setup still defines the measured object. (Metr)
Self-improving agent literature — A Self-Improving Coding Agent, Darwin Gödel Machine, Live-SWE-agent, AgentBreeder. Strongest evidence that the scaffold itself is a mutable substrate for optimization, not just a static wrapper around the model. (arXiv)
Companion entries
Core theory: Agent Scaffolding, Model Capability, Deployment Overhang, Mutable Scaffolds, Pruning Principle
Measurement: Evaluation Harness, Agent Benchmark Methodology, Task-Completion Time Horizon, SWE-bench, Terminal-Bench
Practice: Context Engineering, Tool Design for Agents, Agent-Computer Interface, Human-in-the-Loop Oversight, Single-Agent vs Multi-Agent
Counterarguments: Hidden Test-Time Compute, Minimal Scaffolds, The Case Against Agent Frameworks, Why Stronger Models Delete Architecture