Built a local AI ops platform where every feature is a plugin and Claude Code writes the plugins

I have a confession: I keep starting "automation projects" and abandoning them at the same point.

The pattern is always the same. I write a script that does One Useful Thing: fetch some news, summarise it, post a draft somewhere. Three weeks later I want to add a second destination, or a different source, or a new model provider. The original script has grown a // TODO: refactor comment, and the new thing requires touching six files I don't remember (which is even worse since most of the code is written by Claude/Codex now).

So this time I tried a different rule:

Every feature is a plugin. The core knows nothing about my domain. If adding a capability requires me to edit the host, the host is wrong.

The result is BFrost (could you let me know what you think about this name in the comment?), a worker-first local AI operations platform (I'm publishing today as a public preview (v0.1.0)). It's a small Node.js host that runs on your machine, schedules jobs, moves items between producers and consumers, calls local and remote LLMs and renders a live React dashboard. Everything else (news harvesting, publishing to X or WordPress (current provided as an untested example), Telegram delivery, model providers, assistant tools) is a worker you drop into a folder.

Below: what makes this different from "yet another agent framework" what I had to give up to keep the rule honest, and how a bundled Claude Code skill scaffolds new workers without ever editing the core.

The one rule

Most extensible tools start extensible and decay. Plugins get "first-class" features the core knows about. Feature flags accumulate. The plugin API quietly becomes "the things our most-used plugin happens to need."

BFrost's hard rule, written into the repo's contributing docs and a Claude Code skill:

src/ outside src/workers/    →  domain-free. Never names a worker.
web/src/ outside web/src/workers/   →  same.
workers/local/<id>/   →  where your stuff lives.

That single constraint forced every interesting decision in the project.

What "worker-first" looks like in practice

A worker is a folder with three things:

workers/local/my-mastodon-publisher/
├── worker.json          # the manifest - id, surfaces, settings, cron jobs
├── src/index.ts         # the backend module
└── dashboard.tsx        # optional - a runtime-loaded React tab

The manifest is the single source of truth. It declares the worker's id, the cron jobs it contributes to the scheduler, the settings forms the dashboard should render for it, any credentials it needs, and any dashboard surfaces it owns. The host reads it, mounts the worker, and stays out of the way.

The backend module exports a BackendWorkerModule (TypeScript or JavaScript, your call). The host compiles TypeScript on first load with esbuild and caches the result or by clicking the activate button, in the dashboard). There's no build step you run manually; you edit the file, save, and the next time the worker is enabled the host rebuilds it.

// workers/local/my-mastodon-publisher/src/index.ts
import {
  listItemsForConsumer,
  applyConsumerSuccess,
  applyConsumerFailure,
  openWorkerKv,
} from 'bfrost';

export const workerModule = {
  manifest: /* loaded from worker.json */,
  jobs: {
    'mastodon-publish': async ({ workerId }) => {
      const items = await listItemsForConsumer(workerId, {
        itemType: 'news.article',
        excludeAlreadyHandled: true,
      });
      for (const item of items) {
        try {
          const post = await publishToMastodon(item);
          await applyConsumerSuccess(workerId, item.id, {
            metadata: { postUrl: post.url, postedAt: new Date().toISOString() },
          });
        } catch (err) {
          await applyConsumerFailure(workerId, item.id, { reason: String(err) });
        }
      }
    },
  },
};

That's it. No registration boilerplate, no DI container, no "register this with the scheduler." The host already knows about this worker because its folder exists.

The Item Bus is just a typed queue

When the news worker scrapes an article and the X publisher posts it, what's happening between them?

The temptation is to wire them directly. Worker A imports worker B, calls a method, done. That's also exactly what I'm trying not to do - now A knows B exists, and adding a third consumer means editing A.

BFrost's answer is the Item Bus. The shared queue is generic, owned by core, and looks like this:

{
  "id": "itm_abc",
  "producerWorkerId": "core.news",
  "itemType": "news.article",
  "tags": ["ai", "tooling"],
  "payload": {
    "article": { "title": "...", "url": "..." },
    "source":  { "host": "...", "label": "..." }
  },
  "metadata": {
    "local.publisher.wordpress": {
      "publishedUrl": "https://example.com/posts/xyz",
      "publishedAt": "2026-05-17T10:30:00Z"
    }
  }
}

A producer writes payload. Each consumer reads payload, does its work, and writes back into its own namespace under metadata. Consumers never mutate each other's metadata. That single discipline lets you have five consumers of the same item type without any of them caring about the others.

Want to add Mastodon? Subscribe to news.article, write to metadata['local.mastodon-publisher'] when you post. Want to add BlueSky? Same shape, different folder. The news worker doesn't know either of you exist.

Dashboards that workers own

The dashboard is a React SPA. Built-in workers ship their UI under web/src/workers/builtin/<id>/dashboard.tsx. Local workers can ship dashboard.tsx inside their own folder; the host bundles it with esbuild (browser target, IIFE, React resolved to window.bfrost.React so we don't ship a duplicate copy), serves it from /api/workers/:id/dashboard.js, and the admin app loads it via a <script> tag at runtime.

The bundle calls window.bfrost.registerDashboardView({...}) with the surface ids it claims. The host cross-references those against the manifest, so a worker can't accidentally take over a tab it didn't declare. Toggle the worker off and its tab vanishes. Edit the TSX, refresh, the new bundle is served because the ETag is mtime-derived.

This means an end user can install a worker and immediately see its dashboard, with its own KPIs, its own forms, its own events - without me approving anything or merging any PR.

What I had to give up

This isn't free. Several things became harder so that the contract could stay honest:

1. No worker can call another worker directly. Cross-worker coordination goes through the Item Bus (async) only. The synchronous "services" interface is on the roadmap but deliberately deferred until a real use case demands it.
2. The core never imports worker code. Even the bundled news, X publisher, and research workers live in src/workers/builtin/ and are loaded through the same registry path as any local worker. They prove the contract is expressive enough; they aren't load-bearing for the host.
3. No worker marketplace. Workers load from local disk only. No remote fetching, no signed worker bundles from the internet. v1.0 will get a permission/sandbox model first.
4. No magic on either side. No decorators, no reflection, no class hierarchies. A worker is a folder with a manifest and an exported object. If you can read TypeScript, you can read every line of how a worker is wired.

The payoff: I can read BFrost end-to-end in an afternoon. So can you. So can a Claude Code agent.

Claude Code writes the workers

This is the part that surprised me.

I bundled a Claude Code skill - bfrost-worker-author - inside the repo at .claude/skills/. When you run claude in a BFrost checkout and ask "create a new BFrost worker," the skill activates. It knows the worker contract, the file layout, the hard rules ("never edit the core"), and the order of operations (pick id → scaffold folder → declare surfaces → write tests).

A real session looks like:

> Add a BFrost worker that consumes news.article items and posts them
> to my Mastodon instance. I'll set the access token at runtime.

[Claude] I'll scaffold local.mastodon-publisher as a local worker under
workers/local/. Confirming a few things first:

  - Producer or consumer? → consumer of news.article
  - Credentials? → secret-reference field for the access token
  - Dashboard tab? → config-tab settings only (no custom tab)
  - Built-in or local? → local

Proceeding to scaffold...

Three minutes later there's a working worker. It reads news.article items, posts them, writes back into its metadata namespace, exposes a settings form, and ships with a README.md describing what it produces and consumes. The skill physically refuses to edit the core - if a request would require it, Claude stops and surfaces "this looks like a contract gap, here's what I think the core needs."

The whole reason this works is that the contract is small and stable. The skill isn't smart; the rules are simple enough that following them produces correct code.

What's in v0.1.0

Worth being honest about state. Today, v0.1.0 ships:

• ✅ The full worker-first contract (manifest, lifecycle hooks, dashboard bundles, item bus, per-worker storage).
• ✅ Built-in reference workers: news harvester, X publisher, research notes, Telegram channel, LM Studio provider, plus assistant-tool workers (memory, Google search, article fetch).
• ✅ Local TypeScript workers with compile-on-load (esbuild).
• ✅ A typed bfrost SDK that workers import from - the host registers it as a synthetic module so a worker can't accidentally bundle a duplicate copy.
• ✅ The Claude Code skill.
• ✅ A real-world example: workers/examples/wordpress-publisher/ consumes news items and publishes them to a self-hosted WordPress via the REST API. Copy it, configure it, run it.

What's deferred to v1.0:

• 🔜 A permissioned action runtime - formal approval queue + per-worker filesystem/network/credential scopes. Until this lands, keep destructive workers narrow.
• 🔜 Frontend smoke tests, per-worker metrics in the dashboard, an accessibility pass.
• 🔜 A hosted docs site and a Worker Gallery in the dashboard.

The browsable docs already live at https://convertprivately.com/bfrost/ - getting started, architecture, example workers, and authoring with Claude Code, all four pages.

Try it

git clone https://github.com/ccascio/BFrost.git
cd BFrost
npm install
npm run dev          # host + admin API
npm run dev:web      # dashboard at http://localhost:5173

Then either copy workers/examples/wordpress-publisher into workers/local/, or run claude from the repo root and ask it to scaffold a worker for whatever you actually want to automate. Star the repo if you like the direction, open an issue if you don't - the worker-proposal template is set up specifically for "I want to extend BFrost with X."

Why I'm publishing this now

The honest answer: because I've shipped the project past its own bar twice and held it back both times for "one more polish pass." Workstream 5 (the permission runtime) genuinely matters for v1.0 - workers that touch the real world need approval gates. But v0.1.0 is for people who want to read the code, copy an example, and tell me where the contract breaks.

If you build a worker, drop a link in the comments. If the contract doesn't fit your case, I want to know - that's a roadmap item, not a defect in your worker.

Repo: https://github.com/ccascio/BFrost
Docs: https://convertprivately.com/bfrost/
About me: https://convertprivately.com/about/