ollie/doc/IDEAS.md

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.

Network & Remote Access

Remote access — 9P is a network protocol. Export the namespace over the network and access agent sessions from another machine using the same file interface, with no additional daemon or API layer.

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.

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.

Example: develop → review → test

A kickoff script spawns three sessions and seeds the developer with the task and all three session IDs. From that point the agents coordinate themselves.

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

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

# Read the three new session IDs from the index.
dev=$(tail -3 s/idx | awk 'NR==1{print $1}')
rev=$(tail -3 s/idx | awk 'NR==2{print $1}')
tst=$(tail -3 s/idx | awk 'NR==3{print $1}')

cat <<EOF > s/$dev/prompt
Implement a function that parses a JSON config file.

When your implementation is ready, send it to the reviewer:
  echo "<your code>" > $OLLIE/s/$rev/prompt
Tell the reviewer to reply to s/$dev/prompt if revision is needed,
or to forward to s/$tst/prompt with a reply path of s/$dev/prompt if approved.
EOF

The reviewer's system prompt instructs it to end with LGTM and forward to the tester, or send feedback back to the developer. The tester's prompt instructs it to send Approved or failure details back to the developer. The loop runs entirely within the agents — no polling, no external coordinator.

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 script captures a chat offset before each prompt submission, waits for the agent to finish, and reads only the new output — no reply file needed.

#!/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 to a session and return only the new output.
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
    offset=$(cat s/$sid/offset)
    tail -c +$((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.

Persistent Memory

Memory Recall — Agent sessions are ephemeral by nature, but some knowledge should outlive them. Memory recall gives an agent the ability to persist and retrieve facts across sessions via two abstract tool contracts: memory_remember and memory_recall. When the agent learns something worth keeping — a user preference, an architectural decision, a hard-won debugging insight — it calls memory_remember with a concise, self-authored summary. On a future session it calls memory_recall to retrieve relevant memories before reasoning. Memories are LLM-generated rather than raw chat logs: the agent decides what matters and phrases it canonically, so memories remain meaningful long after the conversation that produced them is gone. The tool contract follows the same pattern as reasoning_plan: the agent owns the content, the tool owns the storage.