# Parallel Agents on a Shared Host

Running two agents on separate hosts means paying for two hosts and waiting for two cold starts. It also means the agents can't see each other's work because each one is operating in its own isolated copy of the codebase.

Shared hosts change both of those. When you place multiple agents on the same Modal host, they share a single filesystem and a single provisioning step. You get the parallelism without the cost or the coordination overhead.

This page walks through a concrete example of building a new authentication feature where one agent handles the implementation while a second writes tests against it in real time.

***

## The scenario

You need to add JWT-based authentication to a FastAPI app. It's a well-scoped feature, but it touches several layers: the user model, the auth middleware, the protected route logic, and the integration tests. Two agents can cover more ground simultaneously, and if they're sharing a filesystem, the test agent can test what the implementation agent is actively writing.

***

## Step 1: Launch the first agent on a new shared host

```bash
mng create impl-agent@auth-host.modal --new-host \
  --message "Implement JWT authentication for this FastAPI app. Start with the user model in app/models/, then build the auth middleware in app/auth/, then update the protected routes. I'll be running tests in parallel so keep the interfaces clean."
```

The first `mng create` call provisions the Modal host. The `--new-host` flag is what creates it, and future agents can join by referencing the same host name. `impl-agent` starts immediately.

***

## Step 2: Add a second agent to the same host

```bash
mng create test-agent@auth-host \
  --message "Write integration tests for the JWT authentication feature being built in this repo. Check app/auth/ and app/models/ to see what's being implemented and write tests alongside it. Focus on token issuance, validation, expiry, and protected route access."
```

With this command, the second `mng create` joins the already-running host. So both agents are now running on `auth-host`, sharing the same working directory.

***

## Step 3: Monitor both agents

`mng list` shows all agents and their current status:

```bash
mng list
# NAME          STATE     HOST        PROVIDER  HOST STATE
# impl-agent    RUNNING   auth-host   modal     RUNNING
# test-agent    RUNNING   auth-host   modal     RUNNING
```

Connect to either one independently to watch their work:

```bash
mng connect impl-agent   # watch the implementation
mng connect test-agent   # watch the tests being written
```

Detach from a session with the standard tmux prefix: `Ctrl+b d`.

***

## Step 4: Inspect shared state with `mng exec`

Because both agents share the same filesystem, you can run a single command to inspect the combined state of their work, so there's no need to connect to each one individually:

```bash
# See what files have changed across both agents' work
mng exec impl-agent "git status"

# Check test results
mng exec impl-agent "pytest app/tests/test_auth.py --tb=short"

# See recent commits from either agent
mng exec impl-agent "git log --oneline -10"
```

`mng exec` runs the command in the agent's `work_dir` on the host. Since both agents share that directory, it doesn't matter which agent name you use for these types of tasks.

***

## Step 5: Send course corrections to individual agents

If one agent goes off track, target it directly with `mng message`:

```bash
# The test agent is testing internals instead of the public interface
mng message test-agent "Focus on black-box integration tests only — test through the HTTP endpoints, not the internal auth functions directly."

# The impl agent is using a library you don't want
mng message impl-agent "Don't use python-jose — use PyJWT instead. It's already in requirements.txt."
```

Each agent has its own tmux session, so messages go only to the intended agent.

***

## Step 6: Clean up

When both agents are done, destroy them. When the last agent on a host is destroyed, the host is torn down automatically.

```bash
mng destroy impl-agent
mng destroy test-agent
```

***

## Why share a host instead of using separate ones?

**Cost.** A shared host is one Modal sandbox, not two. You pay for one set of resources and one container lifetime.

**Shared filesystem.** Agents see each other's changes immediately without any sync step. The test agent can test a function the implementation agent wrote five minutes ago.

**Faster second agent.** The second `mng create` skips provisioning entirely. The host is already running, so the agent starts in seconds.

The tradeoff is that agents on a shared host can interfere with each other if they edit the same files simultaneously. We recommend that you pick task decompositions where agents are working in different parts of the codebase, or use `mng message` to coordinate when they need to hand off.

***

## Full example, end to end

```bash
# 1. Launch the first agent and create the shared host
mng create impl-agent@auth-host.modal --new-host \
  --message "Implement JWT authentication: user model, auth middleware, protected routes."

# 2. Add the second agent to the same host
mng create test-agent@auth-host \
  --message "Write integration tests for the JWT auth feature being built alongside you."

# 3. Monitor status
mng list

# 4. Connect to each independently
mng connect impl-agent
mng connect test-agent

# 5. Inspect shared state
mng exec impl-agent "pytest app/tests/test_auth.py --tb=short"

# 6. Redirect if needed
mng message test-agent "Focus on HTTP-level tests, not internal function tests."

# 7. Clean up — host is destroyed when last agent is gone
mng destroy impl-agent
mng destroy test-agent
```