## Ideas

### Automation & Scripting

**Scripting and automation** — shell scripts that submit prompts, poll `state` until idle, then read `chat` for the result. No SDK, no HTTP client, just file I/O. Works in any language that can write to a file.

**Multiplexing sessions** — run several agents in parallel, each in their own session directory, and fan work out to them from a shell script. Coordinate by watching their `state` files.

**Hooks and watchers** — poll `state` in a loop to trigger actions when the agent finishes, or use `tail -f chat` to react to new output. Build lightweight event-driven pipelines with standard shell tools.

### Tooling & Integration

**Unix tools** — pipe `chat` into `grep`, `awk`, `sed`. Diff two sessions' outputs. Log conversations with `cp`. Search history across sessions with `grep -r`.

**Editor integration** — any editor that can read/write files gets agent access for free. In `acme` or `sam`, you write to `prompt` and read back `chat` with no plugin required. Fits naturally into the Plan 9 workflow.

**Lightweight TUI alternatives** — `watch cat state` as a status bar, `tail -f chat` in one pane, prompt submission in another. Compose a working interface entirely from standard tools.

### Multi-Agent Workflows

Two distinct patterns apply depending on whether work is delegated to ephemeral agents or distributed across persistent concurrent sessions.

#### Subagent delegation

For one-off focused tasks, use `subagent_spawn`. The parent spawns one or more jobs via the `b/` namespace, blocks until all complete, and reads the results. The subagents are ephemeral — they exist for the duration of one job and are torn down automatically. This is the right pattern for parallelising independent subtasks within a single workflow.

See `prompts/08_subagents.md` and `skills/session-management/SKILL.md` for usage.

#### Concurrent sessions

For workflows where multiple long-lived agents work in parallel and need to coordinate, the mechanism is direct prompt passing. Each agent is told its own session ID and its peers' IDs at startup. When an agent finishes a step and wants to hand off, it writes the result to another session's `prompt` — a plain file write from within `execute_code`. Writing to `prompt` queues by default, so a busy agent will not drop a message.

When a peer needs to read back the response it triggered, it polls the target session's `state` until idle, then reads `offset` and extracts the new output: `tail -c +$((offset+1)) s/$peer/chat`. The server sets `offset` to the byte position immediately after the user prompt is appended, so everything from that position to EOF is exactly the model response for that turn.

No external coordinator is needed after the initial kickoff. The agents themselves route work based on context in their prompts. A human can intervene at any time by writing to any session's `prompt`.

Each agent can use a different backend, model, or tool configuration. The boundary between fully automated and human-in-the-loop is just whether any agent's instructions include a step that asks before proceeding.

#### Predefined workflows

When the coordination logic is known in advance, a shell script can drive the entire workflow externally. Named sessions make routing unambiguous. The server updates `offset` to the byte position immediately after the user prompt is appended to chat. After the agent goes idle, `tail -c +$((offset+1))` yields exactly the model response for that turn.

```sh
#!/bin/sh
cwd=${1:?usage: $0 <cwd>}
cd ~/mnt/ollie

echo "name=developer agent=developer cwd=$cwd" > s/new
echo "name=reviewer  agent=reviewer  cwd=$cwd" > s/new
echo "name=tester    agent=tester    cwd=$cwd" > s/new

# Send a prompt and return the model response.
# The server sets offset after the user prompt is appended to chat;
# everything from offset to EOF is the model response for that turn.
send() {
    sid=$1; shift
    printf '%s' "$*" > s/$sid/prompt
    while [ "$(cat s/$sid/state)" = "idle" ]; do sleep 0.2; done
    while [ "$(cat s/$sid/state)" != "idle" ]; do sleep 1; done
    tail -c +$(($(cat s/$sid/offset) + 1)) s/$sid/chat
}

reply=$(send developer "Implement a function that parses a JSON config file.")

while true; do
    review=$(send reviewer "Review the following code. Reply LGTM if ready, or PTAL with feedback.

$reply")

    if ! printf '%s' "$review" | grep -qi "LGTM"; then
        reply=$(send developer "Revise based on this feedback:

$review")
        continue
    fi

    result=$(send tester "Test the following code. Reply Approved if all tests pass, or Rejected with details.

$reply")

    if printf '%s' "$result" | grep -qi "Approved"; then
        printf '%s\n' "$reply"
        break
    fi

    reply=$(send developer "Fix the following test failures:

$result")
done
```

The script is the coordinator; agents have no knowledge of each other. Information flow is fully explicit. A human can intervene by writing directly to any session's `prompt`.

### Self-Generating Workflows

Since agents have access to `execute_code`, a session can write and execute a workflow script without any human involvement. Given a task and knowledge of the filesystem layout, an agent can decompose the work, spawn sessions, write the coordination script, and run it — all in a single turn. The README you are reading is essentially its system prompt. Conductor functionality, for free.