lkn
/
ollie-9p
Archived
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs: expand intro with Plan 9 motivation and design philosophy

This commit is contained in:
Levi Neely 2026-07-17 22:39:46 +02:00
parent b23e2ec2dd
commit b49bbb099d
1 changed files with 4 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
README.md
View File

@ -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.