Kujo SSG

For teams that want deterministic builds, straightforward template overrides, and a transparent content pipeline.

Comment

Inspiration

I wanted Kujo SSG to generate extremely fast static sites, stay simple to work with, and fit the way software is being built now, with AI agents doing more of the work.

That means treating agents as first-class users.

The site structure, CLI, machine-readable context, and WebMCP support are all built around making it easier for agents to understand and interact with a site without scraping pages and guessing what everything does.

What it does

Kujo SSG is a static site generator built as part of the Kujo programming language ecosystem.

It turns structured content, templates, components, assets, and configuration into static websites that can be deployed almost anywhere.

It also gives those sites an agent-facing layer.

Kujo sites can expose functionality through WebMCP, publish llms.txt and other machine-readable context, and give AI clients a cleaner way to interact with a site than browser automation.

It can also be extended with things like themes, plugins, commerce, CMS functionality, and AI integrations while still producing static output.

How we built it

The Kujo SSG follows the same approach as the rest of the ecosystem: small pieces, explicit behavior, strong defaults, and composable tooling.

The build pipeline handles content discovery, routing, templates, rendering, assets, and final site generation.

Around that, I built support for reusable themes, plugins, site configuration, structured metadata, AI-readable documentation, and WebMCP.

WebMCP fit naturally because Kujo was already being built around structured interfaces for agents.

Instead of teaching an agent how to click around a website, the site can expose the actions directly.

Challenges we ran into

The main challenge was adding capability without losing the simplicity of a static site generator.

It is easy to keep adding features until you have basically rebuilt a dynamic framework with a static export step.

I wanted plugins, themes, commerce, AI integrations, and WebMCP to work around the static model instead of replacing it.

Agent interaction was another challenge.

Humans can look at a page and understand what buttons, forms, and navigation are supposed to do. Agents should not have to reverse-engineer that every time, wasting time and tokens on browser use.

WebMCP gives us a much cleaner way to expose that functionality directly.

Accomplishments that we're proud of

Kujo SSG has grown into more than a basic static site generator.

I've used it for real websites, documentation, content-heavy sites, commerce examples, plugin and theme systems, AI integrations, and WebMCP-enabled functionality.

It also works as part of the wider Kujo ecosystem instead of being a standalone tool.

That gives developers access to things like MCP, RAG, evaluation, observability, context management, specifications, validation, and other agent-focused tooling around the development process.

With WebMCP, the final website can now take part in that agent workflow too.

What we learned

A lot of value in building AI-native software comes from making software easier for agents to understand and operate.

Clear contracts are better than guessing, structured data is better than scraping, explicit tools are better than hoping an agent clicks the right thing and deterministic systems become more important as more of the development process becomes probabilistic.

Static sites work really well for that.

The final output is still just HTML, CSS, JavaScript, and assets, while the tooling around it can be much more capable.

What's next for Kujo SSG

I want WebMCP support to become a standard part of how Kujo sites expose functionality to agents.

That sits alongside llms.txt, MCP integrations, structured site metadata, and the rest of Kujo's agent tooling.

I'm also continuing to expand the SSG around commerce, CMS functionality, plugins, themes, reusable site kits, and AI workflows.

The goal is to make sites that are easy for humans to use and easy for agents to understand, modify, and interact with.

Static where static makes sense.

Agent-native where agents make sense.

Built With

Share this project:

Updates

Submission history