Current chaos engineering tools excel at safety but lack a crucial intent layer. While systems like AWS Fault Injection Service effectively manage safety through SLO error budgets and abort conditions, they fail to answer a fundamental question: did the experiment test the right thing? An experiment can be perfectly safe, stay within budget, and leave the system stable, yet still yield no new insights if it does not validate a specific hypothesis about failure propagation. This structural gap causes programs to accumulate scripts without accumulating understanding. The core distinction lies between safety and informativeness. Safety determines how much to break, while intent dictates what breaking will teach. Existing tooling addresses the former but ignores the latter. Chaos scripts are static at authorship, often encoding assumptions about system topology that become obsolete as microservice architectures evolve. Engineers may inject failures into components that no longer impact critical user behaviors, resulting in data that is technically accurate but practically useless. Industry leaders identify this ceiling across various sectors. Abhishek Pareek of Coders.dev notes the need for tools that model failure effects before execution, emphasizing that engineers require AI that understands the reasoning behind a failure, not just the mechanics. Edward Tian of GPTZero argues that current tools inject arbitrary faults rather than validating specific resiliency questions, such as whether a system can tolerate data retrieval degradation. Similarly, Ishu Anand Jaiswal of Intuit highlights the need for an AI planner that understands live topology and a prospective resilience budget to maximize learning while minimizing risk. A proposed intent-based architecture addresses these deficiencies by replacing hardcoded scripts with behavioral specifications. This system uses four layers: an experiment generator that derives tests from intent, a safety evaluator with behavioral context, and an outcome recorder that updates the system model. The intent specification defines a target behavior, a falsifiable hypothesis, and acceptance criteria in behavioral terms rather than infrastructure metrics. For example, a hypothesis might state that checkout latency will remain within SLO limits even if an inventory service experiences high read latency, rather than simply stating "inject latency into service X." This approach shifts safety evaluation from static thresholds to real-time resilience scoring. Instead of aborting based on a fixed error budget or latency spike, the system halts experiments only when the target behavior degrades beyond accepted criteria. This allows the tool to distinguish between a database timeout during a critical signup flow, which is catastrophic, and a similar timeout during a background job, which may be negligible. Furthermore, this architecture extends blast radius measurement to business signals. James Shaffer of Insurance Panda demonstrates tying fault injection directly to revenue metrics. If active quote completions drop by even a small margin, the experiment terminates immediately. This ensures that chaos testing prioritizes financial impact over technical noise. The outcome data model also captures discovered dependencies, allowing the system to update its internal graph of the service topology and improve future experiment design. Ultimately, chaos engineering is becoming an AI problem rather than just an orchestration challenge. Deterministic guardrails are insufficient for the complex, non-enumerable decision spaces required to predict failure cascades. To advance the field, three gaps must be closed: a standard intent specification schema for machine readability, structured experiment outcome data for training predictive models, and a hypothesis-quality evaluation metric to measure the informativeness of experiments. By integrating an intent layer, the industry can move from blindly breaking systems to systematically learning about their resilience.