From b49bbb099dccf219d470005f6aea7dee2440ac1d Mon Sep 17 00:00:00 2001
From: Levi Neely <141506390+lneely@users.noreply.github.com>
Date: Fri, 17 Jul 2026 22:39:46 +0200
Subject: [PATCH] docs: expand intro with Plan 9 motivation and design
 philosophy

---
 README.md | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/README.md b/README.md
index 828e082..f095aec 100644
--- a/README.md
+++ b/README.md
@@ -1,8 +1,10 @@
 # olliesrv
 
-A 9P server that exposes [ollie](https://github.com/lneely/ollie) agent sessions as a virtual filesystem. Mount it with `9pfuse` and interact with AI sessions using ordinary shell tools.
+Ollie starts from a simple, slightly silly question: *What might an AI agent look like in [Plan 9](https://www.usenix.org/legacy/publications/compsystems/1995/sum_pike.pdf)?* From there follow two more: *What happens if agent primitives are exposed as an ordinary filesystem?* and *How much can we subtract from agent implementations while still being useful?*
 
-The goal is integration, not self-sufficiency. Rather than providing orchestration, scheduling, or workflow primitives, olliesrv exposes a stable surface — sessions as directories, conversation as files — and defers everything else to the surrounding environment. Scripting, chaining, monitoring, and automation come from composing olliesrv with tools that already exist, not from building those capabilities into the server.
+`olliesrv` is the answer: a [9P](http://9p.cat-v.org) server that defines what an agent is, then exposes its state and behaviors as regular files and I/O streams. Sessions are directories, conversation is a file you `tail -f`, prompts are writes, tools are executables. Mount it with `9pfuse` and interact with AI sessions using ordinary shell tools — the same primitives scale from simple copilot use cases (`u/complete` manages a session per working directory for ghost-text code completion in [acme](http://acme.cat-v.org)) through interactive shells and one-shot pipelines, up to multi-agent workflows coordinated by scripts, other agents, or both.
+
+The goal is integration, not self-sufficiency. Rather than providing orchestration, scheduling, or workflow primitives, olliesrv exposes a stable surface and defers everything else to the surrounding environment (shell scripts, TUIs, web apps, cron, containers, and other OS facilities). Scripting, chaining, monitoring, and automation come from composing olliesrv with tools that already exist, not from building those capabilities into the server.
 
 For usage examples, see [doc/USAGE.md](https://github.com/lneely/ollie/blob/main/doc/USAGE.md) in the monorepo.