Skip to content
/
Tier B A3 MCP-anchored

Asynkor

asynkor · asynkor/asynkor · ★ 49 · last commit 2026-05-03

Prevents edit-time file conflicts and provides compounding team memory for concurrent multi-machine AI agent teams.

Best whenGit merge-time conflict resolution is too late — agents need atomic file leases at edit time.
Skip ifAllowing agents to edit shared files without coordination, Requiring git pull between agent sessions for file synchronization
vs seeds
claude-flowprovides multi-agent orchestration but runs on a single machine with a hierarchical queen/worker pattern; Asynkor coordi…
Primitive shape 21 total
MCP tools 21
00

Summary

Asynkor — Summary

Asynkor is an MCP-based coordination layer for teams running multiple AI coding agents simultaneously across different machines, IDEs, and agents. It solves the merge conflict problem at edit time (not merge time) by giving agents atomic file leases: an agent that wants to edit api.ts acquires an exclusive lease; other agents attempting to touch the same file are blocked until the lease is released, at which point they receive a file snapshot containing the first agent's changes. Beyond lease management, Asynkor provides compounding team memory (agents call asynkor_remember() to persist architectural decisions that all future sessions inherit), protected zones (path-level guardrails that warn, confirm, or block on sensitive directories), async inter-agent messaging, and a live web dashboard showing active agents, leases, parked work, and audit history. It installs with a single npx -y @asynkor/mcp login command that auto-detects every installed IDE and wires the MCP server into each.

Asynkor most closely resembles claude-flow among the seeds in that both are MCP-anchored and address multi-agent scenarios, but while claude-flow provides hive-mind orchestration with a central queen agent, Asynkor is purely a coordination layer: it prevents conflicts and synchronizes state but does not direct what agents build or how they work. The framework is closest to the "shared infrastructure" pattern (like InsForge for backends), applied to the problem of concurrent file editing.

01

Overview

Asynkor — Overview

Origin

Asynkor is a Go-based project by the asynkor organization, published in 2025-2026. It reached 49 stars as of analysis date and is actively maintained (last push 2026-05-03). The MCP client package is @asynkor/mcp on npm.

Philosophy

The README states: "The coordination layer for AI coding agents. Git prevents conflicts at merge time. Asynkor prevents them at edit time."

The core philosophy is that multi-agent coding teams need coordination infrastructure at the file-editing level, not just at the git-merge level. By the time two agents produce conflicting changes, the damage is already done — one agent's work will be discarded. Asynkor prevents the situation from arising by serializing writes to shared files via atomic leases.

Key Insight

"Your team runs Claude Code on one laptop, Cursor on another, Windsurf on a third. The agents don't know about each other. They overwrite each other's edits, duplicate each other's work, and forget yesterday's decisions. Asynkor gives them one shared brain."

Four Core Problems Addressed

  1. File conflicts: Atomic leases prevent simultaneous edits to the same file
  2. Knowledge loss: Compounding team memory means each session inherits all prior decisions
  3. Cross-IDE isolation: Works across any MCP-compatible IDE/agent on any machine
  4. Lack of visibility: Live dashboard shows who's working, on what, with which files leased

Use Cases

  • Multi-machine teams (two devs on separate laptops, both with agents editing the same repo)
  • Solo devs across IDEs (Claude Code at work, Cursor on personal Mac)
  • Large agent fleets (5+ concurrent agents on one codebase)
  • Cross-repo orchestration (frontend and backend agents that need to know about each other)
02

Architecture

Asynkor — Architecture

Distribution

  • npm package: @asynkor/mcp
  • Install: npx -y @asynkor/mcp login (auto-detects and wires all installed IDEs)
  • Manual: ASYNKOR_API_KEY=... npx @asynkor/mcp install

Required Runtime

  • Node.js (for MCP client)
  • API key from asynkor.com dashboard

Repository Structure

asynkor/
├── mcp/                    # Go MCP server
│   ├── main.go
│   ├── config/
│   └── internal/
│       ├── activity/       # Activity tracking
│       ├── auth/           # Authentication
│       ├── lease/          # Atomic file leasing
│       ├── mcpserver/      # MCP server implementation
│       ├── natsbus/        # NATS message bus
│       ├── redisstore/     # Redis state store
│       ├── session/        # Session management
│       ├── teamctx/        # Team context
│       └── work/           # Work unit tracking
├── client/                 # TypeScript MCP client (npm package)
│   └── src/
└── CLAUDE.md               # Agent guidance

Backend Infrastructure

The MCP server is Go-based and uses:

  • NATS: Message bus for real-time event distribution
  • Redis: State store for leases, sessions, work units, and memory
  • asynkor.com: Cloud service providing the coordination backend

Target AI Tools

Any MCP-compatible agent:

  • Claude Code
  • Cursor
  • Windsurf
  • VS Code Copilot
  • JetBrains
  • Zed
  • Codex CLI

Installation Auto-detection

npx -y @asynkor/mcp login opens browser for auth, then runs asynkor install which detects all installed IDEs and adds Asynkor to each. Subsequent runs are idempotent.

03

Components

Asynkor — Components

MCP Tools (21 total across two v0.2 groups)

Core Work Tools (11)

Tool Purpose
asynkor_briefing Team state: active work, leases, parked sessions, memory, follow-ups, inbox
asynkor_start Declare work intent + acquire file leases for specified paths
asynkor_check Check rules, zones, and leases for specific paths before editing
asynkor_remember Save a short-term staging memory (architectural decision, context)
asynkor_forget Drop a staging memory
asynkor_finish Complete work, release leases, upload file snapshots to team
asynkor_park Pause work for another agent to resume later
asynkor_lease_acquire Acquire additional file leases mid-work
asynkor_lease_wait Block until a contested lease becomes available
asynkor_cancel Clean up stale or orphaned work sessions
asynkor_context / asynkor_context_update Read / atomically rewrite the long-term project doc

Team / Multi-Agent Tools (10) — v0.2

Tool Purpose
asynkor_inspect Read live state of a teammate's work without interrupting
asynkor_ask Open an async thread addressed to another agent
asynkor_inbox List threads addressed to the current agent
asynkor_thread Read a full thread transcript
asynkor_reply Append a reply to a thread (optionally closes it)
asynkor_switch_team Switch the active team (user-scoped API keys)
Protected zones Path-level warn / confirm / block guardrails

Dashboard Features (asynkor.com/dashboard)

Feature Description
Agent overview Connected agents, what each is doing
Lease map Which files are leased by which agent
Activity timeline Who ran what when (pan/zoom)
Conflict graph Agent ↔ files constellation with conflict pulse visualization
Context editor Long-term project documentation
Rules Architectural guardrails
Memory Compounding team knowledge store
Zones Protected path configuration
Members Team invites and roles
Audit log Full history of agent actions

Board Views (4 lenses)

  • Table: Scan all work in rows
  • Board: Live state (active / parked / leased)
  • Timeline: When work happened (pan/zoom)
  • Graph: Agent ↔ files constellation with conflict detection
05

Prompts

Asynkor — Prompts

Asynkor is an MCP coordination server, not a prompt engineering framework. It does not ship SKILL.md or agent prompt files. The "prompts" are the CLAUDE.md guidance and the tool invocation patterns documented in the README.

Excerpt 1 — CLAUDE.md Agent Guidance

# Asynkor coordination rules

1. Call asynkor_briefing at the start of every session.
   It returns: active work (yours + teammates), leases, parked sessions, 
   long-term memory, follow-up items, and unread inbox messages.
   
2. Call asynkor_start before editing any file.
   - paths: list every file you plan to touch (estimate if uncertain)
   - title: one-sentence description of the work
   If a file is leased by another agent, asynkor_start returns BLOCKED.
   Then call asynkor_lease_wait(path) or work on unblocked files first.

3. Call asynkor_finish when done.
   - Include file snapshots for every file you changed
   
4. Use asynkor_remember for insights the team should know:
   architectural decisions, discovered bugs, agreed conventions.

Prompting technique: Sequential protocol injection. CLAUDE.md functions as an Iron Law (similar to superpowers' pattern): every session must follow the start→work→finish cycle. The rules are concrete and verifiable — they specify exact tool calls, not abstract guidelines.

Excerpt 2 — README Tool Usage Examples (Code Comment Pattern)

Agent A                          Asynkor                          Agent B
  │                                │                                │
  ├─ asynkor_start(paths=[api.ts]) │                                │
  │  ◄── lease acquired ──────────►│                                │
  │                                │◄── asynkor_start(paths=[api.ts])│
  │                                │──► BLOCKED: api.ts leased      │
  │  ... editing api.ts ...        │                                │
  │                                │     ... works on other files...│
  ├─ asynkor_finish(snapshots)     │                                │
  │  ◄── leases released ────────►│                                │
  │                                │◄── asynkor_lease_wait(api.ts)  │
  │                                │──► acquired + file snapshot    │

Prompting technique: State machine documentation as agent training data. The ASCII sequence diagram in the README doubles as an agent-readable protocol specification — agents that consume this documentation learn the correct interaction pattern via the diagram structure itself.

Excerpt 3 — Multi-Agent Memory Pattern

asynkor_remember("Auth uses RS256 JWTs. Secret rotation: every 90 days.")
asynkor_remember("Do not modify /migrations directly — always use `pnpm db:migrate`.")

Prompting technique: Persistent protocol injection. asynkor_remember calls accumulate into a shared memory that all future agent sessions inherit via asynkor_briefing. This converts ephemeral in-session knowledge into durable cross-agent institutional memory.

09

Uniqueness

Asynkor — Uniqueness

Differs from Seeds

Asynkor addresses a coordination problem that no seed framework tackles: edit-time conflict prevention for concurrent multi-machine agent teams. All 11 seeds assume a single agent working on a single machine in a single IDE — even claude-flow, which provides multi-agent orchestration via a queen/worker hierarchy on one machine, does not address the "two devs, two laptops, two agents editing the same repo" scenario. Asynkor's atomic file lease mechanism is edit-time isolation at the file level, which is more granular than git worktrees (which isolate at the branch level) and more practical than containers (which isolate whole environments). The asynkor_finish(snapshots) flow — uploading changed files so the next agent can write them locally without git pull — is a novel cross-machine file synchronization primitive not present in any seed. The compounding team memory (asynkor_remember) is semantically closest to ccmemory's Neo4j knowledge graph, but persists conversational knowledge (decisions, conventions) rather than codebase structure.

Positioning

Asynkor is infrastructure for multi-agent teams, not a workflow framework. It is orthogonal to spec-driven development, TDD enforcement, and task decomposition. It answers the question "how do five agents work on the same repo without destroying each other's work?" rather than "how does one agent produce high-quality software?"

Observable Failure Modes

  1. Cloud dependency: Asynkor requires asynkor.com — there is no fully self-hosted option. If the service goes down, all inter-agent coordination fails.
  2. Optimistic lease underspecification: Agents must declare the files they intend to edit before editing them. Undeclared files won't be leased, causing silent conflicts.
  3. No code quality coordination: Asynkor prevents file conflicts but cannot prevent semantic conflicts — two agents making logically contradictory changes to different files that happen to interact.
  4. Memory pollution: The asynkor_remember mechanism is append-only. Stale or incorrect memories accumulate over time with no automated expiration.
  5. Latency: Every file edit is gated on a network round-trip to acquire a lease. In poor network conditions, this adds overhead to every file write.
04

Workflow

Asynkor — Workflow

Per-Agent Work Cycle

Step Tool Description
1. Brief asynkor_briefing Agent reads team state: who's working, which files are leased, recent memory
2. Start asynkor_start(paths=[...]) Declare intent + acquire leases. Blocked if another agent holds a lease
3. Check (optional) asynkor_check Verify zone rules for sensitive paths
4. Work (agent edits files normally) Leased files protected from concurrent edit
5. Finish asynkor_finish(snapshots) Release leases, upload file snapshots for other agents
6. Park (optional) asynkor_park Pause; snapshots upload, leases release, work is resumable

File Snapshot Flow

Agent A                    Asynkor                    Agent B
  │                          │                          │
  ├─ asynkor_start           │                          │
  │  [api.ts leased]─────────►                          │
  │                          │◄─ asynkor_start          │
  │                          │   [api.ts BLOCKED]───────►
  │  (edits api.ts)          │                          │
  │                          │   (works on other files) │
  ├─ asynkor_finish          │                          │
  │  [snapshots upload]──────►                          │
  │                          │◄─ asynkor_lease_wait     │
  │                          │   [acquired + snapshot]──►
  │                          │   (Agent B writes snapshot, edits on top)

Phase Artifacts

Phase Artifact
Start Active lease record in Redis
Finish File snapshots distributed to waiting agents
Remember Team memory entry (persists across sessions)
Briefing Current team state document

Approval Gates

No approval gates — the coordination is automatic (lease acquire/wait/release). Zone guardrails can require confirm before proceeding on protected paths, which is the closest thing to an approval gate.

06

Memory Context

Asynkor — Memory & Context

Memory Architecture

Asynkor provides three layers of memory:

Layer Storage Persistence Scope
Long-term project context Redis (cloud) Global All agents on all sessions
Team memory Redis (cloud) Global All agents on all sessions
Session work state Redis (cloud) Session Current active work only

Long-Term Project Context

The asynkor_context / asynkor_context_update tools read and atomically rewrite a project-level document (architecture overview, conventions, key decisions). This is visible to all agents via asynkor_briefing.

Team Memory (Compounding)

asynkor_remember() and asynkor_forget() manage short-term staging memories that compound into the team knowledge base. Examples of what agents store:

  • Architectural decisions
  • Discovered patterns and anti-patterns
  • Agreed conventions
  • Follow-up items

Every new agent session inherits all prior team memory on asynkor_briefing. This is the "shared brain" mechanism — knowledge doesn't reset between sessions.

Session State

Active work units (leases, current files being edited, work description) are stored in Redis and visible to other agents via asynkor_briefing and asynkor_inspect. When work is parked, its state persists for another agent to resume.

File Snapshots

When asynkor_finish is called, file snapshots are uploaded and queued for agents waiting on those files. The receiving agent writes the snapshot to disk before editing — no git pull required.

Cross-Session Handoff

Yes — parked work can be resumed by any agent on any machine. The team memory, context, and file snapshots provide full continuity without requiring git synchronization.

Memory Type

Redis-based state store with cloud persistence (asynkor.com). The Go MCP server uses a redisstore internal package.

Search Mechanism

None documented. Memory is retrieved via asynkor_briefing (full state dump) or asynkor_inspect (specific agent state).

07

Orchestration

Asynkor — Orchestration

Multi-Agent

Yes. Asynkor is specifically designed for multi-agent teams. It coordinates agents on different machines, different IDEs, and different agent types.

Orchestration Pattern

parallel-fan-out — multiple agents work in parallel on different parts of the codebase simultaneously. Asynkor prevents conflicts between them but does not direct their work. There is no central queen or director agent; coordination is peer-to-peer via the shared lease/memory store.

Isolation Mechanism

process — agents run as independent processes on separate machines or terminals. File-level isolation is enforced via atomic leases (each file can only have one active writer at a time). This is a novel isolation mechanism not seen in the seed frameworks — it is edit-time isolation rather than branch-level or worktree-level isolation.

Max Concurrent Agents

Unknown — no documented limit. The README mentions "five or more concurrent agents on one codebase" as a primary use case.

Execution Mode

continuous-ralph — Asynkor is always running (cloud service), and agents connect to it for each session. It is not invoked per-feature; it is ambient infrastructure.

Multi-Model

No. Asynkor is model-agnostic. It coordinates agents regardless of which LLM they use.

Consensus Mechanism

none in the formal sense (no raft/byzantine). Coordination is via exclusive leases: only one writer per file at a time. This is a mutex-based approach, not a consensus protocol.

Prompt Chaining

No. Asynkor provides coordination, not prompt chaining. Agents call Asynkor tools as side effects of their work, not as stages in a prompt chain.

Cross-Tool Portability

High — any MCP-compatible agent works with Asynkor (Claude Code, Cursor, Windsurf, JetBrains, Zed, Codex CLI, VS Code Copilot).

08

Ui Cli Surface

Asynkor — UI & CLI Surface

Dedicated CLI Binary

No standalone CLI binary in the traditional sense. The npx @asynkor/mcp invocation functions as an installer/configuration tool, not a coding workflow CLI.

Subcommands available via npx:

  • login — authenticate and auto-install Asynkor into all detected IDEs
  • install — install into detected IDEs with an existing API key

Local Web Dashboard

Yes — asynkor.com/dashboard (cloud-hosted, not localhost). Features:

Section Description
Overview Live: connected agents, active work, leases, parked sessions, memory
Board: Table All work items in rows
Board: Board Live state (active / parked / leases)
Board: Timeline Who ran what when (pan/zoom)
Board: Graph Agent ↔ files constellation with conflict pulse visualization
Context Long-term project documentation editor
Rules Architectural guardrail configuration
Memory Compounding team knowledge viewer
Zones Protected path configuration (warn / confirm / block)
Members Team invites and role management
API Keys API key management
Audit Log Full history of all agent actions
Settings Team and project configuration

The README screenshot captions describe the dashboard as designed for a second monitor: "Put it on a second monitor. You'll see conflicts forming before they happen."

IDE Integration

Auto-installed into all detected IDEs via asynkor install. The Go MCP server adds Asynkor to each IDE's MCP configuration automatically.

Observability

Yes — the audit log is a first-class feature. Every agent action (lease acquire/release, memory write, work start/finish, file snapshot) is logged and visible in the dashboard. This provides full replay capability for understanding what happened in a session.

Related frameworks

same archetype · same primary tool · same memory type

Taskmaster AI ★ 27k
A3 MCP-anchored

Converts a PRD into a dependency-ordered JSON task graph that AI coding agents execute one task at a time, eliminating context…

ccmemory ★ 1
A3 MCP-anchored

Accumulates decisions, corrections, and failed approaches from Claude Code sessions into a queryable Neo4j graph so each new…

Pimzino spec-workflow-mcp ★ 4.2k
A3 MCP-anchored

MCP server providing spec-driven development workflow with dashboard-backed approval gates, implementation logging, and VSCode…

MCP Shrimp Task Manager ★ 2.1k
A3 MCP-anchored

Convert natural language requests into structured AI development tasks with chain-of-thought enforcement, reflection gates, and…

Bernstein ★ 460
A3 MCP-anchored

Govern parallel CLI coding agents with a deterministic Python scheduler, HMAC-chained audit trail, and compliance-ready signed…

LeanSpec ★ 252
A3 MCP-anchored

Provides a unified spec CLI and MCP server over any existing spec backend (markdown, GitHub Issues, ADO), making spec-driven…