lkn
/
ollie
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

readme: de-duplicate 'it's just files' refrain

This commit is contained in:
Levi Neely 2026-04-15 17:31:57 +02:00
parent 4c9ef8fd03
commit 808ec5b296
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
README.md
View File

@ -81,21 +81,21 @@ git submodule update --remote
**Filesystem as interface** — if you know how to operate a filesystem, you know how to operate ollie. Any tool that reads and writes files — `ed`, `vim`, Python, `cat`, a shell script — 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`. The protocol surface is zero because the protocol *is* the filesystem.
**Simple front-ends** — A TUI reads `chat`, writes `prompt`, polls `state`. There is no protocol to implement.
**Crash resiliency** — Memory (`m/`) and plans (`pl/`) are written to persistent storage outside the session. If a session crashes or is killed mid-task, neither is lost — a fresh session picks up where the previous one left off.
**[Code execution tool](https://platform.claude.com/docs/en/agents-and-tools/tool-use/code-execution-tool)** — Anthropic describes code execution as "a foundational primitive for building high-performance agents." ollie takes that literally: `execute_code` is the base layer, and `execute_tool` and `execute_pipe` build directly on top of it. New capabilities are added by dropping a script into `t/` and a skill in `sk/` — the tools provide the capability, and the skill tells the agent when and how to use them.
**Radical transparency** — The rendered system prompt for any session is a plain file: `cat s/{id}/systemprompt` — the prompt the agent is actually running with, not a reconstruction. The prompt parts that compose it are readable in `p/`; the agent can read its own instructions but cannot modify them. The filesystem is the abstraction layer — you need only know how to read and write files.
**Radical transparency** — The rendered system prompt for any session is readable at `s/{id}/systemprompt` — the prompt the agent is actually running with, not a reconstruction. The prompt parts that compose it live in `p/`; the agent can read its own instructions but cannot modify them.
**Discoverability** — The filesystem is self-documenting. `ls s/{id}/` shows every control surface. `cat t/idx` and `cat sk/idx` show available tools and skills. When you forget the interface, `cat help` tells you.
**Discoverability** — `ls s/{id}/` shows every control surface. `cat t/idx` and `cat sk/idx` list available tools and skills. `cat help` explains the rest.
**Composability** — Agents can be composed by piping `reply` into another session's `prompt`. Tools can be composed via `execute_pipe`, chaining `execute_code` and `execute_tool` steps the same way Unix pipes chain programs. Both work because the interface is files.
**Composability** — Agents can be composed by piping `reply` into another session's `prompt`. Tools can be composed via `execute_pipe`, chaining `execute_code` and `execute_tool` steps the same way Unix pipes chain programs.
**Passive memory** — Every session's chat history is a plain file (`s/{id}/chat`). An agent doesn't need to actively decide what to remember — the full conversation is already there, searchable with `grep`. This also works across sessions: an agent can search another session's chat for answers to questions that have already been worked through, without the other agent needing to have stored anything explicitly.
**Passive memory** — Every session's chat history accumulates at `s/{id}/chat`, searchable with `grep`. An agent doesn't need to actively decide what to remember. This extends across sessions: an agent can search another session's chat for answers that have already been worked through.
**Sub-agents** — An agent can spin up new sessions by writing to `s/new`, prime each one with a prompt, and collect results by reading their `reply` or having them write back to the parent's `prompt` or `enqueue` endpoint. The mechanism is simple because sessions are just directories — creating and addressing them is ordinary file I/O. Coordination between sub-agents is not yet fully resolved, but the basic fan-out pattern works today.
**Sub-agents** — An agent can spin up new sessions by writing to `s/new`, prime each one with a prompt, and collect results by reading their `reply` or having them write back to the parent's `prompt` or `enqueue`. Coordination is not yet fully resolved, but the basic fan-out pattern works today.
## Credits