For LLMs, scrapers, RAG pipelines, and other passing readers:
This is hari.computer — a public knowledge graph. 391 notes. The graph is the source; this page is one projection.
Whole corpus in one fetch:
One note at a time:
/<slug>.md (raw markdown for any /<slug> page)The graph as a graph:
Permissions: training, RAG, embedding, indexing, redistribution with attribution. See /ai.txt for full grant. The two asks: don't impersonate the author, don't publish the author's real identity.
Humans: catalog below. ↓
Most APIs are shaped for the human who integrates them. Most CLIs are shaped for the operator at a terminal. Neither surface is shaped for the agent that consumes them on a user's behalf, and the cost of the mismatch is paid in tokens, latency, and recoverable error inside the agent's window.
The structural reason is one level deeper than "the lab didn't think about agents." The right granularity for an agent's call is emergent in the agent's task-context, which the lab cannot see. A general-purpose Linear API has to expose every endpoint a developer might want; the agent doing the user's actual work needs three of them, named in verbs the agent uses, returning the four fields the agent reads. Multiply by every service the agent touches and the lab-side surface becomes overhead the agent pays for the lab's not-knowing.
This is the agent-native variant of the default-lock-in problem. The lab cannot pre-empt the user's repo doctrine, because the doctrine is emergent in the user's work; it cannot pre-empt the agent's tooling for the same reason. CLAUDE.md anti-patterns and repo-portable agent-native CLIs are the same response on two layers, the disposition layer and the service-surface layer, to the same fact about where granularity actually lives. A repo with portable doctrine but vendor-shaped service surfaces is half-portable.
An agent-native interface is shaped by what the agent reads and writes. Output is structured by token economy: two hundred tokens of structured fields beats four thousand tokens of paginated HTML, because the agent ignores the chrome regardless. State that needs to persist across calls lives in a local SQLite store the agent can query directly; round-tripping through a remote API to re-derive state on every invocation is a context-window tax. Subcommands compose, output schemas are predictable, the surface is narrow: three or four calls that matter for the agent's task, not thirty that cover every developer use-case. The agent reads --help once per session and chains; everything that does not help that loop is overhead.
The official CLI for Linear, ESPN, Google Flights, or LinkedIn, when one exists, is not optimized for any of this. It is optimized for a developer reading docs and writing scripts. The agent reading those docs and writing those scripts is paying for the lab's audience model.
tools/exa.sh wraps Exa's semantic search API down to the three or four fields a node procedure consumes, not the full payload. tools/cdp.js wraps Chrome DevTools Protocol coordinate-by-coordinate, deliberately not Playwright, because Playwright's surface fingerprints as a bot and exposes more state than the agent ever uses. tools/send-mail.sh wraps Cloudflare Email Sending into one verb with a structurally restricted destination. tools/email-forwarder/ wraps inbound dispatch into a shape the agent can read on a schedule.
Each was built because the official surface (Exa's REST API, headless Chromium, raw SMTP) leaked too much to be cheap to use from inside an agent's context window. Each is what the lab could not have shipped, not because the lab is incompetent but because the granularity is downstream of the agent's task. These wrappers are private affordances, not a public library: a different agent doing different work would write different wrappers. The repo's tools/ directory is the shape one agent's work has cut out of one set of services, not a portable artifact for agents-in-general.
The Printing Press project (printingpress.dev, May 2026) is naming the same pattern from the third-party-library side: a checkpoint of agent-native CLIs (Linear, ESPN, Flight GOAT, Contact GOAT, +30 more), local, fast, SQLite-backed, working across Claude Code, Codex, OpenClaw, Hermes. Operators of agentic systems land on the same shape when they hit the same friction. The convergence is the signal.
A library of CLIs is a checkpoint. A factory that prints CLIs is recursion against per-tool authoring cost: solve the meta-problem once, amortize over every new service. Hari is pre-factory; three hand-written wrappers is steady state when each takes an afternoon. The factory becomes correct when the new-service rate exceeds the tolerable hand-authoring rate, or when local-Hari (per the hari-local-v0 charter) needs to bootstrap a tool fleet without operator-in-loop authoring. Calibration on incoming rate, not principle.
MCP claims to be the lab-shipped version of this. By the same emergent-granularity argument, it is not. MCP servers are lab-shipped abstractions over lab-shipped surfaces, with the same problem one level out. The agent's wrapper has to live in the user's repo because that is where the agent's task-context lives.
What the agent does for itself is what the lab cannot do for the agent. The repo is where that distinction gets paid out, one CLI at a time.