·6 min read

Agent-First: How This Site Is Built for AI and Humans

Agent-First: How This Site Is Built for AI and Humans

The web is shifting. The next wave of visitors to your site won't be humans scrolling through a browser. They'll be agents — AI systems that fetch, parse, and synthesize information on behalf of people. When someone asks an LLM "what does Balázs think about AI regulation?" or "find me a good shakshuka recipe," the answer will come from an agent that reads your site, not a person who types your URL.

That's why I rewrote this site from scratch. Not because the old one was broken, but because the audience is changing. If agents are going to be the norm — and they will be — then it's worth making your corner of the web work for them.

Life Details Still Matter

I work in tech. I spend my days thinking about AI, compliance infrastructure, and decentralized identity. But I also care about getting a margherita pizza right. About the books I've read. About recipes that make a Tuesday evening feel worth it.

This site has all of it. Blog posts about AI regulation sit next to a shakshuka recipe and a list of 135 books I've read over the past three years. It's a personal site in the full sense — not just a professional portfolio, but a reflection of a person. The pizza dough recipe matters as much as the post about the EU AI Act.

And here's the thing: agents don't care about the distinction. An agent looking for a good pizza dough and an agent researching AI policy both need the same thing — structured, readable, well-organized content. Building for agents means building a better site for everyone, about everything.

Files All the Way Down

There is no database. No headless CMS. No vendor lock-in. The entire content layer is two things:

  • MDX files for blog posts and recipes (content/blog/ and content/recipes/)
  • JSON files for structured lists — books, tools, links (content/lists/)

That's the whole stack. Every post, every recipe, every book on my reading list is a plain text file in a Git repository. Any developer, any script, any AI agent can read them directly.

The frontend is Next.js 14 with Tailwind CSS. Server Components by default. No client JavaScript unless strictly needed. The whole thing deploys to Vercel from a git push.

Why flat files?

Because flat files are the most portable, most durable, most agent-friendly format there is.

  • No migration hell. Moving from one framework to another means copying a folder.
  • Git is your CMS. Every edit has a commit history. Every change is reviewable. Whether a human or an AI agent writes the content, the workflow is identical: branch, commit, merge.
  • AI agents can read them directly. An MDX file with YAML frontmatter is trivially parseable. An LLM doesn't need to authenticate with an API or navigate a GraphQL schema. It reads a file.

Zod validates everything

Every content type has a Zod schema. Blog posts require title, summary, and publishedAt. Recipes require the same plus optional fields for prep time, cook time, servings, and difficulty. If a field is wrong, the build fails. No silent corruption, no half-broken pages in production.

This matters for AI-assisted authoring. When Claude Code writes a new post, the schema catches mistakes at build time. It's a contract between the content and the site.

AI-Native by Design

This site was built and is maintained using Claude Code. Not as a gimmick, but as the primary development workflow. The features in this post — the unified search, the book imports, the theme system — were all built in conversation with an AI agent.

The project has a CLAUDE.md at the root that gives the agent full context: build commands, content system, theme conventions, navigation patterns, monorepo structure. When I ask Claude to add a feature or write content, it already knows how the project works. Think of it as an onboarding doc for a collaborator with a 200k context window that never forgets.

Git-Based Admin

The admin CMS works entirely through Git. Create a post? It opens a branch and a draft PR. Edit? It commits to the branch. Publish? It merges to main. The content lifecycle is just Git operations, legible to any tool — AI agents, CI pipelines, review bots — that understands files and commits.

Traditional SEO optimizes for Google's crawler. But we're entering the era of Generative Engine Optimization (GEO), where content needs to be understood by LLMs, not just indexed by spiders.

llms.txt

The site serves /llms.txt — a plaintext document that tells AI models who the author is, what the site covers, content quality standards, and attribution policies. It's the robots.txt for language models. When an AI is trying to understand this site, llms.txt gives it structured context without crawling every page.

Structured Data and Semantic HTML

JSON-LD is on every page. Blog posts have Article schema. Recipes have Recipe schema with prep time and ingredients. The homepage has Person schema. RSS at /rss.xml gives any subscriber — human or machine — a structured feed.

These aren't just SEO best practices. They're the building blocks of a web that AI can actually parse. A recipe with proper schema markup can be read by Google, by Perplexity, by ChatGPT, by any agent that knows what cookTime means.

Universal Search, Universal Context

Hit Cmd+K from any page and you get a command palette that searches across everything — blog posts, recipes, books — in a single fuzzy index. Each result shows a category badge (BLOG, RECIPE, BOOK) so you know what you're looking at.

It's a small detail, but it reflects a larger principle: all content should be findable from one place, with context. The same principle applies to agents. If something queries this site, it should find anything, and know what kind of content it is.

Why Bother?

Because agents will be the norm. Not in some distant future — it's happening now. People are already using AI to research, summarize, recommend, and discover. The sites that are natively readable by machines will be the ones that are visible, discoverable, and quotable in an agent-mediated world.

Building for this isn't hard. It's actually simpler. Fewer moving parts, fewer services, fewer things that break. Flat files. Structured data. Semantic markup. A CLAUDE.md for your AI collaborator and an llms.txt for AI visitors.

It just means thinking about a second audience. And then putting the same care into your site architecture that you'd put into a pizza dough — because the details matter, no matter who's reading.

share: