1. Control and guardrails. I want agent-authored code to be able to express itself in code but I want to own the external tools that are available to the agent.

2. Suspension and resumption. Monty's VM state is fully serializable so I can run the VM until it gets to a tool call and persist the VM state. I could resume it days later with the results of the tool call with no issues. Doing that guaranteed with CPython is really tricky (tools like Pickle can get you close but if you have open sockets or other weird stuff you're in a world of hurt).

▲

simonw a day ago | parent [-]

I'm pretty sure that first one can be achieved using MicroPython or CPython.

Your point 2 is very convincing: I hadn't realized Monty had serializable state as a core feature, that's a very compelling attribute for an agent runtime! I have my own projects that could benefit from that.

▲

camdenclark a day ago | parent [-]

Absolutely the first one could be achieved using one of those tools. But Monty makes it feel so native, it even packages a type checker so you can provide stubs for the external functions (so you provide feedback to the agent on the type of those things).

Serializable state is the most cool property though. It's really undersold in the explanations but makes running durable agent workflows authored in code possible!

	▲	ok_dad 18 hours ago \| parent [-]
		I’m curious about examples you have for using this? I am only thinking about if you wanted an agent to be serviced by a multi node system you could pause and resume an agent, or maybe you could warm up a Monty VM with certain state then store it as the default Monty environment for your agents? I actually have use cases for this but I want to find more and really think about using this in my software.