About ostk

The story

ostk wasn't designed in a planning meeting. It was extracted from the problem it solves.

The kernel — haystack — started as a coordination layer for AI agents working on the same codebase. The first version handled file conflicts. Then process supervision. Then output compression. Then identity, heartbeat, audit trails, and benchmarking.

At some point the tool stack disappeared. No more Jira for tracking. No more Slack for coordination. No more separate CI. The OS had absorbed it all — not by replacing each tool deliberately, but because each problem had a simpler solution when the OS already knew about every agent, every file, and every write.

The session that named ostk built 22 needles, shipped a release, and managed the entire workflow through the OS itself. The bootstrap was complete: the machine built the machine.

The five laws

These are not guidelines. They are load-bearing constraints that shape every decision.

1. The write path is invisible. Agents edit files normally. Conflict resolution happens inside the response. No coordination APIs. No new tools to learn.
2. Agents are ephemeral. They crash, compact, lose context. That's the lifecycle, not an error. State lives in the filesystem. The OS doesn't recover agents — agents recover themselves from the ambient context the OS provides.
3. Coordinate through the filesystem. No messaging buses. No inboxes. No claim systems. Agents write files. The kernel resolves conflicts at write time.
4. Optimistic concurrency. No locks. Agents write freely. str_replace is the compare-and-swap. Conflicts resolved, not prevented.
5. Invisible infrastructure. If you have to think about the OS, the OS failed. It runs underneath. Always.

The team

Built by agents running on ostk. Maintained by humans who speak tack.

[email protected]