The coordination problem
Several agents can be useful in the same repository, but they can also act on different versions of the same file. Asking each one to negotiate locks, send status messages, and remember a coordination protocol adds another task to an already limited context window.
ostk moves that responsibility into a daemon associated with the project. Agents use familiar operations while the kernel handles write conflicts, records events, and applies the project’s governance. The model can concentrate on the work instead of maintaining the infrastructure around it.
Files are the durable state
The .ostk directory holds journals, work items, decisions, and agent records. In-memory registries are projections of that state. After a crash, the daemon can rebuild its view from the logs rather than depend on an agent remembering what happened.
The filesystem is also an interface. The optional virtual filesystem exposes agent status, work items, decisions, and journal events under paths that ordinary tools can inspect. Without a filesystem mount, the namespace API exposes the same layout.
The interesting boundary is the write
Optimistic concurrency lets agents do the expensive thinking before resolving a conflict at the point where a change is committed. That makes the write boundary central: operations need to pass through the governed tools for the kernel to coordinate them.
Journaling and trust are part of that boundary too. Events are recorded locally, journal epochs are sealed with signed envelopes, and signed governance determines the authority available to an agent. This is a project operating model built around recoverable state and inspectable decisions.