Add current architecture to evolution log

doc/evolution.md

@@ -1694,11 +1694,55 @@ architecture cleanup:
 - Linked [OptMem](https://github.com/VictorTaelin/OptMem) as the external
   persistent-memory implementation.
 
-## Phase 32: Architecture documentation caught up with the implementation
+## Phase 33: Current architecture overview (Aug 17)
 
-The documentation is now organized by responsibility: 9P, agent core,
-prompting, tools, toolsrv, remote execution, and virtfs. The architecture
-overview maps these documents instead of repeating their implementation
-sections. This is documentation maintenance, but it reflects a real design
-boundary: Ollie’s core remains the agent loop and filesystem contract, while
-capabilities and specialized state are integrated from outside.
+At this point the runtime has two services and one integration surface:
+
+```text
+9P clients
+    │
+    ▼
+olliesrv ── sessions, agents, prompts, history, backends
+    │
+    └─ authenticated 9P ── toolsrv ── registry, sandbox, processes
+                                       └─ executable or metadata-only tools
+```
+
+`olliesrv` owns the agent runtime. It constructs the `virtfs` tree, serves the Ollie namespace, manages
+sessions and agents, resolves prompts, calls model backends, maintains history,
+and runs the agent loop. Its internal session event bus is used for runtime observers; it is not an external API.
+
+`toolsrv` is a separate authenticated 9P service. It owns tool metadata and
+host-variant discovery, per-agent loading, command execution, process state,
+output limits, sandbox policy, and bypass approval. Tool execution is not an
+in-process agent capability. A session may use a local toolsrv or an SSH-forwarded
+remote toolsrv; the agent runtime remains local.
+
+The 9P namespace is the external integration surface. Clients create sessions
+and agents, write prompts, read chat, wait on state, feed observers, and issue
+control commands through files such as:
+
+```text
+session/new
+session/{sname}/agent/new
+session/{sname}/agent/{aname}/prompt
+session/{sname}/agent/{aname}/chat
+session/{sname}/agent/{aname}/statewait
+session/{sname}/agent/{aname}/feed
+session/{sname}/agent/{aname}/ctl
+generate
+```
+
+A request follows this path:
+
+```text
+client → 9P → olliesrv → agent loop → toolsrv → tool
+                     └──────────────→ backend
+```
+
+The client can be a shell command, editor integration, GUI, terminal, observer,
+or external workflow. The client supplies context and writes a prompt; Ollie
+supplies the runtime and 9P state surface. `virtfs` separates namespace
+declaration from 9P transport. Tool authoring, remote execution, prompting, and
+editor integration remain separate concerns documented by the focused
+architecture documents.