diff --git a/adr/007-default-runtime.md b/adr/007-default-runtime.md
index 21781ce..8515ffd 100644
--- a/adr/007-default-runtime.md
+++ b/adr/007-default-runtime.md
@@ -66,3 +66,14 @@ We selected **k3s as the default runtime** for managed workloads on Linux platfo
 - **Relying on User-Provided Runtime:**  This would require users to install and configure their own runtime environment, which goes against our "zero setup" goal.  Increases support burden and leads to inconsistent environments.
 - **Virtual Machines (VMs):** Using VMs would provide isolation, but would be much more resource-intensive and slower to start than container-based solutions.
 
+## Future work
+
+There is a hype cycle around WASM that holds some ground : WASM to replace containers makes sense in many ways.
+
+To me, it feels just like Java with bytecode. If you can compile to bytecode, all you need to run your program is a JVM. Now, as long as you can compile to WASM, you can run your program on any WASM runtime.
+
+This feels like a sensible iteration over both managing containers, that are just bundling a bunch of libraries to make sure your program has everything it needs. This brings major benefits that used to come with the JVM such as observability into heap allocation, garbage collection, etc.
+
+The benefits won't be the exact same but it is reasonable to consider that this simplification and unification of runtime from containers to WASM will bring very significant improvements to the entire software delivery lifecycle.
+
+Down the road, it will be interesting to consider WASM, but the maturity versus our target customer base is not there yet.