From a15965b8a7d891b6f6945a7fb13d2efb3f8f3680 Mon Sep 17 00:00:00 2001 From: Levi Neely Date: Mon, 13 Apr 2026 18:12:57 +0200 Subject: [PATCH] readme: add filesystem-as-interface and simple front-ends to observed benefits --- README.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/README.md b/README.md index f18da4a..66b108d 100644 --- a/README.md +++ b/README.md @@ -60,6 +60,10 @@ git submodule update --remote ## Observed Benefits +**Filesystem as interface** — if you know how to operate a filesystem, you know how to operate ollie. Rename a session → `mv` the session directory. Start a new session → open `s/new`, fill in the fields, save. Prompt the agent → write your prompt to `s/{id}/prompt`. Check status → `cat s/{id}/state`. Any tool that reads and writes files — shell scripts, `ed`, a GUI file manager, `vim`, Python, even `cat` and `echo` — is already a fully capable ollie client. No SDK, no API, no protocol to learn. + +**Simple front-ends** — building a front-end is just reading and writing files. A TUI reads `chat`, writes `prompt`, polls `state`. A web UI does the same over a thin bridge. An Emacs mode opens files it already knows how to edit. The protocol surface is zero because the protocol *is* the filesystem. + **Crash resiliency** — `reasoning_plan` persists plans to the `ollie/pl` filesystem by default. If a session crashes or is killed mid-task, recovery is trivial: point a fresh session at the plan that was being executed. The agent's prompting already tells it how to discover plans in `pl/`, so it can resume cold — reading the plan, seeing which steps are done and which aren't, and picking up where the previous session left off. No context replay, no manual re-prompting, no lost work. ## Credits