# Ank > A small, token-efficient coordination layer for long-running agentic coding work, keeping tasks, claims and architecture decisions in the repository behind one CLI. HTML version: https://sean.lamet.dekrow.com/work/ank/ - Period: 2026–present - Role: Designer and main developer - Status: Released - Stack: Rust, SQLite, Git, CLI, MCP - Source: https://github.com/haksolot/ank - Site: https://ank.dekrow.com/ ## Public figures - GitHub stars: 91 - Forks: 6 - Releases: 15 - npm downloads, last 30 days: 454 Read live from the GitHub and npm APIs on 2026-10-26, when this page was built. ## Problem Coding agents sharing one repository for hours need to know what they may take, what was decided about the files they touch, and when their work counts as finished. Left to a tracker and people's memory, two agents rewrite the same module, last week's decision is undone, and a task is done because the agent said so. And every line an agent reads to find its bearings costs tokens. I hit this running several agents at once, each in its own git worktree. ## What I built Ank is a small, token-efficient coordination layer for coding agents, not a project-management product. I designed the model and specification, and I own the implementation: a Rust workspace behind one CLI. Tasks and decisions are markdown files in `.ank/`, versioned with the code. A decision binds files through a scope glob, not a ticket. `ank claim` gives a task one holder and freezes its criterion by hash; `ank done` runs the verifiers itself and records a proof. Token-efficient is a number: `ank context`, the first command an agent runs, is capped at 8,000 characters, and on Ank's own repository, about 4.9 MB of `.ank/`, it returns 3.4 KB. > Figure: Constraints and work meet only through scope globs. The markdown files are the truth; the index is disposable. > > Two planes, constraints (ADRs and specs) and work (tasks), each point scope globs at the repository's files; that is their only link. A task goes through claim, which freezes its criterion by hash, then log while working, then done, which runs the declared verifiers and records a hashed proof. Underneath, the source of truth is markdown files in .ank/, versioned by git. A SQLite index is derived from those files and can be deleted at any time. Claims are git refs under refs/ank/claims, shared by every worktree of the repository. ## Where it stands Ank is released and open source under Apache-2.0, and it keeps evolving. Several developers use it to standardise their agentic development workflow, among them developers in my department at Safran Landing Systems and in other Safran entities. Version 0.9.0 shipped on 2026-10-02 with binaries for Linux, macOS and Windows: ```sh npm install -g @haksolot/ank npx skills add haksolot/ank ``` The loop and exit codes are specified; the storage format will change before 1.0. I use it on my own repositories, this portfolio included. **Design** - **Two planes, joined by scope.** Constraints (decisions, specifications) and work (tasks) are separate; `scope` globs are their only join, and `ank scope ` lists everything covering a file. - **Anchors, not walls.** Any file can be edited, but the frozen hashes live out of the editor's reach, so an edit becomes visible to `ank check` rather than effective. - **Refuse on state, never on identity.** There is no permission model. Ank refuses because a task is held, blocked or diverged, and every refusal names the command that resolves it. - **Human acts stay human.** Ratifying a decision (`ank accept`) is a signed commit on the default branch. Agents propose; they cannot ratify. `ank context` has two modes. Before a claim it orients: binding decisions and open tasks, one line each. After a claim it serves the held task's full criterion, the decisions matching its scope and the latest log entries. What does not fit is cut and named, with the command that reaches it. On this portfolio's corpus it returns 2.5 KB before a claim and 1.8 KB under one. It is deliberately not a tracker: no cycles, estimates, velocity or roadmap. Ank is developed with Ank, under the same loop. **Architecture** **Claims are git refs.** A claim is a ref under `refs/ank/claims/`, shared by every worktree of the repository, so parallel agents arbitrate through a compare-and-swap on the ref rather than through a server. A claim has a time-to-live that `ank log` renews, so a silent agent loses it. **SQLite is a cache, never the truth.** The CLI keeps an index next to the files with a content hash per file, compares on every read and reindexes what changed. `ank find` queries an FTS5 table in it. A missing or corrupt index is rebuilt silently: a cache that can refuse to work would be a source of truth in disguise. **Proofs record how they arrived.** A proof carries the hash of the verifier definition, of its output, the HEAD commit and the scoped files, and its route: run by Ank, attested from CI, or submitted by hand. **One binary, several surfaces.** A small core crate, then the CLI, an MCP server for clients without a shell, a TUI reader and an optional watcher. Exit codes are part of the contract: an agent branches on `4`, `6` or `8` without parsing prose. **Trade-offs** - **Local-first over a hosted service.** No server, account or network on the critical path. Across machines, coordination is only as fresh as the last push of the claim refs; I designed for several agents on one machine. - **Files as truth, an index for speed.** Two representations can disagree, so the index never wins. - **Rust.** One native binary per platform, SQLite compiled in, no interpreter to install on every agent machine. The npm package only carries the binary; outside Linux x64, macOS on Apple silicon and Windows x64, it points to `cargo install`. - **Not a security boundary.** Walls would mean permissions, accounts and a server, the product I set out not to build. Ank makes drift visible; it does not stop someone determined to cheat.