ASM 7.0 can detect failure patterns. But we refuse to automatically retry or reroute without explicit human-defined policies. Autonomous systems that act on false positives cause cascading failures. We give you the data. You write the rules. Part 8: The Road Ahead – Scripts as Infrastructure With 7.0, we've changed the ontology. ASM is no longer a "script runner." It's a control plane for ephemeral, intent-driven workloads .
— The Anu Core Team We open-sourced the Stateful Execution Graph prototype. [Link to GitHub.]. Contribute, critique, or just stare at the complexity. All feedback welcome.
How we rebuilt ASM from a script runner into a cognitive automation fabric.
We don't believe in "Ask ASM to deploy the stack." Ambiguity is the enemy of automation. Scripts are code. Code is precise. We won't paper over that with a chat bot.
Or, if you're on 6.x: as-cli upgrade plan --from=v6 --to=v7
Traditional script managers treat each execution as an amnesiac event. Run → Log → Exit. In a world of event-driven architectures, fragile microservices, and self-healing infrastructure, amnesia is a liability.
This is forensic-grade automation debugging. No more "it worked on my machine." You can reproduce the exact execution context from three months ago, down to the pip package versions. I won't lie to you. Upgrading from 6.x to 7.0 is not a apt-get upgrade .
ASM 7.0 exports OpenTelemetry traces natively. Every script execution is a trace. Every subprocess call, every HTTP request from inside the script, every file read – all spans.
But we added one proprietary twist: .
In ASM 7.0, the SEG recognizes the anomaly pattern, injects a pre-processing shim (a built-in Python function you wrote months ago for a different job), repairs the header on the fly, and logs the intervention. The script succeeds. The on-call engineer never wakes up.
This eliminates the "runaway script" problem. No more accidental rm -rf on production because of a stale environment variable. The script must declare its intent. ASM 7.0 enforces it. We heard your frustration. "Why do I need a separate FastAPI app to trigger my maintenance script?"
The problem wasn't concurrency. It wasn't the UI. It was context .
