Congrats on the launch. You mention probes are read-only by design, which makes sense for debugging. Curious about the flip side: when an agent does make a write that turns out wrong, have you thought about extending the same approach toward capturing state before the write, so it's actually reversible? Seems like similar instrumentation (in-process, no redeploy) could apply, but the reversibility side seems mostly unsolved right now.

Thanks!

It could work, the technology isnt the limitation.

But we were clear from day one that we cant let our sdks change the memory. Even if it helped solve a real problem.. say for example resetting a bad env variable or a feature flag without redeployment.

I might be biased from my experience, but i would prefer having a bug in my system for longer that i can reliably reason with than having it solved dynamically within the app which adds another thing to keep in my mind.

for me, bug -> fails -> good bug + dynamic patch -> works -> bad

also we dont think that we ourselves wont have any downtime ever, so we design for it. we'd not want to become as critical for your app as say your database.

As of now, your app works even if our servers are down/blocked/slow, adding the ability to change memory on the fly could change this