Writing
Selected thoughts on agents, memory, and building systems.
Agents need control planes, not just prompts
agents runtimeUseful agent products need sessions, lifecycle, events, tools, approvals, and recovery surfaces. Prompts are how we talk to agents; control planes are how we live with them.
Frontier labs and the retreat from consumer software
ai products consumerFrontier LLM companies increasingly resemble old computer companies: the software experience starts as the trademark, then gravity shifts toward platform, enterprise, and OS layers. When that happens, the most loved consumer products may come from startups that obsess over experience on top of the models, not from the labs themselves.
Harness engineering over model worship
agents systemsIn applied agent systems, capability depends less on the model alone than on the harness built around it. Tool integration, runtime environment, context packaging, retries, evaluation loops, session handling -- a better harness makes the same model dramatically more useful. This is a correction to the instinct that progress is mostly about swapping in a better model.
Public layer over private memory
publishing knowledgeA private knowledge system can serve as substrate for a public site without exposing the full corpus. The pattern: keep internal memory private, define what is publishable, derive a curated public layer. This avoids the false choice between keeping everything private and publishing raw notes. The private system becomes the upstream knowledge layer; the public site becomes a curated interface.
Structured control over prompting
agent control runtimeA useful shift in agent systems: moving from plain chat toward structured control over stateful sessions. Instead of treating an agent as "something you prompt", treat it as a session, a runtime object, something that can be resumed, steered, inspected, and automated. Once sessions become real runtime objects, lifecycle bugs become control-plane failures -- and reliability starts to matter differently.
Interface bridges over substrate
design adoptionSometimes the right move is not replacing the substrate, but changing the interface exposed on top of it. Object storage surfaced through file-like APIs. Knowledge graphs rendered as wiki pages. Agent runtimes wrapped in CLI. If a system is powerful but adoption is low, ask: should the substrate change, or does the interface need a better bridge?
Graph-mediated retrieval
retrieval structureA useful retrieval pattern: place a structural layer between raw data and final reasoning. Instead of sending an agent straight into raw files, give it a graph-like map first -- what exists, what connects, where to re-enter, what to read next. This reduces blind traversal and makes large knowledge bases navigable without loading everything into context.
Agent memory as both knowledge and runtime
memory agentsFile-based, explicit memory makes agent knowledge inspectable and portable. A useful pattern: raw sources, compiled wiki, schema rules. But agent memory is also a runtime problem -- thread history injection, session continuity, context correctness. A strong personal agent is model + memory substrate + maintenance loop, not just a smart chat endpoint.