1. Home
2. Technical Writing
3. Company of Zero

Company of Zero: How AnimaMesh Runs a Company's Back Office on Cloudflare Workers

By Jack Jin · August 15, 2026 · Updated October 4, 2026 · 14 min read · Includes my 11:09 video

AnimaMesh is an open source engine where AI agents do a company's back office on Cloudflare Workers and the human only approves. One public engine holds all the code, and each company gets a private brain of markdown with zero lines of code. Part by part, with the code behind each: decoupled beats where one agent can fail without stopping the rest, read-only reach into SharePoint, a brain that files its own GitHub issues past a leak guard, and AI that reaches out to the owner instead of waiting for a prompt. It started as my AI Tinkerers Columbus talk on August 3, 2026.

I follow the order of the talk. Every part links to its moment in the recorded version if you'd rather watch.

Letting one founder run more than one company

The dream of this project is to let founders start more than one company. As people, we're still liable for the LLC, the C Corp or the S Corp. But so much of what keeps a company running is preparable work: the compliance calendar, bookkeeping prep, keeping documents in order, governance, research. How much of that can run agentically, with the human as the approval gate?

One founder running seven companies is a thought experiment for now. The project started from two simple requirements:

1. All of the company's knowledge lives in markdown files. The format I picked is Google's Open Knowledge Format (OKF): one concept per file, YAML frontmatter on top, and links between files that turn them into a graph an agent can read.
2. AI reaches out to the owners, instead of the owners reaching out to AI.

With those two, I set out to build what I presented at AI Tinkerers.

Watch this part 0:00 The company of zero dream

One public engine, many private brains

The first idea is the split. The engine is where all the code is. It's a public GitHub repository that anyone can use, and it never names a company, a person or a persona. The brain is the real knowledge: one company, in a private repository, with zero lines of code. Just markdown and a little JSON for configuration.

The dependency only goes one way. The brain picks an engine version by git tag, so if your brain isn't ready to upgrade to the latest AnimaMesh, it doesn't have to. The engine never knows the brain exists. That's how one engine can power many companies. The whole coupling is a few lines in the brain's config:

  "engine": {
    "repo": "github.com/jackzhaojin/anima-mesh",
    "ref": "v0.12.0",
    "localPath": "../.."
  },

The brain also decides its own staff. Because the agents are data and not code, the brain configures its own capabilities. The sample brain in the repo, a made-up company, has five agents on its roster, and each one does something different. Each brain defines how many agents it wants.

Watch this part 1:00 One engine, many brains

A brain is markdown files with zero lines of code

A lot of this is based on the second brain idea, except it's for a company. You want the different kinds of memory in one place: facts, decisions, events, the constitution of hard limits. Everything that works in a second brain for a person goes here.

OKF gives it a structure. Every concept is its own markdown file with a required type in its frontmatter, and two files are reserved: index.md is the map and log.md is the story. I chose it because the same file is readable by a person, an agent and a validator. There's no database, no admin UI and nothing to export. One concept per file means every git diff is one meaningful change, and typed frontmatter means pnpm cli validate can check the whole brain. The deck adds where this came from: plain files under git, adopted after a SaaS vendor deleted years of data.

An agent is a file too. Here is the hub's wiring from the sample brain. The job itself is prose underneath.

level: L3
model: "claude-sonnet-5"
harness: anthropic-api
heartbeat: daily
whitelist: [schedule-update, draft-write, defect-report]

level is the agent's rung on an autonomy ladder from L1 (report only) to L4 (external actions, each behind a human approval). harness picks the model provider, heartbeat sets its rhythm, and whitelist lists the writes it may propose. Adding an agent is copying a template. Retiring one is deleting the file. Promoting one is a one-line edit, and git history is the paper trail.

What's more unique is that agents run on Cloudflare and check out the brain to work on it. The brain's GitHub repo is every agent's source of truth. Every agent commits what it did, and at the end the chief of staff pulls everything together and sends one brief to the CEO of the company, who is a human. In the talk I said the whole thing is basically free, because it's fractional serverless compute that runs under the Workers limits. The reason it fits is that a model call is waiting on the network, not using the Worker's CPU.

Watch this part 3:20 Inside a brain

Decoupled beats let agents take sick days

The third idea is the sequence. Each agent runs when its beat comes up, and the chief of staff runs last to get everyone's results together. In the cloud, one Durable Object alarm fires at 08:00 in the company's own timezone and decides who is due:

• Each agent declares daily, weekly, monthly or quarterly, and the beat compares that with the agent's last run-completed line in the ledger. The thresholds sit under the calendar period (6 days for weekly, 27 for monthly, 85 for quarterly), so a beat that drifts by a few minutes never skips a run.
• Daily means "not yet today" on the local calendar, not 20 hours since the last run. A comment in the code says why: on the first scheduled morning, my 1 a.m. debug runs silenced the 8 a.m. brief.
• The due spokes run one at a time in alphabetical order, and the hub runs last so its brief reads the day's fresh reports.
• Everything lands in one commit. Only then does the brief go out.

It's this decoupled for two reasons: I want it to run for free on Cloudflare, and I want each brain to be able to customize itself. Each company should have its own staff. The deck adds why the spokes run one after another: the hub needs them finished, one vendor call at a time keeps rate-limit errors from piling up, and a failure points at exactly one agent.

Because it's my most decoupled agent architecture, two or three agents failing doesn't fail the whole thing. Say your company has 20 or 40 agents. If two or three fail, that's reported as a failure, but it doesn't crash the beat. People take sick days and the company keeps going. Their work isn't done that day, and that's maybe okay. The rule came from a real failure, and the comment is still in the code:

  // One spoke's failure never aborts the beat - an unattended mesh must
  // degrade agent-by-agent, not collapse. (Lesson from the first launchd
  // beat: an auth error in one provider killed the remaining runs.)
  const hubName = config.delivery?.deliverAgent ?? "chief-of-staff";
  const runs: RunReport[] = [];
  const failures: HeartbeatFailure[] = [];
  for (const { agent } of due) {
    progress(`heartbeat: running ${agent.name}`);
    try {
      // lines 228 to 242: run the agent; the hub also gets the scheduler notes
    } catch (err) {
      const message = err instanceof Error ? err.message : String(err);
      failures.push({ agent: agent.name, error: message });
      progress(`heartbeat: x ${agent.name} failed - ${message.slice(0, 200)} (continuing)
    }
  }

A failure still has to reach the human. If anything failed, the Worker sends a separate failure DM. No DM means the mesh is healthy, so silence must mean success.

Below is a simplified model of one morning's beat on the sample brain's five agents, with research-watch set to fail. Press Run the 08:00 beat: the other agents still finish, the brief still goes out, and a separate failure DM says which agent broke. Then press Next day and the failed agent is simply due again.

Watch the laptop-only agents. When one is due, the cloud tier doesn't just skip it: it rides into the hub's prompt as a note, so the brief nags me to run it locally. And a failed agent never writes its run-completed line, so it's simply due again at the next beat.

Watch this part 4:38 Decoupled beats

The brain reaches files where they already live

The fourth idea is reach. Just like people, I sometimes need to reach into a file cabinet, because I don't have perfect memory of, in theory, the ten companies I'm running. I need to dig out a piece of paper I read two years ago. AI is the same. Not everything has to be in OKF, but the agents need to reach into your SharePoint or your Google Drive.

Right now the project is Microsoft based. Documents stay in SharePoint and OneDrive and are read through Microsoft Graph: delegated, read-only, with the live folder listing in the agent's prompt. The brain records where the truth lives and what it means, and the original stays put: the EIN stays in the letter. The brain doesn't need all the knowledge, just like a human brain doesn't. It needs to know where to get the files. The demo is built for SharePoint, and I think it can be extended to Google Workspace.

The deck and repo go a little further than the talk did. The CRM was bootstrapped from the mailbox's sent items with a one-off consent and a token that's never saved, because your outbox is the ground truth of your real relationships. The cloud tier also reads sibling GitHub repos as sources. And there's one deliberate gap: no direct bank access. It's designed, not wired, and money stays behind the constitution's gates.

Watch this part 5:57 Reach into SharePoint

Every line of code in the open source engine

Number five is a big part of the goal. I want every single line of code in the open source code base, and each company, each brain, to have only its own markdown files. It's deliberate. The engine can be improved for everyone, and each brain is an instance of the engine.

That's a new way I'm thinking about my open source projects. If something is private and I don't want to share it, that's fine: separate the knowledge from the engine. The rule that makes it safe is strict. No private identity, real email, secret or persona name ever goes into engine code, templates, tests or docs, because one leaked name in a public repo is history you can't take back. When a brain proves a capability that's generally useful, it gets promoted into the engine with placeholders instead of names.

Watch this part 7:02 Open source engine, private knowledge

The brain files its own GitHub issues

This is the part I find the coolest. The brain is all markdown and zero lines of code, but the AI running it is fairly smart, and sometimes it realizes there's a bug in the engine. The brain can only change files in its own repo. It can't modify the engine. So the AI opens an issue on the engine, the same way people open issues on a project they don't control. No human does anything. When I recorded the video there were five issues on the engine, and all five had been opened by AI. Then I, as the maintainer of the engine, can see which brain hit what. My AI looks at the issue and makes a fix, the engine tags a release, and every brain gets the fix when it moves its pin.

Code decides what leaves a private brain for a public repo. The agent only writes the report, ending it with a fenced defect-report block, and four checks run on it:

1. The whitelist gate: only an L3 agent with defect-report on its whitelist may ask.
2. The identity-leak guard: any word of the principal's or persona's name, or any configured email, and the report is never filed. The guard denies; it never rewrites, because a guard that edits text is one you can't audit.
3. Title dedup against the engine's open defect issues, so a recurring bug is one issue.
4. A cap of two per run, and a ledger line either way. Anything that can't be filed becomes a private draft in the brain.

Issue #4 was an agent twice reporting a failure of a web tool that never existed: its job budgeted web searches while its harness sent no tools. That became the v0.12 release, where providers declare what they can actually do and the prompt says so out loud. Issues #5 and #6 were filed by a mesh's own hub and became v0.13, where an agent's required files are always put in its prompt or marked as missing.

Below, the engine's real checks run in your browser on a sample report. Each preset trips one of the four checks, and switching the agent to research-watch trips the first. The top line says what happened, and the lines under it are the ledger entries the engine would write. You can also edit the report text.

```defect-report
title: External web-fetch tool returns no usable content across consecutive agent runs
---
Repro: an agent whose job budgets web searches runs on a harness that sends no tools.
Expected: the prompt says plainly that no web search is available.
Actual: two runs in a row report a failed search tool that never existed.
```

```defect-report
title: External web-fetch tool returns no usable content across consecutive agent runs
---
Repro: an agent whose job budgets web searches runs on a harness that sends no tools.
Expected: the prompt says plainly that no web search is available.
Actual: Mira's brief to Casey went out with no research, and two runs in a row report a failed search tool that never existed.
```

```defect-report
title: claude-code harness: opaque failure when local login expires; instance env not passed to CLI providers
---
Repro: run a laptop-tier agent after the local CLI login has expired.
Expected: a clear auth error. Actual: an opaque failure.
```

```defect-report
title: Demo defect 1: schedule note repeated in the brief
---
Repro 1: the same scheduler note appears twice in one brief.
```

```defect-report
title: Demo defect 2: schedule note repeated in the brief
---
Repro 2: the same scheduler note appears twice in one brief.
```

```defect-report
title: Demo defect 3: schedule note repeated in the brief
---
Repro 3: the same scheduler note appears twice in one brief.
```

Watch this part 7:47 The AI files its own GitHub issues

The live demo read my non-compete to answer a question

The last thing I demoed took a little longer in Columbus. I still work for Accenture, so I asked a real question: with my non-compete, can I still present at AI Tinkerers Columbus, or would that be a problem? During the demo, the agent read the knowledge graph, pulled my actual non-compete PDF out of SharePoint through Microsoft Graph, read it and answered.

What I find powerful is that it didn't just answer from the knowledge graph. It went from the graph to the document, worked through it, and figured out what applied. I'm not showing the answer here, since it's my own employment paperwork.

Reading one specific document on request is v0.17.0, tagged the day of the talk. The agent ends its output with a read-request block naming files it saw in a listing, and deterministic code checks the source allowlist, the path and the caps (4 files, about 32K characters) before it serves them, with a ledger entry either way.

Watch this part 9:13 Demo: asking my non-compete a question

The real unlock is AI that reaches out to you

The crux of the engine wasn't demoable, because I'm not going to show a company's real data. The powerful part is that AI reaches out to the owners, not the other way around. Most of the time when people use AI, they sit down and type into it. Very seldom does AI take the mental load and the friction off you, organize its 10 or 25 workers, and then reach out to you about what's missing. To me, that's the only way one person could run ten companies: the mental load moves off the individual and into an agent orchestration layer.

The 35-second clip I posted on August 25 is this part of the live talk. If AI reaches out to you as the owner, it carries the mental load and keeps you focused, assuming the AI is good enough. My example was that AI may need me to download a statement from Chase.

In the engine, everything the mesh does ends in a channel I already live in. The daily brief arrives as a Discord DM. A failed beat sends its own DM. A nag comes back every morning with its day count until its done-condition is met. Due work the cloud can't run becomes an explicit ask. And the ask arrives with the work started: the sample brain's prep pack for a bank export has a session starter to paste, the prep already done, and quiz questions, so answering takes judgment, not reloading context. The machine holds the calendar and the state. I hold only the decisions.

Watch this part 10:06 The real unlock

What works today and where it stops

The engine runs its beat on Workers and Durable Objects against a private GitHub brain, and the same brain runs on a laptop through the CLI. You don't need my brain or any credentials to try it. The sample brain validates and runs on the engine's offline fake provider:

pnpm cli validate docs/sample-brain
pnpm cli run chief-of-staff --instance docs/sample-brain

Where it stops:

• It's pre-release. The deck documents v0.16.1 and the recording runs v0.17.0.
• Seven companies with one founder is still a thought experiment.
• Reach is SharePoint, OneDrive and the mailbox through Microsoft Graph, plus GitHub. Google Drive isn't built.
• There's no direct bank access, on purpose, and the commercial agents stay dormant until their activation gates are open.
• The spokes run one at a time by design, so a busy beat takes as long as its model calls.
• A CRM kept as one file per record suits hundreds of relationships, not tens of thousands.
• Agents can still be wrong, and a failed agent's work just doesn't happen that day. That's why money movement, filings, publishing, credentials and access always end at the human.

The repo has the full talk as a page, diagram then code, stop by stop, and a guide from an empty directory to a running brain. Since the recording, v0.17.1 and v0.17.2 have followed. If you're building anything agent-memory powered that reaches out to builders, not the other way around, I'd like to hear how you're doing it.