readme: add filesystem-as-interface and simple front-ends to observed benefits

This commit is contained in:
Levi Neely 2026-04-13 18:12:57 +02:00
parent 8b55fc3895
commit a15965b8a7
1 changed files with 4 additions and 0 deletions

View File

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