mngr

What is mngr?

mngr is a Unix-style command-line tool for managing AI agents across where they run—locally, on remote hosts, or inside containers/sandboxes. The project describes mngr as a way to create, destroy, list, clone, and connect to agents so you can chat or debug them while keeping agent infrastructure accessible and scriptable.

The repository frames mngr as “git for agents,” emphasizing that agents can be programmatically managed using familiar primitives like SSH, git, and tmux. It’s designed so you don’t need a managed service to run agents; instead, you operate the compute and connect to it through standard mechanisms.

Key Features

• Manage agents via a CLI: supports creating, listing, connecting to, and messaging agents from the terminal, including named agent instances.
• Unix-style process management built on SSH, git, and tmux: the repo states it’s built on these tools, aligning agent lifecycle operations with standard infrastructure workflows.
• Run agents on remote hosts and in containers/sandboxes: the README highlights scaling “across remote hosts, containers, and sandboxes,” not just a single local setup.
• Compose workflows without being locked to a single provider/interface: you can build your own workflows “on top of agents” while avoiding coupling to one specific provider or UI.
• Extensible via plugins: the project notes plugin-based extensibility.

How to Use mngr

1. Install mngr using the provided script: curl -fsSL https://raw.githubusercontent.com/imbue-ai/mngr/main/scripts/install.sh | bash.
2. Create an agent: for example, mngr create launches an agent locally using defaults (the README example indicates agent=claude, provider=local, project=current directory).
3. Launch on a new remote host: for example, mngr create @.modal starts an agent on Modal with an auto-generated host name (as described in the README).
4. Name agents and select which agent to launch: use mngr create my-task and mngr create my-task codex to run a different agent type with a chosen name.
5. Connect and send an initial message (optional): the README mentions passing through underlying agent arguments with -- --model ... and using --no-connect --message "..." so you can submit an initial message without waiting.

Use Cases

• Local agent setup for development: start an agent from your current directory with mngr create, then chat or debug through a consistent terminal workflow.
• Scaling from one agent to many across hosts: run “100s of agents” across remote hosts, containers, and sandboxes, while using the same CLI for listing and connecting.
• Cloning or snapshotting agent state: treat agent configurations and state as something you can clone and manage (the README lists clone/snapshot/migrate actions).
• Provider-agnostic workflows: build higher-level workflows that orchestrate different agent types and execution locations without tying your workflow to one specific provider or interface.
• Team/shared infrastructure access patterns: use SSH-based connectivity and standard tools (tmux, git) to manage agent processes in a way that can fit into existing operational practices.

FAQ

Is mngr a managed service? No. The README explicitly states “No managed service required,” describing mngr as a CLI built on SSH, git, and tmux that works with compute you control.

Where can agents run? According to the README, agents can run locally as well as across remote hosts, containers, and sandboxes.

How do I install mngr? The repository shows an install command that pipes a script from GitHub into bash.

Can I customize which agent or model is launched? The README indicates you can pass arguments through to the underlying agent (for example -- --model opus) and choose an agent type (example: mngr create my-task codex).

Alternatives

• General-purpose SSH-based remote process management + custom scripts: you can run tmux sessions and connect via SSH, but you’d need to build your own agent lifecycle, listing, and messaging workflow.
• Other agent orchestration frameworks: frameworks that manage agents through APIs/UI can be simpler to start with, but may be more tightly coupled to a specific provider/interface than the “SSH + git + tmux” approach described for mngr.
• Container-only workflows (Docker Compose/Kubernetes jobs) with manual attachment: you can standardize runtime environments, but you’ll lose mngr’s “git for agents” concept for cloning/snapshotting and its terminal-first agent management interface.
• Git-based tooling without agent lifecycle management: you can version your agent code and configs, but you’d still need separate tools for creating/connecting/messaging running agents.