cohix

Dynamic workflows in awman are an open-source take on Claude's dynamic workflows but with pluggable agent harnesses and models.

I do exactly this with awman workflows: https://github.com/prettysmartdev/awman/blob/main/docs/05-wo...

You can use any agent and/or model for each step and share context between them.

> But on the other hand... this is a robust reminder that coding agents can do anything you can do by typing commands into a terminal—and frontier models know every trick in the book and evidently a few that nobody has ever written down before.

> Running coding agents outside of a sandbox has always been a bad idea

This is why I always run code agents inside containers (Apple containers specifically, for better hypervisor-level isolation)

This is my OSS project to manage said containers and agents: https://github.com/prettysmartdev/awman

And me? I’m the damn fool that shot him…

I’ve worked with Wasm for about 6 years now (founded a company around it that got acquired, even)

Even though our product was not a commercial success ~3 yrs ago I still believe something like this should succeed and give people choice when it comes to isolation/virtualization (containers, microVMs, Wasm). They are each useful and appropriate for different things.

I sent you an email!

I would certainly be interested. Please reach out to connorjhicks at gmail to discuss!

Please do, interested to add Boxes as a runtime for awman, then workflows could execute in the cloud transparently.

Would love to have some collaboration on the Windows side. Windows builds get published but get little to no manual testing, and not “fully supported” as of now but I would like to. If you can file issues and/or PRs I’d happily review.

Will check out your project as well, looks similar to where I started with awman but it’s morphed since then.

I really like the pricing model and focus on not shafting people by auto-sleeping when an agent is done working.

I’ve been working on an [OSS TUI](https://github.com/prettysmartdev/awman) for managing agent execution and workflows in containers (local or remotely) and would love to collaborate if you’re interested.

A workflow manager that automates the software development lifecycle around code agents in the terminal.

Built on top of Kubernetes and Agent Substrate

Founder of Suborbital here, happy to answer any questions!

Hello!

> Could you share some insights on why wasmtime and not wasm3 or wasmer in particular

The underlying architecture also supports Wasmer (there's a compiler flag to switch between them), and between the two, Wasmtime is better suited to be statically compiled into the Sat binary, which was a pre-set requirement for this experiment. Wasm3 is also awesome, but Wasmtime does have a performance leg up on Wasm3.

> What do you make of Cloudflare's / Deno.land's approach of relying on v8 isolates (which can run WASM) versus relying on WASI for the nanoprocess model? Do you think eventually most edge-functions would be WASM-only (as opposed to v8 / firecracker)? Or, are there inherent limitations in the WASM-only approach?

I personally believe that eventually the Wasm/WASI-only approach will be very viable, and even today you could run Sat on bare-metal with the right configuration and get very good sandboxing. CloudFlare/Deno are using one of the most natural on-ramps into the Wasm ecosystem, and I think it's a perfectly valid approach that will likely work very well, the V8 code optimizer is no slouch.

> Any developments you'd particularly recommend folks keep an eye on?

The ones you mentioned certainly, as well as wasmCloud, Lunatic, Yew, AssemblyLift, and Fastly's Compute@Edge are all projects to watch in the WebAssembly space.

> How did the team get together to work on suborbital?

Suborbital started as an open source project (Reactr), and is now a startup that focuses the majority of its efforts on open source Wasm tooling/frameworks/etc. I am the founder of said company, and the others are the founding team!

> I particularly think WASM is poised to take over serverless itself. So, all the best and hope you folks make it. Thx.

Thank you, and I agree :)

Sat is a pre-built server and a set of APIs wrapped around Wasmtime, it could theoretically use WAMR as well!

The end goal is that Docker isn't needed at all, you could just run Sat on bare metal and you'd get all the nice sandboxing properties of Wasm. That said, the tooling in the industry is largely container-based, so that's the starting point for now.

The benefit you get today is you can actually run un-trusted code in Wasm and have a higher level of sandboxing than a container, for example you can run user-submitted code with the right configuration.

When writing for Wasm, I'd say the best thing to keep in mind is that the ecosystem is young and so not everything is fleshed out, but there are already a ton of cool things you can do, and the experience will vary depending on the language you're using to target it.