DIAGNOSIS // 01

Why ostk

ostk is a modular, local-first-by-custody runtime that connects supported agent surfaces to project state you control. Three common failure modes appear as agent work scales.

You're using AI agents to code. ostk addresses collision, context drift, and missing trace through a decoupled stack whose guarantees apply at explicit integration boundaries.

PROBLEM_01 // COLLISION

They collide.

Two agents edit the same file. One finishes a second after the other. Whose version wins is whoever wrote last — silently overwriting files. The first agent's work is lost, and the system fails silently.

Modular Solution: fs_ops CAS edits declare the text an agent expects. If current content differs, ostk can auto-merge a safe non-overlapping change, return a suggested merge, or fail visibly for review. Native client and raw-shell writes remain outside that CAS contract.

Handled by: ostk daemon & libostk IPC client.

PROBLEM_02 // DRIFT

They drift.

Each agent session runs in its own context window. They re-discover codebase details. They forget previous decisions. They don't see concurrent actions, forcing you to manually copy and paste context across chats.

Modular Solution: ostk-recall can incrementally index configured workspace and transcript formats into a local hybrid search corpus. A supported client can retrieve that evidence through MCP; indexing and retrieval improve orientation but do not make every harness transcript or decision automatically visible.

Handled by: ostk-recall MCP server with local embeddings.

PROBLEM_03 // NO_TRACE

They leave no trace.

Something went wrong. There's no auditable record of what prompt generated a command, what files were read, or who authorized the action. Security reviews stall because proprietary binary wrappers hide agent execution.

Modular Solution: Kernel-mediated dispatches append structured rows to a local, hash-chained journal. Rows are Ed25519-signed when a signing key is available, and the open client/kernel code lets operators inspect that path. Native client actions and external-service behavior require their own audit evidence.

Handled by: the kernel journal and libostk client path; GPG release/governance signatures are a separate trust layer.

THE_SHAPE

A decoupled, open-source stack. Adopt only what you need.

ostk is built as a set of modular components. You don't have to adopt the full suite. You can drop in ostk-cache to save tokens immediately, connect ostk-recall as an MCP server to add memory to Cursor, or build custom integrations against the permissive MIT-licensed libostk.

Choose your onboarding path:

→Explore the modular architecture comparison on our Stack Page.
→Read how the userspace client links applications at libostk Reference.
→Install the full CLI daemon for complete integration via Quick Start.

WHAT_YOU_GIVE_UP

The trade-offs the rest of the page didn't lead with.

A learning curve. The vocabulary — humanfile, agentfile, pin caps, needles, tack — takes a session or two to internalize. The five-minute start covers the floor; the kernel spec covers the ceiling.

A daemon process. ostk runs a background daemon per project. Memory cost depends on what's loaded — a baseline daemon is tens of MB; with embeddings resident it can be hundreds. Use ostk daemon restart to swap a rebuilt binary in cleanly; pkill -f "ostk daemon" if you just want it gone.

A directory you can't ignore. .ostk/ is the substrate. Lose it and you lose the audit chain (the project still works — you just lose history). Back it up like you'd back up .git/.

A small state footprint. Per-project state in .ostk/; per-machine state in ~/.local/share/ostk/ and ~/.cache/ostk/. Nothing else.

→ START_HERE

Pick an onboarding path. Install the daemon or adopt components.

→ THE_STACK

Review the decoupled components and licensing layout.