AMOS and the 90% Operating Model

Why the next step in enterprise AI may be eliminating most manual system work—not by adding more automation scripts, but by redesigning the operating architecture around law, generation, verification and self-repair

Executive perspective

The software industry is entering a paradoxical phase. Artificial intelligence can now generate code, tests, documentation, infrastructure definitions and increasingly complete applications at speeds that would have been implausible only a few years ago, yet many engineering organizations remain burdened by the same operational friction that existed before generative AI: fragmented repositories, inconsistent environments, repetitive configuration, manual integration, dependency failures, log inspection, release coordination, duplicated tooling and a growing requirement to verify machine-generated work. McKinsey has estimated that generative AI could create productivity value equivalent to 20–45 percent of current software-engineering spending, while earlier controlled research cited by the firm found developers using GitHub Copilot completing a programming task approximately 56 percent faster. More recent evidence, however, shows why code generation alone is not the end state. Google's 2025 DORA research found AI use had become nearly universal among surveyed technology professionals and that more than 80 percent believed it improved their productivity, while simultaneously observing that AI acts primarily as an amplifier of the organizational system into which it is introduced. DORA's broader research has also documented situations in which faster code creation shifts effort downstream into review, verification and integration rather than eliminating the work altogether. The emerging economic question is therefore no longer simply how much faster developers can write code. It is how much of the total operating burden surrounding software can be removed from human attention altogether. (McKinsey & Company)

This is the problem addressed by what Trang Phan describes as the Omega approach within AMOS, the Absolute Operating System. AMOS is built around a broader Law-First Deterministic Organism Architecture, or LDOA, in which software is treated not primarily as a collection of manually maintained files and isolated scripts but as an operating system generated and governed from a smaller set of canonical definitions, constraints, specifications and observable states. The business ambition of the Omega model is aggressive: remove approximately 90–95 percent of routine manual system work by shifting responsibilities such as environment preparation, structure generation, validation, integration, health checking, repair, auditing and regeneration from the human operator into the operating architecture itself. That figure should be understood as a design target for the proportion of repetitive operational work the architecture seeks to absorb, rather than as a general benchmark already demonstrated across external enterprise environments. The strategic idea behind it is more important than the percentage: the largest productivity gain may not come from helping people perform every technical task faster; it may come from eliminating entire categories of technical work that people should no longer need to perform manually.

The distinction is substantial. Most current AI development tools operate inside the existing software-development model. A developer still has repositories, build systems, environments, package managers, scripts, CI pipelines, deployment controls and operational dashboards; AI simply helps the developer write or interpret the artifacts inside those systems. The Omega approach asks whether the operating model itself can be compressed. Instead of teaching a human which commands to execute, the system owns the sequence. Instead of expecting the operator to remember which environment is active, the runtime validates and establishes its own environment. Instead of manually moving source material between directories and resolving naming inconsistencies, the architecture accepts controlled inputs, validates them, places them according to known rules and records what changed. Instead of asking a human to inspect hundreds of log lines, the system produces a structured account of its state, failures and recovery status. Instead of repeatedly patching the same class of failure, the repair is converted into a durable rule so that future instances are handled automatically. The human role consequently moves upward from operation to intent, exception and governance.

This shift matters because enterprise AI has reached a similar transition point more broadly. McKinsey's 2025 global survey found that 62 percent of respondents said their organizations were at least experimenting with AI agents, yet nearly two-thirds had not begun scaling AI across the enterprise and only 39 percent reported enterprise-level EBIT impact. McKinsey's subsequent work on the divide between AI agents and enterprise systems argues that companies frequently accumulate use cases and pilots without rebuilding the end-to-end processes, data and technology required to turn those pilots into scalable operating value. Google's DORA research reaches a compatible conclusion from software engineering: AI is most valuable when introduced into a strong organizational system, while weak engineering foundations can cause AI to amplify instability as easily as productivity. The gap between experimentation and value therefore appears increasingly to be an operating-architecture gap rather than a raw intelligence gap. (McKinsey & Company)

AMOS's 90 percent proposition should be understood in that context. It is not primarily a promise that AI will write 90 percent of software. The more consequential objective is that a human should no longer need to perform most of the low-level coordination required to keep a complex intelligent system coherent. The operator defines intent, approves consequential change and decides how to handle genuinely ambiguous failures; the operating system assumes responsibility for the repetitive mechanics required to convert those decisions into a functioning system. This creates a different productivity model from conventional coding assistance. If the architecture succeeds, the unit of leverage is not lines of code per developer. It is the number of system-maintenance decisions that no longer require a developer at all.

1. The 90 percent opportunity sits outside code generation

The early commercial narrative around generative AI in software development concentrated heavily on coding velocity, and for good reason. Code generation is visible, measurable and easy to demonstrate. McKinsey estimated that generative AI could create direct productivity value equivalent to 20–45 percent of current software-engineering spending through activities including initial code creation, correction, refactoring, root-cause analysis and system design. The productivity gain is meaningful, but the same research implicitly exposes the limit of a code-centric view: software engineering is not simply the production of source code. It is an operating system of requirements, dependencies, environments, testing, integration, deployment, observability, governance and maintenance. Faster code production can therefore increase pressure on the rest of the system if those surrounding processes do not improve at the same rate. (McKinsey & Company)

DORA's research makes the point more directly. Its recent work characterizes AI as an amplifier rather than a universal performance enhancer. The 2025 State of AI-assisted Software Development research found widespread AI adoption and strong perceptions of individual productivity improvement, yet DORA's analysis emphasizes that the organizational system remains the decisive variable. A related DORA report found that a 25 percent increase in AI adoption was associated, in its measured context, with a 1.5 percent decrease in software-delivery throughput and a 7.2 percent decrease in delivery stability, even as individual developers reported productivity benefits. The result should not be generalized into a claim that AI harms engineering organizations; it demonstrates that faster local production can increase batch sizes, review requirements and instability if the broader delivery architecture does not adapt. (Dora)

AMOS attacks this second-order problem. The aim is not merely to make the developer faster at operating a complicated system. It is to reduce the number of reasons the developer must interact with the complexity at all. Environment setup, structural validation, repeated build processes, state inspection, artifact movement and recurrent repairs become candidates for absorption into the operating layer. If a task has a known correct procedure, repeatable inputs and machine-verifiable success criteria, the Omega philosophy asks why it remains a recurring human task.

This is an important economic distinction. Automating an action saves the time required to perform the action. Removing the need for the action saves the action, its coordination cost, its error probability, its documentation burden and the future training required to teach another person how to perform it. That is the compounding logic behind the 90 percent ambition.

2. AMOS starts from one canonical operating reality

One of the largest hidden costs in complex software environments is ambiguity about what is authoritative. Teams accumulate development branches, archived environments, old deployment packages, experimental versions, duplicated scripts and multiple paths that appear capable of starting the same system. Over time, engineers compensate by carrying increasing amounts of operational knowledge in their heads: which repository is live, which environment is safe, which script is current, which directory is archival and which workaround remains necessary. The system still works, but part of the operating system has effectively migrated into human memory.

AMOS's Omega model begins by attacking that ambiguity. From a business perspective, the important concept is one canonical operational reality. There is one active system state, one normal entry path and one controlled mechanism through which external changes become part of that state. Archives may exist, experiments may exist and backups may exist, but they do not compete with the production reality for authority. This sounds simple, yet it addresses a surprisingly large share of operational friction because many repetitive failures begin with uncertainty about state rather than incorrect code.

The analogy to enterprise platforms is instructive. Companies invested heavily in ERP partly because multiple independent representations of financial, inventory and operational reality create enormous reconciliation cost. The same principle applies inside increasingly complex AI systems. A self-maintaining architecture cannot exist if the system does not know which representation of itself is authoritative.

In the Omega approach, canonicalization is therefore a productivity mechanism, not merely repository hygiene. Once authority is unambiguous, generation, audit, recovery and automation become substantially easier because the system no longer needs humans to determine which version of reality should be acted upon.

3. The operating system should own its environment rather than borrowing the operator's shell state

A second category of hidden work comes from execution environments. Software engineers routinely encounter problems caused by mismatched interpreters, missing packages, incorrect paths, incompatible versions and environmental state inherited from earlier work. These failures are individually trivial and collectively expensive. They consume engineering attention without creating differentiated intellectual property or customer value.

The Omega model treats environment integrity as an operating-system responsibility. The runtime is expected to determine whether the required environment exists, establish it when it does not, verify critical dependencies and refuse to proceed when its execution conditions are invalid. The human operator should not need to remember an activation sequence before running the system because the correct environment is itself part of what defines a valid system launch.

The business principle is broader than any particular implementation. Any prerequisite that can be determined deterministically should be owned by the platform rather than remembered by the person. This principle applies to development environments, dependency validation, paths, permissions, service availability, schema versions and configuration compatibility.

At scale, removing these micro-decisions can create more value than automating individual lines of code because every micro-decision is also a potential source of variance. The same workflow performed by different engineers on different machines should not depend on informal operational memory when the correct state can be machine-verified.

4. The Omega architecture compresses many scripts into one governed lifecycle

Software estates frequently accumulate automation without becoming automated. Teams create a script for bootstrapping, another for synchronization, several for generation, others for testing and more for deployment and repair. Each script reduces one manual action but creates a new coordination requirement: somebody must know which script to use, in what order and under which conditions. Automation can therefore increase the number of operational artifacts even while reducing the number of keystrokes.

The Omega model seeks to move beyond this script-centric stage by treating system construction as a single governed lifecycle. The user expresses the intention to build, integrate or verify the system; the operating architecture determines the required sequence of environment preparation, structural construction, runtime validation and final state assessment. Intermediate components remain modular internally, but they no longer require manual orchestration during normal operation.

This distinction mirrors a broader maturity transition in enterprise technology. Early cloud adoption frequently involved collections of infrastructure scripts. Mature cloud platforms moved toward declarative environments, policy-driven deployment and centralized control planes. Early DevOps involved automating individual development tasks; mature platform engineering attempts to provide a coherent internal product that abstracts much of the underlying complexity from individual developers. DORA's 2025 research likewise emphasizes foundational capabilities and platform quality as key determinants of whether AI-assisted software development creates organizational value. (Dora)

AMOS pushes this concept toward an AI-native operating model. The objective is not to give engineers a larger collection of intelligent tools. It is to provide a system that understands the normal lifecycle of its own construction well enough that those tools disappear behind one controlled interaction boundary.

5. The most consequential shift is from manual construction to generation from canon

The 90 percent objective becomes difficult to achieve if every component remains handcrafted. Human labor may be shifted from coding into configuration, but the total maintenance surface remains large. The deeper leverage comes from reducing the number of artifacts that humans author directly and increasing the number that can be reliably generated from a smaller set of authoritative definitions.

AMOS is built around this law-first principle. The human defines the essential specification of what a component is allowed to be, what it must provide, what boundaries apply and how success is evaluated. The operating architecture can then generate implementations that conform to those definitions. The business analogy is manufacturing: the objective is not to train workers to assemble every product faster by hand but to design a production system in which the specification drives repeatable creation.

The leverage becomes substantial when the number of components increases. If 200 operational units share a common contract, changing 200 implementations manually creates 200 opportunities for inconsistency. Changing the canonical contract once and regenerating validated implementations transforms the maintenance economics. The system becomes definition-heavy and artifact-light from the human perspective, even if many artifacts continue to exist underneath.

This is one of the most significant distinctions between conventional AI coding tools and the AMOS approach. A coding assistant helps a developer create an artifact. A generative operating architecture seeks to make the artifact itself disposable because the authoritative knowledge resides in the specification from which it can be rebuilt.

That is a much stronger form of automation.

6. LDOA shifts software engineering from function maintenance toward law maintenance

The Law-First Deterministic Organism Architecture underlying AMOS formalizes this principle at a broader level. Rather than beginning with functions, services or applications and subsequently attempting to impose consistency across them, LDOA begins with the constraints that every implementation must preserve. The operating logic is therefore organized around laws, contracts and invariants before implementation details.

For business readers, the important implication is not the internal representation of those laws. It is the inversion of the maintenance model. Traditional software requires organizations to identify where a policy is implemented, change those implementations and test whether the resulting behavior remains consistent. In a law-first system, the policy exists at the governing layer and implementations are generated or validated against it.

The difference becomes particularly valuable as AI-generated software expands the volume of code organizations can create. McKinsey's 2025 software-development research argues that the value of AI rises substantially when companies redesign the full product-development lifecycle rather than merely accelerate coding. (McKinsey & Company) If code becomes dramatically cheaper to generate, the economic bottleneck naturally moves toward deciding what code is valid, how it should behave and how organizations maintain coherence across the resulting estate.

LDOA is designed for this post-code-scarcity environment. Its strategic hypothesis is that laws become more valuable as implementations become cheaper. When a machine can generate many possible implementations, the durable intellectual property moves toward the architecture that determines which implementations are legitimate.

7. AMOS treats software less like a project and more like an operating organism

Another distinction in AMOS is its treatment of maintenance. Conventional software development often views maintenance as a sequence of exceptions: something breaks, engineers investigate, patches are applied and a new stable version is released. The Omega model seeks to make health monitoring, isolation and regeneration part of ordinary system operation rather than exceptional human intervention.

The organism analogy is useful at a business level even without exposing implementation detail. Healthy biological systems do not require a central operator to consciously repair every minor deviation. They contain local mechanisms for detecting abnormal states, isolating damage and restoring function. AMOS applies a computational version of this philosophy. Components have expected operating conditions. Their health can be evaluated. Faulty components can be isolated from broader execution. A controlled regeneration process can attempt to restore the component from its authoritative definition, and successful repair can be verified before the component returns to normal operation.

The importance of this architecture increases with scale. As AI reduces the cost of creating software components, organizations can end up maintaining more components than human teams can realistically inspect individually. The economics therefore favor architectures in which maintenance becomes increasingly automated.

The objective is not a fantastical system that never requires engineers. It is a system in which engineers spend their time on novel failures and architectural decisions rather than repeatedly fixing conditions the platform has already encountered.

8. The architecture replaces log archaeology with machine-readable state

Operational troubleshooting remains one of the least glamorous but most expensive forms of technical work. Engineers repeatedly search logs, compare timestamps, inspect dependency failures and reconstruct the sequence that produced a system state. AI can help summarize logs, but that still assumes the system's primary interface to its own condition is unstructured text written for human interpretation.

The Omega approach asks a more fundamental question: if the system already knows which stages completed, which validations failed, which artifacts were created and which dependencies were unavailable, why should a human reconstruct those facts from logs?

The stronger architecture produces a machine-readable operational state as a first-class output. Normal logs remain available for deep investigation, but the primary result of a run is a structured account of what environment was used, which system sections were successfully built, which tests passed, what failed and what corrective path remains available.

This creates two forms of leverage. First, operators can understand the state of a large system without manually interpreting hundreds of lines of execution output. Second, AI itself can reason over the structured status artifact far more reliably than over an arbitrary log stream. The system therefore becomes easier both for people and for machine operators to manage.

This is one of the ways the 90 percent model compounds. Once operational state becomes structured, diagnosis can itself be automated more effectively. Once diagnosis becomes structured, recurrent repairs can be converted into rules. Once repairs become rules, future incidents stop consuming human attention.

9. The target state is not automation but a closed learning loop around failure

The deepest productivity gain comes when every resolved failure reduces the probability that the same class of failure will require human intervention again. Many organizations automate execution but do not automate institutional learning. Engineers solve the same dependency, configuration or environment problems repeatedly because the resolution remains in a ticket, chat history or individual's memory rather than being converted into platform behavior.

AMOS's operating philosophy treats repair as an input to system evolution. A failure is not complete when functionality is restored; it is complete when the architecture has enough knowledge to detect, prevent or automatically repair the same condition in the future where feasible.

This changes the economics of maintenance from linear toward cumulative. Conventional maintenance can resemble a treadmill: more systems create more recurring support. A self-improving operating environment can make the opposite relationship possible in selected areas: more resolved incidents increase the platform's ability to handle future incidents without people.

The idea aligns with DORA's characterization of AI as an organizational amplifier. AI does not replace the need for strong engineering practice; it increases the payoff from turning good practice into repeatable platform capability. (Dora) AMOS extends that principle by attempting to make the platform itself the long-term repository of resolved operational knowledge.

10. The DO–WATCH–GOVERN model changes how autonomous engineering should be controlled

As systems become more autonomous, one of the biggest enterprise design questions is how to prevent self-maintenance from becoming uncontrolled self-modification. AMOS addresses this at a business level by separating execution from evaluation and authority. One part of the architecture performs the work. Another evaluates whether the result satisfies the relevant quality and safety conditions. A governance boundary then determines whether the result can be accepted, retried, escalated or isolated.

The significance of this separation is difficult to overstate. Much of the current enthusiasm for autonomous coding assumes the same AI can generate a change, inspect its own change and decide whether the change should enter the system. That architecture is economically attractive because it minimizes friction, but it also concentrates failure modes. A system biased toward accepting its own output can manufacture confidence rather than assurance.

AMOS's approach makes autonomy conditional. Machine systems can generate and repair aggressively where the downside is contained, while the final authority to admit those changes remains governed by separate criteria. The mechanism is conceptually similar to financial controls separating transaction initiation from approval, or software organizations separating development from protected production deployment.

This creates a scalable pathway toward higher automation. The enterprise does not need to choose between manual control and unconstrained agents. It can automate execution heavily while preserving deterministic governance over what becomes authoritative.

11. The 90 percent target changes the human role from operator to governor

The most important implication of the Omega approach concerns work design. A 90 percent reduction in manual operating effort would not mean removing 90 percent of human intelligence from the system. It would mean redirecting human intelligence away from repetitive system mechanics.

The human would increasingly perform three functions. The first is intent: determining what the system should accomplish. The second is judgment: resolving ambiguous or genuinely novel conditions for which predetermined rules are insufficient. The third is governance: determining which constraints the automated system must obey and when those constraints should change.

Everything below that layer becomes progressively more automatable.

This is broadly consistent with the direction McKinsey identifies in software development, where AI can shift engineering effort away from code production toward architecture, product thinking and higher-value design. (McKinsey & Company) The AMOS proposition is more aggressive because it extends the shift from coding into operations, integration and repair.

The ultimate productivity unit is therefore human decisions per system outcome, not code output per hour. An architecture that can produce the same reliable outcome while requiring one human decision instead of twenty has created much more structural productivity than an assistant making each of those twenty decisions 30 percent faster.

12. Industry application: software engineering could move from AI-assisted coding to AI-operated development environments

Software engineering is the most direct application. Current AI tools increasingly help developers plan, generate, test and review software. The next stage is to operate more of the development environment itself. A request to add a capability could trigger controlled generation, integration, validation, documentation and audit processes without requiring the developer to manually navigate each layer.

The commercial upside extends beyond developer hours. Automated environment consistency reduces onboarding time. Generated components reduce configuration drift. Structured audit artifacts improve compliance. Controlled regeneration reduces the cost of system upgrades. Automatic quarantine limits the impact of faulty components. Canonical operating state reduces deployment errors.

The value is particularly strong for organizations managing large internal software estates where coordination cost can exceed the cost of writing any individual component.

McKinsey's 2025 study of nearly 300 publicly listed companies found a relatively small group realizing considerably greater value from AI-enabled software development by redesigning roles, processes and performance enablers rather than merely adopting AI coding tools. (McKinsey & Company) That result is directionally consistent with the AMOS thesis: the full productivity opportunity requires redesigning the development system, not inserting an AI assistant into an unchanged workflow.

13. Industry application: regulated enterprises could automate engineering without automating away control

Financial services, healthcare, energy and government face a different constraint. They may benefit enormously from automated development and operations but cannot allow a self-generating system to change production environments without strong traceability and control.

The Omega architecture's emphasis on deterministic input handling, structured audit, validation and controlled admission is therefore particularly relevant. A machine-generated change can move through much of the engineering lifecycle automatically while the evidence required for acceptance remains auditable. High-risk modifications can still require human approval, while routine rebuilding and low-risk repair can remain automated.

This potentially resolves a longstanding tension between agility and governance. Enterprises often implement governance by adding manual checkpoints because those checkpoints are easy to understand and demonstrate to regulators. The result is safe but slow. If key controls can become deterministic and machine-verifiable, organizations can preserve accountability without requiring a person to perform every verification.

The commercial opportunity is therefore not only productivity. It is lower governance cost per unit of software change.

14. Industry application: industrial and infrastructure systems can use self-repair without surrendering operational authority

Industrial systems provide another compelling use case. Plants, utilities, telecom networks and logistics environments contain large software and configuration estates, but autonomous repair must remain subordinate to operational safety.

An AMOS-style architecture can separate internal software self-maintenance from external physical authority. The system may detect and regenerate a failed non-critical component automatically, but actions capable of affecting physical operations can remain behind higher-order deterministic controls. This allows organizations to capture the availability benefits of automated repair without treating all machine-generated changes as equally safe.

The architecture resembles a broader trend toward autonomous operations in cloud and network environments, but the law-first model adds a strong distinction between what can repair itself and what can change the environment.

That distinction is essential if self-maintaining AI is to move beyond laboratory systems into enterprise infrastructure.

15. The benchmark is whether the architecture removes human work without moving the work somewhere else

The most important benchmark for the 90 percent thesis is not the number of automated scripts or AI-generated files. Automation initiatives frequently overstate productivity because visible work disappears from one stage and reappears as verification, debugging or exception handling downstream.

DORA's evidence provides a useful warning. AI can accelerate code creation while increasing review pressure and instability when organizational systems are not redesigned. (Dora) A credible AMOS benchmark must therefore measure net eliminated human work, not automated activity.

A serious evaluation would hold the system objective constant and compare conventional operation with the Omega model across a meaningful period. Human interventions should be counted. Time spent configuring environments, moving artifacts, interpreting logs, resolving dependency failures, rebuilding components, conducting routine validation and recovering from known classes of failure should be measured. The system should also track how often an automated action creates downstream remediation work.

Only then can a 90 percent reduction be demonstrated.

The target is demanding, but it is also the right one. If an architecture reduces 90 percent of manual build activity but increases verification labor sufficiently to offset the gain, it has not achieved the Omega objective. The metric is human operating burden removed end to end.

16. The commercial moat is not the scripts—it is the compressed operating knowledge

The strategic value of AMOS would not reside primarily in the individual automation routines required to build, validate or repair the system. Those techniques are increasingly reproducible, particularly as AI coding capability spreads. The stronger asset is the accumulated operating knowledge encoded into the system: definitions of valid components, known failure states, governance conditions, health expectations, repair paths and the relationships among them.

That body of knowledge is difficult to reproduce because it grows through operation. Every resolved failure can become another automated capability. Every accepted architecture decision can become another deterministic constraint. Every generated component can inherit the same standards. Over time, the operating system becomes a compressed representation of how the system should build, behave and recover.

This is the same reason mature enterprise platforms can create durable advantages even when their underlying technologies are widely available. The technology is replicable; the encoded operating model is harder to copy.

AMOS's law-first architecture concentrates that value deliberately. Instead of allowing institutional knowledge to remain distributed across scripts, engineers and documentation, it attempts to make the governing logic itself the durable asset.

17. The 90 percent model can reshape the economics of small technical teams

One of the most consequential possibilities is organizational. Complex software systems traditionally require teams whose size grows with the breadth of the system because every additional component creates maintenance, integration and operational obligations. AI coding tools can increase the output of each individual engineer, but the broader support structure often remains.

A self-generating and self-repairing architecture changes the scaling relationship. A smaller human team can potentially govern a much larger technical estate because the operating system absorbs more of the routine maintenance surface.

This has obvious implications for start-ups, research organizations and specialist teams. A small group could maintain infrastructure previously requiring a materially larger operations function, provided the system's deterministic boundaries and regeneration mechanisms remain robust.

For large enterprises, the opportunity is different but equally significant. Engineering talent can be redirected toward customer value, architecture and innovation rather than environment maintenance, repetitive integration and recurring repair.

The target is not labor elimination for its own sake. It is leverage concentration: reserving expensive human cognition for the decisions where it produces differentiated value.

18. The long-term destination is software that is rebuilt more often than it is manually repaired

Traditional software estates accumulate history. Patches modify patches; migrations preserve compatibility with older decisions; workarounds remain long after their original cause disappears. Over time, understanding the current system becomes more expensive because the architecture contains many historical layers.

A canon-driven architecture creates an alternative trajectory. When implementation artifacts are disposable and the authoritative system exists at a higher specification layer, rebuilding becomes more attractive than indefinitely modifying legacy outputs. A broken component can be regenerated rather than surgically repaired. A structural standard can be changed centrally and propagated through controlled regeneration.

This could have profound implications for technical debt. Technical debt exists partly because code is expensive to recreate and therefore survives long after its original design assumptions have changed. As AI reduces the marginal cost of generation, organizations may be able to shift from preserving every implementation toward preserving intent, evidence and constraints.

AMOS is built for that future. Its strongest long-term proposition is not that it can maintain an increasingly complicated codebase forever. It is that the codebase itself becomes a replaceable manifestation of a more durable operating definition.

Strategic outlook

The development of generative and agentic AI has created an unusual moment in software economics. The marginal cost of producing code is falling faster than the marginal cost of governing, integrating and maintaining software. Organizations that treat AI purely as a coding accelerator may therefore discover that the bottleneck simply migrates. Google's DORA research already points in this direction: 90 percent of surveyed technology professionals now use AI at work and more than 80 percent report productivity improvement, yet AI's organizational impact depends heavily on the quality of the surrounding development system and can amplify instability where that system is weak. (Dora)

The next productivity frontier is consequently operating-system compression.

AMOS, created by Trang Phan as an Absolute Operating System and built around a law-first deterministic architecture, approaches this frontier by moving the human progressively out of repetitive system mechanics. The Omega objective—reducing routine manual operating work by approximately 90–95 percent—comes from combining several shifts that are individually familiar but structurally more powerful when integrated: one canonical operational state, environment self-management, generated components, deterministic validation, machine-readable audits, controlled integration, continuous health monitoring, quarantine, regeneration and accumulated repair knowledge.

The architecture does not seek to eliminate human control.

It seeks to relocate it.

Humans define intent. Humans determine consequential boundaries. Humans resolve ambiguity that cannot yet be reduced safely to deterministic policy. Machines perform the repetitive work required to maintain those decisions at scale.

That is a different vision from today's copilot model.

The copilot makes the operator more productive.

The Omega model attempts to make much of the operation disappear.

Conclusion: the largest AI productivity gain may come from eliminating the work around the work

The first wave of AI-assisted software engineering focused on helping developers create artifacts faster. That opportunity is real and already measurable. McKinsey estimates substantial potential productivity effects across software engineering, while DORA finds widespread developer adoption and strong perceptions of individual productivity improvement. Yet both research streams increasingly point toward the same conclusion: the benefits of AI depend on the system into which it is introduced. Faster generation does not automatically produce faster, safer or more valuable software delivery. (McKinsey & Company)

AMOS begins from that problem.

Created by Trang Phan as an Absolute Operating System, AMOS is designed around a Law-First Deterministic Organism Architecture in which specifications, constraints and operating laws occupy a more durable position than the artifacts they govern. Its Omega operating model applies this architecture to an aggressive productivity objective: compress the normal human workload of building, integrating, validating, auditing and repairing the system until the overwhelming majority of routine work is performed by the system itself.

The significance of the 90 percent target is therefore not the percentage alone.

It is what the percentage represents.

A developer should not need to remember the correct environment if the system can establish it. A developer should not manually build hundreds of similar components if they can be generated from a controlled definition. An operator should not reconstruct system status from logs if the system can report its own state structurally. A known failure should not require repeated manual repair if the repair can become part of the operating architecture. A routine upgrade should not require system-wide file surgery if controlled regeneration can recreate the affected components. And a machine-generated change should not require humans to inspect every detail if deterministic evaluation can establish that the relevant invariants remain satisfied.

Every one of those shifts removes a small amount of operational labor.

Integrated together, they create a very different system.

The human ceases to be the mechanism holding the architecture together.

The architecture begins holding itself together.

That is the deeper business meaning of the AMOS Omega model.

It is not simply automation of software engineering.

It is an attempt to change the labor structure of software itself—from systems that require people continuously to build, coordinate and repair them toward systems in which people increasingly define intention, boundaries and exceptions while the operating architecture performs the mechanics of remaining coherent.

If that model can demonstrate a genuine 90 percent reduction in end-to-end manual operating effort under production conditions—not merely a transfer of work from creation into verification—it would represent a substantially larger productivity shift than conventional coding assistance.

The company using such an architecture would not merely write software faster.

It could operate more software, with fewer manual interventions, through a smaller decision surface, and with a greater share of human attention concentrated on the work that machines cannot yet reduce to reliable operating law.

That is the economic logic of the 90 percent model.

And it may ultimately be the more important question for enterprise AI:

not how much work the machine can perform,

but how much work the human should no longer have to perform at all.

Institution for Trust, Intelligence & Autonomy

Design. Intelligence. Automation.

Home - Work - Capabilities - Insights. - About - Contact

INQUIRIES

solutions@itia.ai

North America — Vietnam — Australia

© 2026 ITIA-Production-grade AI engineering for the global enterprise.