What I built around Pi
I extended Pi’s open-source agent runtime into a Windows personal assistant: a React/Tauri application, CLI, Chrome extension, typed tools, persistent SQLite state, and hybrid retrieval over personal knowledge. Pi supplies the agent foundation; my work connects it to the interfaces, memory, tools, and lifecycle of the product.
Keeping the assistant consistent across interfaces
Kora can be used from a Tauri desktop application, a command-line interface, and a Chrome extension. Each surface has a different interaction model, but the underlying work—retrieving context, selecting tools, updating state, and resuming a session—must stay consistent.
Putting a separate agent loop inside every interface would have made each surface easy to start and difficult to trust. Tool behavior, prompts, memory rules, and session state would drift as soon as one client changed faster than the others.
The boundary I chose
The interfaces request work and render events. The runtime owns session control, tool and skill execution, context retrieval, and durable state. SQLite and local files keep persistent context on the user’s machine; configured model providers receive the context needed for an inference request.
What the design improves
- Continuity: a session can be resumed without teaching each interface its own memory model.
- Inspectability: one owner records tool activity, retrieved context, and durable state.
- Consistency: tools and skills behave the same way regardless of where a request begins.
- Evaluation: retrieval and safety behavior can be tested below the interface layer with repeatable fixtures.
What the design makes harder
A shared runtime creates a real contract between clients and the system underneath them. Events need stable shapes. The browser extension cannot depend on desktop-only internals. Packaging, local process management, recovery, and version compatibility become product problems rather than details hidden inside one application.
Local-first storage also improves user control while making cross-device synchronization more difficult. I chose that tradeoff deliberately: Kora’s default responsibility is to the user’s machine and context, not to a hosted account.
How I check the boundary
I built an evaluation harness around changing workweek scenarios: delayed information, revised plans, simulated-user interactions, controlled event timing, and fresh sessions after restarts. It inspects task completion, retained memory, authorization boundaries, and recovery alongside the conversation.
The harness is under development. Retained pilots exercise Kora itself, with separate simulated-user and blinded-review roles; cross-agent comparisons and final qualification remain future work. The useful result is a trace of what the assistant actually did and where its behavior needs improvement.