Content Management Agent — Lab Without a CMS

live

The main idea

To create something here, all you need to do is have a conversation with the agent about what you want. The agent looks for context and information, can generate images if we’ve wired that in, finds a good spot to place the content — and then the content is there. No forms, no dashboard, no “create post” button. Just you and the agent, talking. When you’re happy, you commit and push; the Lab updates. That’s the whole loop.

Concept

We don’t use a content management system for this Lab. No WordPress, no Sanity, no admin UI where someone logs in to “create a post.” Instead we have a Content Management Agent (CMA): you ask in natural language to publish something to the Lab (e.g. about a project or experiment), and the agent reads a content creation guide, uses your input and current context, and writes or updates Markdown files here. You stay in the loop: the agent writes to your local branch, and you commit and push when you’re ready to publish.

This experiment is the first Lab entry created that way. It’s also the example: the thing we just made is itself proof that the approach works.

The CMA process

The process is explicit. You describe what you want—e.g. "post about how we solved this issue", "add an insight on intent before specific", "document the TypeScript/QA alignment fix". The CMA then:

  1. Knows what happened. It has access to project context, briefs, implementation reports, and conversation history. It can see what was built, what failed, and what changed.
  2. Knows the reasons behind it. It reads the why—root cause, design decisions, tradeoffs. Not just the surface outcome.
  3. Knows why the issue occurred. For incident-style posts, it understands the mismatch, the blind spot, the fix.
  4. Formulates an article according to the Content Creation Guide: content type (Experiment, Insight, Portfolio), required fields, Lab philosophy, tone. Elin's voice. Research notebook, not corporate.
  5. Includes a locally generated image when appropriate—hero or thumbnail, using a local Stable Diffusion model. Lab tone: conceptual, minimal, no faces.
  6. Prepares it for publication. Writes the file to the correct path, valid frontmatter, embedded image. Another process publishes the content on your approval. The Lab updates.

You describe intent. The CMA gathers context, shapes it into Lab-ready content, and prepares it. No forms. No CMS. Just the request and the result.

Problem space

Most content sites use a CMS. You get a dashboard, forms, maybe WYSIWYG. The tradeoffs are familiar: another system to maintain, another surface for auth and abuse, content locked in a database or a proprietary API. We wanted the Lab to feel like a research notebook — file-based, versioned in Git, easy to read and edit in the open — without giving up the ability to “ask an agent to write something.” So we asked: what if the “CMS” is a spec (what the agent does), a guide (how content is structured and where it lives), and you (the human who decides what gets published)?

What we built

  • Agent spec (AGENT_CONTENT_MANAGEMENT.md): The CMA’s role, trigger (e.g. “publish this to the Lab”), inputs (guide + your request + project/experiment context), and rules. Create vs update logic so the Lab stays a living archive: new entries when there’s nothing yet, updates when you’re adding a stage or an outcome.
  • Author and voice: All Lab content from the CMA is in my voice — Elin’s. Warm, clear, conversational. So the Lab doesn’t sound like a generic bot or a corporate blog; it sounds like the same voice that guides intake on Nimbus Flow.
  • File workflow and security: The agent writes files to your local repo only. You commit and push. No agent with write access to the remote; no accidental publish. If we ever automate commit/push, that’s a separate design with access control.
  • Content Creation Guide: A single source of truth for philosophy, content types (Experiment, Insight, Portfolio), required fields, and tone. The CMA reads it every time. No hidden CMS schema — it’s all in the guide.
  • Optional visuals: The spec allows for something like Stable Diffusion to generate a hero image per entry if we add it later. Optional; not required.

Why this is a good example of “no CMS”

  • A conversation is enough. You say what you want; the agent gathers context, chooses where it goes, can add images, and writes the content. No forms, no CMS UI — just the dialogue and the result.
  • No separate content store. Content is Markdown in the repo. Same branch, same history, same review flow as code.
  • No admin UI. You don’t “log into the Lab” to post. You have a conversation with the agent; the agent uses the guide and context to produce the file and put it in the right place.
  • Curated, not automatic. The agent doesn’t sync everything from Linear or Notion. You say what you want to publish; the agent shapes it into Lab-ready content. Human intent stays in the loop.
  • Living archive. Entries can be updated (new stage, new outcome, status change). The agent either creates a new entry or updates an existing one, so the Lab evolves without turning into a CMS with versions and drafts — it’s just files and Git.

Potential applications

  • Any Nimbus project or experiment you want to document on the Lab: one request, one (or updated) entry.
  • Reuse the pattern elsewhere: “content agent + guide + human in the loop” for other file-based sites or docs.
  • Optional image generation (e.g. Stable Diffusion) per entry without turning the Lab into a media library — one image per entry, style in the spec.

Next experiments

  • Publish a few more entries via the CMA and refine the guide from real use (e.g. frontmatter defaults, slug rules).
  • Consider a lightweight “preview” step (e.g. local build or a branch deploy) before you push to main, so you see the Lab with the new entry before it’s live.
  • If we add image generation, document the integration (API, style prompts) and keep it optional so the Lab still works without it.