Documentation Is Part of the Product Now

I spent the last stretch rebuilding the Edgaze docs into something much closer to a proper documentation platform. The docs existed before, but they were mostly there because software is supposed to have docs. That was not good enough. Edgaze now has enough moving parts that unclear documentation starts becoming a product problem, especially around the places where people are making decisions with money, APIs, or production workflows. I have also become slightly obsessive about documenting the things platforms usually make you reverse engineer yourself. Every block in Workflow Studio now has its own reference page. Pricing is documented down to how an individual run is calculated. Failed runs, creator earnings, payout timing, refunds, chargebacks, payout thresholds, BYOK, version pinning, API behaviour, and the legal side all have explicit documentation. None of this is particularly glamorous, but ambiguity gets expensive very quickly. If a buyer is paying per workflow run, they should be able to understand what they are paying for before they press Run. If a creator is earning from those runs, they should know exactly how that money moves, when it becomes available, and what happens in edge cases. They should not have to start earning first and then discover the business model by opening a support ticket. A surprising number of marketplaces make this unnecessarily difficult. The headline revenue share looks simple, but then you start finding the details scattered between help pages, payout dashboards, terms, support responses, and whatever somebody said in a Discord channel six months ago. I do not want Edgaze to work like that. If there is a rule that affects somebody's workflow, money, or integration, the rule should be written down. There is another reason I cared about rebuilding the docs now, though, and it is probably the more interesting one. The audience for documentation is changing. Historically, docs were written for a developer sitting in front of a browser. They would search for an endpoint, read a few examples, copy some code, break something, come back to the docs, discover they had ignored a paragraph directly above the example, and continue with their day. That is still important. But now software is increasingly being used by systems that read documentation themselves. Every Edgaze documentation page can be opened directly in ChatGPT, Claude, or Perplexity. The same page can also be retrieved as raw Markdown by adding `.md` to the URL. That is intentional. Documentation should not only render nicely in a browser. It should be easy to consume programmatically and easy to hand to an AI system without scraping a pile of navigation, buttons, and page chrome first. The API documentation follows the same philosophy. The spec is generated from the same schemas the handlers use, which keeps the documentation much closer to the actual interface instead of maintaining a second, slowly decaying description of what the API supposedly does. Documentation drift is one of those boring problems that can waste absurd amounts of time. An API changes, someone forgets to update one page, and six months later a developer spends an afternoon debugging perfectly reasonable code against instructions that stopped being true three releases ago. Tying the documentation to the implementation removes a large class of that nonsense. But the biggest reason this matters is what is starting to happen above the API layer. Edgaze MCP is already live. I have not properly announced it yet, but an agent can already search the Edgaze marketplace, inspect workflows, run demos, pay for real executions, and follow the resulting run without a person manually operating the marketplace in between. That changes how I think about who the customer is. An agent is not only something you build inside a workflow anymore. It can be the thing discovering and buying the workflow. And if software agents are going to become customers, documentation becomes part of the machine interface. The agent needs to understand what a workflow accepts, what it returns, how pricing works, what an error means, whether a version is pinned, how an API behaves, and what assumptions it can safely make. Vague docs are annoying for a human. For an autonomous system, they can become a hard integration failure. This is why I think documentation is moving from being support material to being infrastructure. The website is for humans. The API is for software. The documentation increasingly sits between both. Humans need it to understand the platform before trusting it. Developers need it to build reliably against the platform. Agents need it to understand what they are allowed to do and how to do it correctly. That is a much higher bar than having a sidebar with a few tutorials. The goal is that nobody should have to message me to understand how Edgaze works. Not a creator. Not a developer. And, increasingly, not the customer with no pulse.