What Is Automorphic Design? Building Systems and Organizations That Can Change in the AI Era

AI is evolving quickly. Models, interfaces, regulations, and user expectations now change within months. In this environment, an approach based only on defining the right requirements at the beginning and building a finished system means that the system may start becoming obsolete the moment it is completed.

What we need is not only the ability to predict the future accurately. We need the ability to change shape as circumstances change without losing what matters most. I call the practice of building this capability into systems, services, and organizations “automorphic design.”

Automorphic design is not the name of an established standard. It is a design philosophy I am developing by moving back and forth between research and implementation. Its foundations, however, draw on a long history of work on changeability in systems engineering, self-adaptive software, resilience, and dynamic capabilities in management.

Being robust and being able to change are different

A robust system continues to behave in the same way when it encounters an anticipated shock. Robustness matters. But when the assumptions themselves change, preserving the same behavior can become a source of risk.

Fricke and Schulz described changeability across a system lifecycle through flexibility, agility, robustness, and adaptability. Ross and colleagues further organized changeability around who initiates a change, what changes, and by what mechanism. Change is not an exception to be handled later; it is itself an object of design.

Resilience research points in the same direction. Holling distinguished the stability of maintaining a state from the capacity of a system to persist through disturbance and reorganization. The goal is not merely to return mechanically to an earlier form. It is to preserve essential functions while changing structure in response to the environment.

This leads to the first principle of automorphic design:

Protect the purpose, not the form.

Six principles of automorphic design

1. Define the core that must not change

A system in which everything can change is not free; it has lost its basis for judgment. Begin by articulating an invariant core: purpose, values, rights, and safety conditions.

For medical AI, that core may be patient safety and dignity. For educational AI, learner agency. For enterprise AI, accountability and promises made to customers. Features, interfaces, and models may change, but the core remains the standard for deciding whether a proposed change is acceptable.

2. Separate the parts that may change

Do not fuse AI models, data sources, rules, permissions, interfaces, and operating procedures into one monolith. Divide them into replaceable units and make their dependencies explicit. Modularity is not only about making development easier; it limits the impact of change.

Research on self-adaptive software has emphasized a cycle of monitoring the environment, analyzing state, planning a change, and executing it. In the AI era, human judgment and organizational rules must be built into that cycle.

3. Maintain windows that can detect change

If we monitor only the indicators imagined at design time, unexpected change remains invisible. Alongside performance, usage, and failure rates, we should observe why people stopped using a system, which procedures staff work around, and who remains absent from the data.

AI can perform impressively inside the data it receives, but it will not necessarily announce changes that the data does not contain. Quantitative indicators, voices from the field, known failures, and unfamiliar signs of discomfort must feed the same learning loop.

4. Experiment on a small scale—and make rollback possible

Do not apply every change to the entire system at once. Test within a limited scope, preserve a comparison, and define stopping conditions and recovery procedures. A prototype is not simply a rough version of a finished product. It is an instrument for making a desirable future appear at small scale so that we can learn from it.

Being automorphic does not mean always moving forward. The ability to return from a mistaken change is also a fundamental design capability.

5. Keep humans as the authors of change

A system is not automorphic merely because AI continues optimizing it automatically. We must make clear who sets the purpose, who approves a change, and who can stop it.

The NIST AI Risk Management Framework also distinguishes the roles, responsibilities, and oversight of humans and AI, and treats risk management as a continuing lifecycle activity. It is not enough for a human to press the final button. People need to understand why a change was selected and retain meaningful alternatives.

6. Change the system and the organization together

Even if the technology can adapt, change will stop when organizational decisions, contracts, evaluation systems, and budgets remain fixed. Conversely, a new strategy cannot be executed when information systems continue enforcing an old way of working.

The dynamic-capabilities perspective developed by Teece and colleagues focuses on an organization’s ability to integrate, build, and reconfigure internal and external capabilities under rapid technological change. Automorphic design treats this organizational capability and the system architecture as one design problem.

Why this matters in the age of AI agents

Traditional software executed written procedures quickly and accurately. AI agents interpret situations, make plans, choose tools, and divide responsibilities with other agents and people. Their behavior can therefore be recomposed at runtime.

Static requirements alone are no longer sufficient. At minimum, we must make the following operational:

• purposes and prohibitions that do not change
• the scope delegated to AI and the conditions for returning control to people
• data and tools the agent may use
• records of decisions and methods of evaluation
• stopping, degraded-operation, and recovery procedures
• paths for learning from new situations and returning that learning to design

The more freedom we give AI, the more clearly its surrounding boundaries and learning loops must be designed. Autonomy and control are not opposites. Well-designed control makes safe experimentation and change possible.

Design a grammar of change, not a final form

Automorphic design does not aim to create a universal system capable of handling every possible future. Nor can we predict every future. The goal is to establish a “grammar of change”: when change arrives, what do we protect, what may change, who decides, and how do we verify the result?

Do not stop at the vision. Do not try to complete the future in a single attempt. Use prototypes to invent a small instance of a desirable future, learn from the field, and change shape again.

That is what I mean by automorphic design.

References

• Fricke, E. & Schulz, A. P. (2005). Design for changeability: Principles to enable changes in systems throughout their entire lifecycle.
• Ross, A. M., Rhodes, D. H. & Hastings, D. E. (2008). Defining changeability: Reconciling flexibility, adaptability, scalability, modifiability, and robustness.
• Salehie, M. & Tahvildari, L. (2009). Self-adaptive software: Landscape and research challenges.
• Holling, C. S. (1973). Resilience and Stability of Ecological Systems.
• Teece, D. J., Pisano, G. & Shuen, A. (1997). Dynamic capabilities and strategic management.
• NIST (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0).