Ubiquitous Journal
So I’m Building a Documentation Registry for Agents
A structured, machine-readable directory of the technologies we actually use to build software.
There’s been an enormous amount of focus on prompts. Better system prompts. Longer prompts. Coding-agent prompts. “Act like a senior software engineer.” “Follow best practices.” “Think step by step.”
But none of those instructions magically give the agent the latest Better Auth documentation. They don’t tell it whether a Clerk integration changed last month. They don’t give it the current Vercel deployment configuration. They don’t guarantee it understands the latest Convex APIs. They don’t tell it which version of an SDK the project is actually using.
A brilliant prompt attached to incomplete or outdated technical knowledge is still incomplete. You cannot prompt missing information into existence.
The Idea Is Simple
Create a structured, machine-readable directory of the technologies we actually use to build software: authentication providers, databases, backend platforms, hosting companies, frontend frameworks, programming languages, AI providers, agent frameworks, payment systems, storage, email, testing, DevOps, observability, APIs. Everything.
Each technology gets a structured page containing the authoritative places an agent should look before it starts writing code — official documentation, API reference, framework integrations, GitHub repository, changelog, migration guides, supported runtimes, current SDK information, and relevant configuration documentation.
A Different Operating Model
Instead of telling the agent “figure out how Better Auth works,” the workflow becomes:
Identify Better Auth.
Retrieve the Better Auth registry entry.
Load the relevant first-party documentation.
Determine the installed version and framework.
Build against the actual documentation.
Verify the implementation.
That is a completely different operating model.
The Registry Isn't the Documentation
I don’t want to copy every company’s documentation and create another giant knowledge base that immediately goes stale. The registry is the routing layer. It tells the agent where authoritative information lives and how to retrieve the right information for the task.
Think of it like DNS for technical knowledge. The agent knows what it needs. The registry knows where the source of truth is. The documentation provider owns the actual knowledge.
Human-Readable and Agent-Readable
The public website can still be useful for developers — browse categories like authentication, databases, hosting, AI providers, frontend, backend, payments, testing, and DevOps, and see companies like Clerk, Better Auth, Supabase, Convex, Firebase, Vercel, Netlify, Cloudflare, Stripe, OpenAI, Anthropic, Gemini, Next.js, React, PostgreSQL, Prisma, Drizzle, Playwright, and GitHub.
But the more interesting part is the machine-readable layer. An agent could access endpoints like /api/providers/clerk, /api/categories/authentication, /api/search?q=nextjs+authentication, or simple agent-readable files such as /agent/vercel.txt, /agent/convex.txt, and /llms.txt. Now the documentation registry becomes infrastructure rather than just a website.
Documentation Should Become Infrastructure
For autonomous agents, documentation can become callable infrastructure. Structured. Versioned. Searchable. Machine-readable. Source-aware. Connected directly to agent workflows. Instead of trying to make the model memorize every SDK on Earth, give it reliable access to the source of truth when it needs it.
The model should reason. The documentation should provide the facts.