#Principle
Some complexity belongs to the problem itself; design determines where that complexity is handled and who must carry it.
#Why it matters
A system cannot always be made simpler by removing controls. Complexity can be absorbed by software through defaults, automation, validation, inference, and good information architecture, or pushed onto users through manual configuration and recall. Over-automation can also hide important decisions. Layr should ask whether complexity is allocated to the party best equipped to manage it.
#Deeper design interpretation
Some complexity cannot be removed because it belongs to the underlying problem. A migration may genuinely require mapping uncertain fields; permission systems may require policy decisions; financial workflows may require review. Design decides whether that complexity is handled by the user, by the system, or through a collaboration between both.
Good products absorb repetitive, mechanical, and deterministic complexity through defaults, derivation, validation, automation, and sensible inference. They keep consequential judgment visible to users. The challenge is avoiding two extremes: exposing every implementation detail as configuration, or hiding meaningful decisions behind opaque automation.
Layr should ask who is best equipped to handle each part of the complexity and what happens when the system is uncertain.
#What the agent should reason about
Classify complexity as mechanical, inferential, policy-based, or consequential. Mechanical complexity is often a strong automation candidate. Policy and high-consequence choices generally require explicit user involvement. Inferential automation should expose confidence and recovery when uncertainty is material.
The agent should evaluate total correction cost, not only initial setup effort. Automation that frequently guesses wrong may increase overall complexity.
#Common failure patterns
- Users manually transform data the system can derive exactly.
- High-confidence mappings require repetitive confirmation.
- The system makes financial or permission decisions silently.
- Advanced configuration is required for common cases with obvious defaults.
- Complexity is hidden until an error occurs, leaving no diagnosis path.
#Audit questions
- Which complexity is inherent to the task?
- Which part can the system handle deterministically?
- Where is human judgment necessary?
- How does the interface expose uncertainty and recovery when automation is imperfect?
#Example agent finding
High — Import mapping pushes deterministic work onto the user. Twenty-three source columns exactly match destination fields by name and sample type, yet every mapping requires manual confirmation. Preselect high-confidence matches, show the evidence, and require explicit review only for ambiguous or consequential mappings.
#Agent directive
Move avoidable mechanical complexity into the system while keeping consequential choices visible to the user.
#Apply this when
- Imports, configuration, data mapping, permissions, integrations, onboarding, scheduling, billing, and advanced workflows.
#Observable signals
- Users manually calculate or transform data the system already has.
- The interface exposes backend implementation constraints as user decisions.
- Automation makes a consequential choice without showing assumptions.
- Advanced configuration is mandatory for common cases with predictable defaults.
- The product hides necessary complexity until failure, leaving users unable to diagnose it.
#Recommended actions
- Automate repetitive transformation, validation, and sensible defaults.
- Surface uncertainty and assumptions when automation is imperfect.
- Require explicit input for decisions that involve policy, money, access, or irreversible consequences.
- Provide advanced controls after the common path, not before it.
#Do not over-apply
Automation is not automatically simpler. If the system cannot infer safely, explicit user control may reduce total complexity by preventing correction work.
#Example
Weak
An import asks users to manually map every obvious field even when names and sample values match with high confidence.
Stronger
High-confidence mappings are proposed and visible for review; ambiguous or consequential mappings require explicit confirmation.
#Evaluation notes
- Default severity: Medium to high in repeated or error-prone workflows.
- Typical confidence: High when the system already has the information needed to reduce manual work.
- Primary evidence: System capabilities, repeated input, automation confidence, decision consequence, error recovery.
- Related rules: Occam's Razor, Cognitive Load, Mental Model, Postel's Law