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.

1Password is hiring REMOTE in US/CANADA for a lot of roles.

I lead the platform integrations team and we build some incredibly cool things including the CLI, SCIM bridge, and some unannounced projects that get me so excited I can hardly stop myself from telling you what they are right now.

Customer Integration Specialist (Support Engineer mixed with DevRel): https://jobs.lever.co/1password/efe0dbd3-239f-4472-9f6f-71bf...

Developer - Platform Integrations (not quite a backend dev, closer to full stack): https://jobs.lever.co/1password/bb67606b-0de1-40f8-b5a1-a535...

These ones ^^ are specifically on my team, but there are about 40 other roles as well!!

https://1password.com/jobs

PLEASE apply even if you’re unsure of quals!!

I've been working on this as a way to simplify and standardize how my projects do background tasks/concurrency, and yesterday I added support for running WASM jobs natively. Take a look and let me know what you think!

Thanks very much, and I hope within the next 2-3 months we'll be in a place where you can hold the CLI to those standards as well :)

Disclosure: I am the lead developer for the team that builds the 1Password CLI.

You're completely right about the use-case there. One of the things I think we missed the mark on was choosing to expose the full item JSON structure as the default. I think it is important that access to the full item is available, but I think it would have been a much better user experience if we had abstracted that in the default case.

What you've pointed out here is what we are currently working on addressing. Development of the CLI was put on hold for over a year while development of our SCIM bridge was ongoing (they're built on the same codebase). In the past few months, we have ramped up the entire team, and movement has accelerated greatly on the CLI. This is feedback we're well aware of, and we're working hard to address it.

Feel free to post in our discussion forums if you're still willing to have a more extensive conversation: https://discussions.agilebits.com.