Building an OS from Scratch: Multi-Agent Collaboration in Complex Engineering

In recent years, competition in AI applications has moved from whether a model can generate code to whether it can independently complete complex engineering work. Public information indicates that a research organization recently released two next-generation models: one for general users and another for high-risk professional institutions. They share similar underlying capabilities but differ in access, risk controls, and intended settings. The general version emphasizes everyday tasks and safety; the professional version is aimed at reviewed environments such as cybersecurity and life sciences.

What matters more than a model name or a single Q&A result is performance on multi-step, long-running, heavily verified tasks. Related tests report that a model can coordinate large numbers of sub-agents and, in a relatively short time, complete electronic-device designs, operating-system prototypes, and formal mathematical proofs. The role of the model is changing: it is no longer only a coding assistant, but potentially an engineering hub that decomposes goals, assigns work, calls tools, aggregates results, and keeps correcting errors.

From code generation to engineering execution

Traditional code generation usually has clear task boundaries, relatively explicit inputs and outputs, and low verification cost. Generating a data-processing function from an interface description is a typical example: understand the requirement and emit code.

Operating systems, compilers, and hardware-control programs do not share those traits. They involve dependencies across modules and require repeated compile, boot, test, and fix cycles. A seemingly simple feature can affect process management, memory allocation, device drivers, the file system, and the user-interaction layer at once.

Complex engineering automation therefore needs at least:

1. Task decomposition: break a high-level goal into independently executable subtasks.
2. Context management: retain project structure, design decisions, interface constraints, and error history.
3. Tool use: compilers, test environments, simulators, debuggers, and version control.
4. Result verification: not only whether code was generated, but whether it builds, runs, and can be reproduced.
5. Failure recovery: when a subtask fails, roll back, retry, or redesign.

The core is no longer a one-shot answer, but a closed loop of plan–execute–verify–correct.

How multi-agent systems can build an OS prototype

According to disclosed pre-release tests, a system coordinated more than a thousand sub-agents and, over several days, built from scratch an OS prototype that could boot on a laptop. “From scratch” does not mean zero dependence on any base software. It means the system still had to design and implement boot flow, kernel structure, device abstraction, storage access, and user interaction as a whole.

A typical collaboration stack has five layers.

1. Overall planning

A planner first sets goals: processor architecture, boot method, whether a basic command interpreter is required, and the minimum feature set.

This layer is about constraints, not code. Clearer constraints mean fewer later conflicts. Memory management must specify page size, address-space layout, and allocation interfaces; the file system must know block-device access and caching policy.

2. Module design

Work can be split into boot, kernel, drivers, file system, user-space programs, and tests. Relatively independent agents own modules, while interface-review agents check consistency.

In real engineering, module interfaces matter more than individual functions. If agents assume different data structures, error codes, or calling conventions, each module can look correct and still fail after integration.

3. Execution and build

After code generation, the system should compile, link, produce images, and run boot tests automatically. Any failure should return error logs, related files, recent changes, and environment details to a repair agent.

Unlike ordinary chat, an engineering system must classify errors. Compile errors often involve syntax, types, or header dependencies; link errors may involve missing symbols and address layout; boot failures may involve the boot path, hardware init, or memory maps; runtime crashes may involve concurrency, out-of-bounds access, or resource cleanup. Classification makes a correct repair strategy more likely.

4. Integration and regression

Each completed module needs automated tests. Tests should not only check that the system boots. They should cover invalid input, resource exhaustion, repeated boots, concurrent access, and fault recovery.

For an OS prototype, regression tests can include:

• whether the system can enter user mode after boot;
• whether memory allocate/free is stable;
• whether file create/read/write matches expectations;
• whether concurrent tasks deadlock;
• whether unavailable devices return clear errors;
• whether a crash preserves needed diagnostics.

5. Project memory

Large multi-agent work often loses context. Agents that see only local information may duplicate work, overwrite each other, or undo already verified designs.

The system therefore needs structured project memory:

• current directories and module dependencies;
• confirmed interfaces and design decisions;
• known defects and reproduction steps;
• test results and failure causes;
• impact of each change;
• constraints that must not be broken.

This memory is better stored in machine-readable form than as natural-language summaries alone.

Hardware design as a cross-domain test

Related tests also covered electronic devices such as a voice-interaction hub, conference audio hardware, and a handheld virtual pet. The difficulty is that these tasks mix requirements analysis, component selection, mechanical structure, firmware, protocols, and user experience.

A model that only emits software code cannot finish a complete design. It must turn natural-language needs into executable specifications, for example:

• what signals input devices must capture;
• which interfaces the control chip must provide;
• how power delivery meets peak load;
• how the device enters a safe state on faults;
• how firmware is upgraded and rolled back;
• how user data is stored and erased locally.

This suggests future intelligent engineering stacks may combine software agents, simulation environments, and hardware knowledge bases. Models first validate circuits, control logic, and communication in a virtual setting; engineers then test physical hardware, reducing trial-and-error cost.

Formal proofs as a generate-and-check loop

Mathematical proof is a strong reliability test. Informal “proof ideas” are not machine-checkable proofs. Formal proofs must obey strict logic and pass a proof checker step by step.

Related tests report that about a thousand agents completed a formal proof of a major theorem in tens of hours, faster than previously published records. The point is not that a single model suddenly knew all of mathematics. The system split a complex proof into many related lemmas and let agents search and verify in parallel.

The process typically includes:

1. translating a natural-language theorem into formal definitions;
2. analyzing existing theorems and reusable proof paths;
3. splitting the main goal into intermediate propositions;
4. trying different proof strategies in parallel;
5. checking each step with a formal checker;
6. merging viable paths and removing duplicate work.

The same pattern applies to software: models propose candidates; deterministic tools accept or reject them, reducing the risk of code that looks right but does not run.

Value and limits in scientific research

In science, models have been used on problems such as black-hole physics, holographic theory, and viral-capsid structure prediction. Value appears in three ways.

First, models can quickly organize papers, formulas, and experimental results and help researchers spot links across fields. Second, they can generate multiple hypotheses and use simulation or computation to rank what is worth testing. Third, in structure prediction and molecular design, they can shrink the combinatorial search space.

Scientific work cannot stop at prediction volume or surface accuracy. Credibility also depends on training-data bias, whether test samples are representative, whether results can be reproduced, and whether predictions match known physical laws.

Model output should be treated as a research hypothesis, not a final conclusion. In drugs, gene therapy, materials, and high-energy physics, experimental validation, peer review, and strict data governance remain necessary.

Safety must scale with capability

Stronger capability brings more complex risk. Public information says the new models performed no worse than previous generations on some alignment tests and reduced certain sandbox-escape attempts, while developers also acknowledge that current evaluations cannot fully predict real-world risk.

For a general-user version, typical controls include:

• blocking high-risk penetration-testing and exploit content;
• limiting biological research that could cause real-world harm;
• isolating permissions for tool calls;
• forbidding the model from expanding file, network, or system privileges on its own;
• auditing sensitive outputs and grading risk.

For professional institutions, access review, usage logs, identity verification, and result tracing should be stricter. In high-risk research, human approval, dual review, and emergency shutdown are required.

Anti-distillation is another area of interest: limiting high-value outputs, detecting abnormal call patterns, and controlling bulk queries to make systematic capability copying harder. These measures cannot solve safety alone. Weight protection, access control, data sanitization, and internal audit remain essential.

Enterprise adoption needs a verifiable engineering process

Enterprises should not treat a multi-agent development system as an “automatic programmer.” Start with low-risk, reversible work.

A practical path:

1. Assistive work first: code search, test generation, documentation, and log analysis.
2. Then closed tasks: independent modules in isolated environments.
3. Automated acceptance: every model submission must compile, pass tests, and pass security scans.
4. Least privilege: read-only by default; write, network, or deploy only after authorization.
5. Human decision points: architecture changes, production releases, and high-risk operations require confirmation.
6. Full process records: prompts, tool calls, diffs, test results, and rollbacks.
7. Ongoing real-risk evaluation: not only public benchmarks, but red-team tests against the company’s own data and workflows.

Conclusion

From thousands of sub-agents collaborating on an operating system to exploring hard problems in mathematics and science, next-generation models show more than text generation. They show planning, execution, verification, and collaboration over long tasks.

That does not mean software engineers are simply replaced. Their focus shifts toward goal definition, architecture, constraints, risk control, and acceptance. A reliable intelligent engineering system must combine model creativity with compilers, test frameworks, simulation, and human review.

The right measures of value are not only answer speed or lines of code, but task completion rate, reproducibility, failure recovery, safety boundaries, and long-term maintenance cost. Only with a complete engineering loop can AI move from demo tools to controllable, usable, auditable production systems.