A shared operating model for humans and AI agents.
MeshKore defines how work, context, decisions and conventions are organized — so any AI agent can contribute consistently to a project.
It's not a tool, an app, or another coding assistant. It's the model your whole team — human and AI — operates by. Four dimensions define it:
Read https://api.meshkore.com/v1https://api.meshkore.com/v1/standard.md and apply it to this repo.
Your agent fetches the spec, creates .meshkore/, drops the editor rules at the repo root, and reports back what changed — all reviewable in the diff.
Humans set direction; agents do the work — but both read and write through the same model. That's what makes their output consistent, no matter which tool runs.
Four dimensions, one operating model.
These aren't four features among many — together they are MeshKore. Each answers a different question about how a project runs with AI in the loop.
The contract for handing work between humans and agents — every turn anchored to an initiative and task, logged, and attributed to who (or what) did it.
A predictable home for roadmaps, tasks, context, decisions and resources — so any agent finds what it needs in the same place every time.
The rules agents are expected to keep — commit attribution, snapshots before edits, daily logs, the do's and don'ts — versioned so they never drift.
An opt-in ladder from a single local project up to many agents on many machines, and a network that coordinates across projects — adopt only what you need.
The folder is not the standard.
You'll see a .meshkore/ folder and a CLAUDE.md appear in your repo. Those are how the model shows up on disk — its implementation, not the thing itself.
MeshKore is the operating model. The files are one way of expressing it. Swap the editor, swap the tooling, and the model — and everything your agents already know — stays intact.
One concept, many manifestations. The contract is portable; the files are interchangeable.
What changes when a project has an operating model.
Working with AI agents without a shared model means re-explaining everything, every session. The model is what turns one-off prompting into durable, repeatable work.
- ✕ Every agent has to be re-briefed from scratch.
- ✕ Context is fragmented across chats, READMEs and people's heads.
- ✕ Conventions drift — what's in your head, your README and your rules file diverge.
- ✕ Decisions vanish; nobody remembers why a thing was done.
- ✕ You can't tell which change came from which agent.
- ✓ Agents inherit context — every session starts informed.
- ✓ Work is anchored to tasks and a shared roadmap.
- ✓ Decisions are documented where the next agent will read them.
- ✓ Conventions stay consistent — versioned, not improvised.
- ✓ Every change is attributable to an agent, a model, and a moment.
Adopt as much of the model as you need.
The same model scales from a single offline repo to many agents coordinating across machines and projects. Each level is a strict superset of the one above — climb only when a real problem asks for it. Most teams only ever need L0 and L1.
.meshkore/ tree with context, tasks and governance. Works offline, no account, no install — the model, on disk, in one repo. Where almost everyone starts.
CLAUDE.md / .cursorrules / .windsurfrules at the repo root so every agent session loads the model automatically — no pasting, no reminding.
meshcore daemon and run several agents, on several machines, against one shared model — observed and dispatched from the Architect cockpit. Optional.
Architect — the cockpit for L3
When you turn the daemon on, Architect gives you a live view of every agent, roadmap and chat across your cluster. It's one implementation of the model's coordination layer — the operating model stays the protagonist; the cockpit just makes L3 tangible.
Full decision tree + per-level setup at /cluster/adopt.
Where the model lives on disk.
For the curious: this is how the operating model materializes inside a repo. You never have to design any of it — your agent lays it down when you adopt.
The folder layout
.meshkore/ ├── public/cluster.yaml ← only committed to git ├── docs/ project context ├── modules/<id>/ tasks/log/diagrams ├── log/<YYYY-MM-DD>.md daily prose ├── timeline/<date>.jsonl machine events ├── credentials/ secrets, never committed └── (a few more) full list in spec
Cycles — optional timebox
Tasks gain one optional frontmatter key: cycle: <id>. A cycle is a 1–2 week timebox declared by a file in .meshkore/cycles/<id>.md:
--- id: 2026-w22 title: "Sprint 22 — CC P0" starts: 2026-05-25 ends: 2026-06-07 status: active ---
Don't want sprint cadence? Don't create cycle files — every task stays uncycled and nothing changes.
Versioning
The model is versioned. Breaking changes get a major bump and an explicit migration path.
The changelog describes every version; your agent applies the catch-up when a repo's .meshkore/STANDARD_VERSION falls behind.
Teams who follow the adoption ladder rarely see migrations — the daemon detects drift and prompts.
For agents and automation
This page is the human overview. The full normative content — schemas, frontmatter, governance rules, path conventions, hard rules, editor boot block — lives in the agent-facing spec. If you're an AI agent applying the standard to a repo, fetch one of these instead:
Refresh cadence: once per session, or every 24h. The updated field in standard.json signals changes. If anything elsewhere on this site contradicts that spec, the spec wins.
Start here
Drift between this page and any other? File it as a doc-bug at github.com/meshkore. The agent-facing spec is the tiebreaker.