Giant Context does a great deal of work no one is waiting on. Pages that take minutes to build, sites to crawl and import, its own recurring maintenance. None of it fits in a web request, so I stopped treating a job as a call and started treating it as a record. A row in a Postgres table, claimed with FOR UPDATE SKIP LOCKED, retried in the same row, and broken into a graph of dependent tasks. Fire-and-forget is a way of losing work without ever finding out.
Giant Context builds your website out of your own files, and it keeps editing it afterwards. Every page remembers the files it was built from, so when you update a price in a document, changing the source turns up every page that used it. Those pages are edited to the new number and land in your queue for approval. You maintain your files. The site follows.
I did not write the MCP tools an agent calls. Each route declares in its own schema that it wants to be a tool, what to tell a model about it, and whether a call can overwrite. The MCP server reads a filtered copy of the API's OpenAPI schema and assembles the tools from it, and I have never updated the service.
Not just a website. Your emails, your help articles, your blog posts and your pages, out of one system that reads what your business is and works out what it is missing. The value is in the noticing. A business produces the evidence for these decisions constantly, in its own documents, its published pages, the questions its customers ask, and reading all of it every week is more than anyone has time for. Mind reads all of it every time it runs, and everything it makes arrives finished and waiting on your approval.
An agent writes most of the code in Giant Context and deploys it to production, which only works because no single check is trusted alone. Eleven of them sit one behind another, each with a hole I can name, and a failure has to find a hole in all eleven at the same time. Nothing here is asked to be perfect. It is asked to fail differently from the layer beside it.
Production throws an error and the hour before the fix is the expensive part, the reproduce, the search, the reconstruction. Brain files each one as a triaged issue, resolves the stack trace back to the file that threw, and returns a root cause, a fix diff, and every step it took. Errors were the first place I pointed the platform's own intelligence, because a wrong answer would be obvious to me.
Brand consistency slips because most tools keep the brand in many places and copies drift. Here a brand is one row, and a block stores the token primary rather than a hex, so changing the brand recolours every page without touching one. Includes what reads it at render, why fonts are self-hosted, and the three briefs the AI works from.
Most software does not need this. Three roles and one boundary is cheaper and enough for teams working on shared material. The business case here names a different buyer, an agency running a roster of clients inside one account, where the tenant boundary sits around all of them at once and the separation has to be built underneath it.
A customer deletes their homepage and it vanishes from their site, but it is not gone. Every deletable entity is serialized whole into one trash table with a thirty-day clock, restorable exactly as it was, and only a scheduled purge job destroys anything. Build the trash before the delete button.
A month ago I shipped the thing this company was built to do, a customer describing their business and getting a real editable website back. Getting it to work taught me the most important lesson I know about building with language models. A prompt does not design a website. A process does, and building the process meant learning the craft I built the machine to spare me.