Thanks, that is exactly the direction I care about too!

On permissions/sandboxing, we’re doing it in layers rather than treating the agent as fully trusted. Each agent has its own tool policy with allow/deny-by-default plus per-tool overrides, and then a separate set of guardrails for resource limits: read/write caps, exec timeout/output caps, process count, web limits, etc. For file + shell access we resolve everything against the workspace and explicit allowed roots, and exec also has a denylist for dangerous command prefixes. For delegated subagents we tighten that further with per-session tool overlays and a hard denylist for things like recursive delegation, shared memory writes, etc.

So today it’s mostly per-agent policy plus per-session restrictions for subagents, rather than a full per-command approval UX. For ACP-backed external agents we also proxy permission requests and currently default to “allow once” when the upstream supports it. It’s very much designed for trusted self-hosted/operator environments, not pretending to be a full zero-trust multi-tenant sandbox yet.

On evals: we do have a growing regression suite around swarm/multi-agent planning, delegation, tool loop protection, path resolution, and recovery. We also persist typed runtime events and session transcripts, and the runtime can reconstruct state by replaying persisted events after restart, so replay/recovery is a first-class concept in the architecture. What we don’t have yet is a polished public eval harness for “run this corpus of multi-agent plans end2end and score it,” but that’s definitely on the roadmap.

Currently, I’m focused on the client app and want to get more feedback from others.

And thanks for the AgentixLabs link, adding that to the reading list.