Multi-Agent Engineering Practices: From Task Decomposition to Acceptance Testing

Long-term engineering is no longer just about asking a model to write a function. When the objective is a bootable system, a manufacturable hardware prototype, or a repeatable physical action, the real difficulty lies in translating vague intentions into verifiable intermediate artifacts while maintaining consistency over days of continuous work. In public demonstrations, some teams have started from an empty directory, using a master agent to orchestrate numerous sub-agents to complete design, coding, testing, and review. Other teams have migrated production services from dynamic languages to system-level languages or built functional electronic devices based on text requirements. These cases serve as samples of capability boundaries rather than guaranteed performance metrics to replicate. Below, this topic is rewritten through the lens of actionable engineering methods.

Define Completion Before Assigning Tasks

An empty directory is strict because there is no historical code to copy; all interfaces, boot paths, and failure modes must be closed internally. Before starting, you should clearly define what “completion” means, rather than just stating “build a system.” This should at least include: the target hardware or virtual machine environment, criteria for successful boot, required drivers and subsystems, explicitly excluded scopes, and how to shut down upon failure.

It is recommended to write acceptance criteria as automatically executable checks rather than prose-style requirements. For example:

• Entering a login or command interface within a limited time after a cold boot;
• Minimum self-tests for storage, input, and network drivers;
• File creation, read, and deletion operations can be replayed;
• An end-to-end script for the interface or installation process;
• Build artifacts can be repeatedly generated in a clean environment.

Without these gates, thousands of parallel tasks will only produce patches that cannot be merged.

Boundaries Between the Master Agent and Sub-Agents

Effective collaboration is not about dividing work equally, but layering it. The master agent is responsible for specifications, dependency ordering, conflict arbitration, and final sign-off. Sub-agents are responsible for narrow tasks: a specific driver, a set of tests, a segment of documentation, or a fault reproduction. Each subtask should carry inputs, outputs, restricted directories, and completion criteria.

In practice, four roles can be adopted:

1. Planning: Break the system down into kernel, storage, input, network, interface, and installer, marking dependencies.
2. Implementation: Commit minimal changes only within authorized directories.
3. Verification: Use independent tests and static checks to refute the implementation, rather than helping it “pass by making excuses.”
4. Review: Check whether interfaces are stable, errors are swallowed, or resources are leaked.

Sub-agents should not expand their scope independently. When discovering a specification gap, they should return the issue rather than secretly altering the architecture. Otherwise, eight days of continuous work will turn into an untraceable explosion of branches.

Long-Term State: Memory, Artifacts, and Replay

The risk of multi-day tasks lies not in single generations, but in context loss. A reliable approach is to store state in repositories and artifacts, not in conversations.

• Place specifications and decision records in version control, clearly stating “why an alternative solution was not adopted”;
• Retain build logs, test reports, and known failures for each integration;
• Tag key milestones to ensure you can revert to the “last bootable” commit;
• The master agent should only read summaries per round: passed items, failed items, and blocked items, avoiding stuffing all code into the context.

An illustrative task ticket can be very brief:

Task: Storage driver minimal read/write
Allowed modifications: drivers/storage/
Prohibited: Changing boot assembly and public header file ABI
Completion: Sector read/write tests pass, returns error code on failure
Rollback: Discard the branch if tests fail

This constraint is more effective than “do your best.” The advantage of agents is parallel trial and error; the advantage of engineering is the ability to revert at any time.

Language Migration: Profile the Bottleneck Before Rewriting

Migrating important services from dynamic languages to system-level languages is often motivated by startup time, memory footprint, and deployment size. The correct sequence is not a full-library rewrite, but establishing a baseline comparison.

First, fix the workload and metrics: cold start latency, peak memory, error rate, and functional equivalence. Use profiling to find the actual hotspots, which are often interpreter startup, serialization, locks, or external calls, rather than the “language itself being slow.” Then replace modules incrementally, keeping external interfaces unchanged, and use the same set of contract tests to prove behavior hasn’t drifted.

During migration, dual implementations should be maintained for a period: the old path as a control, the new path for canary release. Only expand traffic after contract tests, fault injection, and rollback drills pass. Multiplicative improvements in public cases only indicate “there is room under specific services and specific bottlenecks” and cannot be extrapolated to all systems. Claiming speedups without baseline measurements is an unverifiable conclusion.

Hardware Prototypes: Concurrent Closure of Specs, Components, Board-Level, and Structure

Generating electronic devices from text requirements is difficult not because of drawing a schematic, but because electrical, structural, and software aspects must be simultaneously manufacturable. The engineering paths for home voice devices, conference amplification, or handheld interactive toys are similar.

1. Specification: Power, interfaces, acoustic or interactive metrics, dimensions, cost, and safety ratings.
2. Component Selection: Prioritize general-purpose components that are purchasable and have datasheets, and mark alternative parts.
3. Board-Level: Layers, impedance, power integrity, connectors, and test points should be determined before layout.
4. Structure: The enclosure must leave tolerances for connectors, antennas, heat dissipation, and assembly.
5. Firmware: Implement minimal self-tests first, then functional logic.
6. Manufacturing Feedback: Modify specifications based on actual measurements after prototyping, rather than tweaking until it “looks like it works.”

“A runnable first revision without circuit changes” is a strong result, relying on reliable component models, design rules, and test fixtures. In enterprise adoption, you should assume the first revision requires board respins, reserving test points and version numbers. Agents can draft specifications and schematic descriptions, but electrical safety, battery, and RF compliance must be signed off by qualified personnel. Do not send model sketches directly to the factory for mass production.

Robotics: Task Decomposition and Safety Fences

Screwing a bottle cap, solving a Rubik’s cube, or drawing simple graphics may look like demos, but engineering-wise, they are closed loops of perception, planning, control, and exception handling. Progress usually comes from more stable state estimation, clearer skill boundaries, and re-perception after failure, rather than a longer prompt.

Each skill should define preconditions, success criteria, and timeouts. The bottle cap task must limit torque; the drawing task must limit the workspace; when human hands are involved, default to shutdown. Models can propose action sequences, but the execution layer must have independent limits, emergency stops, and collision detection. When the object’s state cannot be confirmed, the correct action is to stop and request human intervention, rather than continuing to attempt.

Research Assistance: Computable Does Not Mean Solved

In fields like theoretical physics, models can help organize assumptions, check derivations, and generate verifiable computational steps. Even if a preprint is formed, it is only material to be tested. Whether mutations still exist at microscopic scales depends on assumptions, numerical methods, and independent recalculation, not on whether the narrative is fluent.

The usage principles are simple: retain original assumptions and calculation scripts; distinguish between “model suggestion” and “proven”; write counterexamples and boundary conditions into documentation; have domain experts review before external release. High-risk research directions should also implement permission tiers, granting stronger tools only to approved institutions and logging their usage. This is access control, not the automatic legalization of conclusions.

Safety Tiers and Enterprise Adoption Checklist

The same underlying capabilities can face different risks. Programming and reasoning for the general public should reject obvious destructive operations by default; capabilities for controlled research should be separately approved, minimally authorized, and fully audited. Safety research can be used for defensive discussions if it stays at the level of mechanism names and impact descriptions; specific attack steps, directly usable exploits, and malicious code should not be part of “agent capability demonstrations.” Life science experiments must also comply with laboratory norms and ethical reviews; models cannot replace approvals.

During implementation, use the following checklist for self-inspection:

• Goals are measurable, and scopes have explicit “not doing” boundaries;
• Subtasks have directory permissions and completion criteria;
• Integration is repeatable, and failures are rollback-able;
• Testing is separated from implementation, and review records are traceable;
• Performance conclusions include baselines, environments, and workloads;
• Hardware and robotics have human sign-offs and physical emergency stops;
• Scientific outputs clearly mark unreviewed sections.

If you use cloud object storage to save artifacts, container platforms to reproduce builds, and logging and monitoring to observe long tasks, these are general capabilities. When selecting tools, focus on permissions, retention periods, and audits, rather than chasing the number of days or parallel scales seen in demos. Agents are suitable for accelerating specifications, drafts, and regressions; responsibility still lies with engineers and researchers who can sign off. Reducing demos to gates, artifacts, and reviews is what makes repeatable systems engineering.