Instead of writing an article about how we created an agentic website for XYZ, we decided to ask it to introduce itself.
That choice is slightly theatrical, but it also makes the point faster. This website was built as a website: a site whose content, structure, knowledge layer, previews, and supporting automation all live in a form that AI can inspect and work on directly under clear constraints.
That distinction matters. A lot of website AI still looks like decoration. A chatbot floats in the corner, maybe a few pages are AI-generated, and the rest of the site still behaves like a brittle hand-maintained object. We wanted something more useful. The site started as a clone of our existing Hugo-based tryformation.com setup, which we already maintain in an agentic way, but the design itself started from a clean slate using imagery and an opinionated design prototype by our CEO, Ian Hannigan. From there we registered the domain with Cloudflare, asked Codex to set up the deployment flow through GitHub Actions, and pushed the first version of the site live in about four hours.
The Guard Rails
The are the reason this works without turning into chaos.
First, the site lives in a repository with a predictable structure. Pages, services, blog posts, navigation data, assets, and templates all have clear homes. That means AI is not guessing where things belong. It can inspect the current state, compare similar content, and make targeted changes instead of improvising across a vague CMS surface.
Second, the repository carries explicit instructions. We keep workflow rules close to the work so the system knows the content source of truth, the translation expectations, the asset rules, the validation commands, and the tone. In practice this matters more than many people expect. The difference between a useful AI collaborator and a messy one is often not the model itself. It is whether the operating constraints are clear enough to make good decisions repeatedly.
Third, we do not leave the output unbounded. The site is built through templates, generated knowledge, search indexes, and validation steps. So even when AI drafts copy or proposes structure, the result still has to fit the established system. That sharply reduces random drift. It also makes review easier because the output lands in inspectable files rather than disappearing into a SaaS interface somewhere.
Fourth, we are selective about where live intelligence belongs. The little helper on this site does not run as an unrestricted live LLM. We prepare its knowledge layer, we shape likely answers, and we keep the runtime behavior narrow enough to stay fast, predictable, and cheap. That is a guard rail too. Sometimes the right AI decision is to move more intelligence upstream into the production process instead of into the visitor-facing runtime.
The Content Production Flow
The production flow is where the website starts behaving less like a brochure and more like a working system.
We usually start from a practical need: a new service, a sharper explanation, a better landing page, a missing FAQ, a stronger article, or a new way for visitors to reach the right offer. From there, AI can inspect the current repository, understand how similar pages are structured, and draft new material directly in the same format the site already uses. That is how this site moved from first live version to something much richer over the following two weeks: more content, more features, tighter design, and a growing layer of useful detail instead of a long backlog waiting for developers.
Because the content lives in markdown, JSON, templates, and reusable assets, the system can do more than write a first draft. It can connect a page to the right navigation, generate follow-on knowledge for search and the site helper, create social preview material, and preserve internal consistency across the site. The work is not trapped in one editor window. It flows through the full website stack.
That also means improvements compound. A clearer service page improves the page itself, but it also improves internal search, the bot knowledge layer, linked content, and future editorial work because the better explanation is now part of the system. Once the site is structured this way, each good edit becomes reusable input for later edits.
The current site helper is part of this flow. We generate and curate knowledge before the visitor arrives. We use overrides where we want tighter answers. We cache work where nothing changed. We keep the whole thing connected to analytics so the site can tell us what people are actually asking, where the navigation fails, and which topics deserve stronger treatment. That creates a loop between content production and observed demand. The same pattern also helped us move fast on features. One example we are particularly happy with is the audio transcription experience. We went from idea to prototype in a day, then refined the UX until visitors could read along with the text being highlighted.
What This Changes For Editors
For editors, the biggest change is the drop in cost and effort across the whole workflow.
An editor can ask for a new article, a tighter headline, a more direct call to action, a new FAQ cluster, a campaign page, a search-oriented content pass, or a structural cleanup without starting from a blank page every time. AI can propose the first pass, compare it against the rest of the repo, and work inside the same patterns the site already uses. The editor stays in charge of judgment, but spends less time on repetitive assembly work.
That is especially useful when the job is not purely textual. Editors often need surrounding operational help: update internal links, keep formatting coherent, align the navigation, reuse an existing image, add the right metadata, or make sure the page also helps search and retrieval. A promptable website lets AI help with those tasks in one pass because the surrounding system is available to inspect.
There is also a speed benefit for ongoing maintenance. Websites drift because small jobs pile up. A few weak pages stay weak. An older article is still useful but badly linked. A service page no longer reflects how the offer is framed. The FAQ lags behind real conversations. In a promptable setup, those jobs become much cheaper to do, which means they are less likely to be postponed indefinitely.
Editors also do not need to become developers to benefit from this. Ian Hannigan is not a developer, and he did almost all of the work on this site. Not needing a development team in the loop for every content change, design iteration, or feature idea removes most of the friction that normally slows a website down. The value is not that everyone suddenly writes templates by hand. The value is that the website is stored in a form where AI can do precise implementation work on behalf of the editorial and design owner.
Why We Think This Matters
We built the XYZ website this way because we wanted the site itself to demonstrate the behind our services. If we are going to talk about agentic websites, promptable content systems, and AI-assisted editorial operations, the website should behave like one.
This site is a success story for us. We did not use AI to cut corners. We used it to raise the ceiling. It helped us deliver a modern layout that feels right for the brand, advanced search and retrieval, a strong internal knowledge layer, and a content workflow that would have been much heavier to build and maintain the old way.
We are also not treating the website as finished. We are constantly iterating on it because the friction is so low. New pages, sharper explanations, better navigation paths, stronger retrieval, and more targeted content can be added as soon as we see the need. At this point the site almost writes itself, not because humans disappeared, but because the system is set up to turn editorial intent into working output very quickly.
The practical difference is straightforward. The website itself is designed to work productively with AI. The result is a site that can move faster, explain itself better, and keep getting better as we use it.
If your website still behaves like a precious object that only changes through slow handoffs, there is a good chance the operating model is the real bottleneck. We can help build a promptable website around your content, your offers, and your editorial workflow so the site becomes easier to improve instead of harder.