Runtime adaptation without methodology drift
Runtime adaptation expresses the same AAM responsibilities, work products and acceptance logic through an agent environment's native conventions. A runtime owns concrete execution behavior; an adapter is the boundary that preserves semantic intent while mapping it to native mechanisms.
This conceptual reference discusses execution environments for AI Architect Mastery's vendor-neutral AI Driven Development Methodology. Adaptation changes native mechanisms, not the PRD → PLAN → TASK → IMPLEMENTATION workflow. It is not a requirement to install an AAM product.
What stays stable and what can vary?
AAM defines WHAT; runtime / adapter defines HOW. AAM defines the responsibilities, work products and acceptance logic that must be preserved. The runtime and adaptation boundary determine how those requirements are expressed and executed through native mechanisms.
Intent, responsibility, scope, acceptance criteria and human accountability remain stable. Instruction loading, role configuration, permissions, tool syntax and execution behavior can vary. Adaptation is therefore more than renaming configuration files.
How to evaluate a mapping
- Identify the semantic requirement: for example, a read-only review role.
- Identify the runtime's actual native mechanism and configuration.
- Verify support in the named environment: present, partial, permission-dependent or unavailable.
- Record gaps and adjust the bounded assignment without weakening acceptance.
- Use native execution evidence to establish what actually worked.
Constructed limitation: a review-only environment
A runtime can inspect a diff but has no permission to execute tests. The agent can deliver static review findings, not verified runtime behavior. The human must obtain the required test evidence elsewhere or keep acceptance pending.
Defined model versus available product
- Defined
- A concept and its semantic boundary are part of AAM's methodology.
- Reference design
- A documented structure illustrates the intended model.
- Verified implementation
- A named, versioned environment demonstrates reproducible behavior.
- Planned product capability
- A future target, not something a user can assume is available.
No specific directory layout is mandatory for the methodology. A reference harness design does not prove that an installer, adapter generator, extension or plugin is released. This page makes no such availability claim and does not claim feature parity between vendors.