The Engineering Boundaries of Multi-Agent Systems: How to Set Rational Investment Criteria

When a public demonstration can dispatch thousands of subtasks from an empty directory and deliver a system prototype that boots on a laptop in roughly eight days, it is easy to interpret “it runs” as evidence that the engineering paradigm has already changed.

At the same time, infrastructure, cloud, and chip-related assets can experience broad sell-offs within only a few trading sessions. Valuation ranges for growth-oriented AI software companies may also be revised downward within weeks. The capability narrative moves upward while capital markets move downward. For enterprises, however, the experience is more concrete: annual AI budgets may double or triple, usage-based bills are clearly visible, yet the number of projects that enter core workflows and reliably replace human labor does not increase proportionally.

These are not simply two contradictory stories. They reveal three curves diverging for the first time at scale:

• The capability curve
• The capital curve
• The delivery curve

This article focuses only on reusable engineering judgments. It does not depend on any particular product launch or financing rumor.

Start by Separating Evidence into Three Tiers

When discussing whether complex software has been “written by agents,” the first step is to assess the strength of the evidence rather than reach a conclusion immediately.

Officially verifiable information usually includes only the model or tool’s access scope, billing method, the starting and ending conditions of the demonstration task, and the capability boundaries explicitly stated by the provider. If a demo shows a kernel, disk, keyboard and mouse, network drivers, persistent storage, windows, a login screen, or an installer, that proves only that a bootable path was completed in a controlled environment.

Third-party testing should disclose the task specification, hardware scope, number of failures, points of human intervention, and reproducible steps. A demonstration that shows only one successful run provides limited information.

Market rumors, valuation ranges, and intraday index movements describe risk appetite and the cost of capital. They are not measurements of engineering capability. Mixing these three evidence tiers leads either to overestimating a demo or using stock prices to dismiss a technology. Both conclusions are misleading.

What Did the Eight-Day Prototype Actually Advance?

Parallel execution of thousands of subtasks replaces “one person writing code sequentially” with a pipeline of planning, delegation, implementation, and verification. For software with deep vertical complexity, such as an operating system, this pipeline can significantly accelerate several categories of work.

The first is scope decomposition. A boot path can be divided into bootstrapping, memory and process foundations, block-device I/O, input devices, a minimal network stack, a mountable file system, a minimal graphical or text interface, and an installation wizard. Each slice can have a relatively clear definition of done, making it suitable for a short-lived subtask.

The second is scaffolding and experimentation. Driver stubs, build scripts, configuration constants, and repetitive error handling can be generated quickly. Basic filters can then be applied using checks such as whether the project compiles and whether the system boots far enough to print a login screen.

The third is regression density. Long-running automated checks can repeatedly reboot virtual machines or simulation environments overnight, exposing “one change breaks everything” failures earlier.

These are real productivity gains, not stage props. They show that the “search for a viable implementation” phase of software engineering is shifting from a search guided by individual experience to a large-scale parallel search.

The Boundaries It Has Not Crossed

Between a bootable prototype and a deliverable system, the missing ingredient is not simply more agents. It is a different set of constraints.

Hardware and Environment Diversity

A single virtual device working on a laptop does not prove correctness across real controllers, firmware variations, power loss, or concurrent interrupts. Demonstrations typically fix the image and device model, effectively reducing the state space to a minimum.

Correctness and Security Boundaries

Kernel permissions, address-space isolation, and system-call parameter validation cannot be accepted because a system appears to reach a login screen. Race conditions, integer overflows, and error-recovery paths require specifications, adversarial testing, and long-duration soak tests—not simply more generated code.

Persistence Semantics

The fact that a file can be saved does not prove crash consistency, power-loss atomicity, or a valid permission model. Prototypes often rely on in-memory storage or simplified logging to pass the demonstration.

Supply Chain and Maintenance

A demonstration rarely answers where dependencies came from, whether their licenses are acceptable, whether builds are reproducible, or who will maintain a driver six months later. The wider the agent fan-out, the more temporary code and conflicting assumptions may be introduced, increasing the cost of later review.

The more accurate conclusion is therefore this: multi-agent systems shorten the calendar time required to reach the first bootable path from zero, but they leave most of the work required to prove that the path holds under production constraints largely intact. The paradigm has moved forward by half a step, stopping before verification.

Why Lower Unit Prices Do Not Necessarily Lower the Total Bill

A common pricing assumption in public discussions is that input and output unit prices may fall by roughly 20%. If the number of calls and the context length per call remain unchanged, the bill should decline. Multi-agent engineering breaks that assumption.

Fan-Out Amplifies Usage

One planning step can generate dozens or thousands of subtasks. Each subtask may carry specifications, interface agreements, and failure logs. Retries and aggregation add further consumption. Token usage therefore grows approximately with the number of attempts and the length of the context, rather than with the number of lines ultimately merged into the repository.

Hidden Human Labor Is Not Included in the Unit Price

Someone still needs to write task specifications, restrict permissions, review diffs, and decide which generated result can be merged. The eight days reported in a demonstration often do not include these on-call and review hours as part of the “model work time.”

The Duration of Price Declines Matters

Whether lower prices remain beneficial depends on two factors:

1. Whether competition continues to reduce the unit price
2. Whether effective output per unit increases

If effective output remains unchanged and the system merely produces more discarded diffs at a lower price, total cost of ownership will still be dominated by retries and review. The short-term beneficiary of a price cut is the customer running the same workload. If that customer immediately uses the savings to increase fan-out, the benefit may be consumed by higher usage. Infrastructure and model providers, meanwhile, may exchange lower unit prices for greater total volume.

This is not a one-sided concession. The billing unit is continuing to shift from “engineering-months” toward “attempts.”

Why Budgets Rise Faster Than Delivery

Many teams have sharply increased their AI budgets over the past year because pilots are easy to approve. Chatbots, coding assistants, and document summarization can demonstrate individual productivity gains within weeks.

Delivery moves more slowly because core workflows require stable task-completion rates, auditable responsibility, and human fallback during failures—not merely an impressive prototype.

The gap usually comes from four misalignments.

Misaligned Objectives

A demo optimizes for “can it boot?” A business process optimizes for “can it continuously handle real tickets without an expert on standby?” These are different metrics, even when they are funded under the same project name.

Misaligned Acceptance Criteria

Without a frozen input distribution, a failure budget, and a defined human-takeover time, it is impossible to determine how much labor has actually been replaced. At the end of the month, teams can see usage but not replacement rates.

Misaligned Architecture

Embedding an agent directly into irreversible operations—such as changing production configuration or sending external communications—creates a large error radius. The faster the fan-out, the larger the potential impact of a mistake.

Misaligned Costs

Usage-based billing makes marginal cost visible, but it can also make “try it one more time” feel inexpensive. Without a per-task cost ceiling, complex tasks naturally expand until the budget is exhausted.

What to Bet on When Capability and Capital Diverge

The capital curve reflects whether growth can cover compute, talent, and sales expenses, as well as how much risk premium the market is willing to pay. It can move sharply within weeks and is therefore unsuitable as the switch for an engineering roadmap.

The capability curve reflects whether search and generation become faster on fixed tasks. It can help determine which types of work deserve a pilot, but it cannot determine which human safeguards may be removed.

Enterprises should invest along the delivery curve. They should use the capability curve to select work slices, and use the capital curve only as a risk note for vendors and budgeting—not as proof of technical capability.

A practical sequence is as follows.

1. Select Reversible, Measurable, Well-Bounded Slices

Examples include generating a driver stub from a specification and compiling it, or adding regression tests to an existing interface. Do not make replacing kernel maintenance or security response the goal of the first phase.

2. Define the Completion Criteria

At minimum, specify:

• Input samples
• The allowed proportion of human edits
• Time limits
• Fallback behavior after failure
• The maximum cost of one successful run

“Reaches the login screen” can remain a smoke-test condition, but it cannot be the only acceptance criterion.

3. Treat Orchestration as a Production Job, Not a Chat

Separate planning, implementation, and checking. A failed check must not automatically expand permissions. Every diff should enter review rather than being merged directly.

4. Set Budgets Per Task, Not by Monthly Intuition

Set separate limits for fan-out width, retry count, and context length. When a limit is exceeded, downgrade the task to human handling. This prevents prototype-style search from consuming the entire budget.

An illustrative acceptance and cost gate could look like this. The thresholds should be calibrated by the business rather than copied from a demonstration:

task: boot_path_smoke
inputs: fixed_image, fixed_device_model
gates:
  - build_ok
  - boot_reaches_login
  - no_secret_in_diff
  - human_edit_ratio <= 0.3
budget:
  max_subtasks: 40
  max_retries_per_task: 2
  max_cost_per_run: team_defined
on_exceed: stop_and_assign_human

5. Use Four Weeks, Not Eight Days, to Make the Decision

A four-week evaluation window is more informative than an eight-day demo:

• Week 1: Measure smoke-test performance and cost
• Week 2: Add abnormal inputs
• Week 3: Track the proportion of human edits
• Week 4: Decide whether to expand the slice, keep the system in an assistive role, or stop

If a prototype can be delivered in eight days, that is precisely why a short demonstration may overstate completion. The decision window must be longer than the demonstration window.

How to Tell Engineering Progress from Launch Theater

Four questions provide a quick filter.

Did the Task Start from a Real Empty Directory?

Were dependencies and toolchains preinstalled? Were failed runs removed from the record? A demonstration that preserves only the successful path is closer to staging than evidence of general capability.

Does Acceptance Include Fault Injection?

A system without power-loss tests, invalid parameters, or concurrency pressure has demonstrated only a happy-path boot.

Was Human Intervention Measured?

If no one reviewed diffs but the result is described as merge-ready, the claim is usually not credible. Conversely, if humans rewrote most of the output, that should not be counted as an AI capability gain.

Is Cost Reported as a Function of Fan-Out?

A successful run without the number of attempts and the associated usage cannot be extrapolated to a team’s bill.

If three of these four answers are negative, treat the result as advertising for a capability ceiling rather than as a delivery case. Even if all four answers are positive, the evidence shows only that the slice deserves a pilot. It does not show that the entire system can be replaced.

Conclusion

Multi-agent systems have turned the first bootable path of complex software into a problem that can be searched in parallel. That is a real engineering improvement.

They have not eliminated specifications, verification, security, or long-term maintenance. Nor does a lower unit price automatically become higher profit. The capital curve can reverse over a weekend, and the capability curve can rise sharply in a single demonstration. Enterprises can control only the delivery curve.

The practical response is to replace rumors with tiered evidence, whole-system replacement with reversible slices, and the “we built a system in eight days” narrative with cost gates and measured human involvement.

The right thing to bet on is not a more impressive demo. It is a narrow task that works on real inputs, stays within a defined budget, and repeatedly passes the required gates.