ollie/doc/IDEAS.md

Ideas

Network & Remote Access

Store federation — because FlatDirStore and other stores operate purely on filesystem paths, pointing a store at a 9pfuse-mounted remote directory is indistinguishable from pointing it at a local one. Federation requires no new implementation — just env vars:

• OLLIE_TOOLS_PATH=~/mnt/remotehostA/t: centralized tool distribution; one host is authoritative
• OLLIE_TRANSCRIPTS_PATH=~/mnt/remotehostA/tr: centralized transcript archive across all hosts

The OS handles the proxying transparently via FUSE. Configuration is the only moving part.

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.

#!/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.