Supporting Agents, and microvm developer environments

[nick-walt]

Hi @luccahuguet,
This is an obvious idea you've no doubt considered and is perhaps outside the scope of Yazelix Nova and may sit with Zellij — could a Herdr or Supacode style TUI experience for managing Agents be possible, with the added capability for the Agent panel to be hidden when working directly in the human developer environment?

Additionally, to be able to view and interact with Agents running under a special or separate agent user account that runs alongside the developer's account with lower permissions and accessed via a separate SSH login.

The Agents may even run in a completely separate repository and developer environment contained in a microvm, such as through Apple's Containerization implementation via Kata Containers OCI runtime, or the NixOS microvm implementation via microvm-nix (Nix Module supporting five microvm hypervisors, including Cloud Hypervisor and Firecracker):
https://github.com/apple/containerization
https://microvm-nix.github.io/microvm.nix/
https://www.cloudhypervisor.org/docs/prologue/introduction/

Possibly related to Agent management in developer environments is the ability for the terminal multiplexer to traverse microvm "containers" as if they were directories under the same root. The Gnome GTK4 terminal emulator called Ptyxis has some capability of doing this for Docker and Podman containers, possibly through the OCI runtime which Kata Containers also provides as an interface which is native to Apple Containerization (not sure if microvm-nix exposes it's supported microvm hypervisors via OCI).

Even Podman rootless containers are not enough of a security boundary for Agents. This is where microvm hypervisors come in. Plus it may be that Virtio-GPU DRM Native Context will be supported by microvm hypervisors, such as Cloud Hypervisor, CrossVM or QEMU microvm. Incus just added support in version 7.3:
https://discuss.linuxcontainers.org/t/incus-7-3-has-been-released/27033#p-92489-gpu-sharing-for-virtual-machines-through-drm-native-context-3

Incus may implement microvm capability via the QEMU microvm hypervisor and subsequently support Native Context in a microvm if QEMU microvm supports it:
https://discuss.linuxcontainers.org/t/a-fun-project-microvms-with-incus/26889/4

[luccahuguet]

Will check!

Thank you for such a rich suggestion

[luccahuguet]

"agent workspaces with isolated execution targets"

saved this idea for later

might use it!

[nick-walt]

In looking for a multiplexer and terminal pairing it is clear that their integration can be improved, especially for remote dev over SSH.

Additionally, if a full virtual machine contains numerous microvm "containers" it would be awesome if the multiplexer could be installed as a service into each microvm and be integrated with the same multiplexer installed into the parent virtual machine which multiplexes everything to the remote terminal.

In a way the terminal emulator should be configurable to pass through key functions handled by the multiplexer, such as window and tab management, developer environment management (including passing through the interaction of the multiplexer (mux) with systems like Direnv).

This sits squarely in the ballpark of Zellij and other multiplexers but worth mentioning here. It is almost as if the mux and the terminal emulator need to be integrated. What do you think?

[luccahuguet]

It is almost as if the mux and the terminal emulator need to be integrated

the next yazelix line (after nova) is kind of like that

I will give you a more complete answer later, but I overall like where this is going

[luccahuguet]

is there anything about herdr you are not happy about?

[nick-walt]

I haven't spent enough time with Herdr but the UI and Docs didn't make it obvious that the agent panel could be hidden for normal muxing. The marketing is almost entirely focused on agents moreso than muxing as a complete experience.

The biggest issues with these CLI and TUI programs is discovery. The best TUI I've ever experienced for discovery and ease of getting into advanced features was Cisco's IOS CLI — totally contextual help system that was essentially documentation and autocomplete at your fingertips, without the invasiveness and noise of most coding autocompletes.

Probably the best static (file) configuration experience is vscode, where all settings are scaffolded but only default values are populated. Just browse the config file via vscode to determine what to enable.

I was in Ghostty recently and opening the configuration file of a fresh installation revealed a completely blank page — not even defaults were listed: and this is supposed to be a batteries-included experience.

Herdr looks great but it's still early days and it feels incomplete as a mux beyond the agent panel.

[luccahuguet]

I haven't spent enough time with Herdr but the UI and Docs didn't make it obvious that the agent panel could be hidden for normal muxing. The marketing is almost entirely focused on agents moreso than muxing as a complete experience.

i've no idea if herdr can do this or not...

but how do you like yazelix's agent popup? seems to be exactly what you want. always toggleable, and keeps running on the background

Probably the best static (file) configuration experience is vscode, where all settings are scaffolded but only default values are populated. Just browse the config file via vscode to determine what to enable.

yazelix answer to that is the ratconfig popup. hopefully this is working well for you. we save only the settings the user set that are different from the default. while the ratconfig UI keeps rendering all settings and knows what is default, what is not, and lets you put any setting back to it's default value too

[nick-walt]

Probably a significant UX benefit of an integrated mux / terminal pair would be features that require communication of capability and state between the two.

It would be awesome if the terminal could define (perhaps in a profile) a multi-split tab or window that tells the mux (via selection or on connection) to load the requested layout such as what you're doing to create an IDE multi-pane experience.

The mux knows it is communicating with a specific terminal and visa versa. They don't have conflicting capabilities.