"Compile" Markdown specs for SDD or Subagents into executable logic, e.g. CodeAct+DSPy+Prolog. Not sure how and if I will continue, but it's been lots of fun.
I'd be curious if a middle layer like this [0] could be helpful? I've been working on it for some time (several iterations now, going back and forth between different ideas) and am hoping to collect some feedback.
Network can be closed down. It also uses a userland network stack, so future iterations might include being able to define rules for ingress and egress.
I've been recently experimenting with using a Prolog-based DSL [0] as the missing layer: Start with a markdown document, "compile" it into the DSL, so that you obtain an "executable spec". Execution still involves LLMs, so it's not entirely deterministic, but it's probably more reliable than hoping your markdown instructions get interpreted in the right way.
Hi all, been building this in public for some time. This is my latest iteration, hoping to get some interesting comments and feedback here, before I go down yet another rabbit hole and unnecessarily burn through even more premium tokens.
Thank you! When I started working on agentvm my original goal was similar to yours, build a kind of Mingw or Cygwin for WASM. However, I quickly learned that this wouldn't really be feasible with reasonable amounts of time/token spend, mostly due to issues like having to find a way to make fork work, etc. I am no expert for WASM or Linux system programming, but it's been a lot of fun working on this stuff. I hope that the WASI standard and runtimes become more mature, as I feel that WASM sandboxes make a lot of sense in environments where containers are not an option.
> Don't there need to be per- CPU/RAM/GPU quotas per WASM scope/tab? Or is preventing DOS with WASM out of scope for browsers?
> IIRC, it's possible to check resource utilization in e.g. a browser Task Manager, but there's no way to do `nice` or `docker --cpu-quota` or `systemd-nspawn --cpu-affinity` to prevent one or more WASM tabs from DOS'ing a workstation with non-costed operations.
Thanks for sharing the context! The fork problem is gnarly. Makes sense that full Linux emulation was the path forward for your use case.
Agreed on WASI maturity. We're hoping the component model lands in a stable form soon. Would love to see the ecosystem converge so these approaches can interoperate.
linux-wasm is an awesome project, but relies on compiling the kernel itself into WASM. This seems to work in principle, but is still a bit unstable. But I do hope that eventually one can get rid of the emulator in the middle as is done in c2w.
Thought this could be useful. Opus 4.5 helped me build most of it, including a simple network stack so that the VM may access the outside world. Still at a very early stage, but I think it looks promising.
"Compile" Markdown specs for SDD or Subagents into executable logic, e.g. CodeAct+DSPy+Prolog. Not sure how and if I will continue, but it's been lots of fun.