Built for Claude, Cursor, Codex, and MCP agents
Stop Claude and Cursor from editing the same file
One agent starts from stale context. Another changes the file first. Availsync makes each integrated agent claim the repo, project, or file path before it edits.
Conflicts become skip_run before overwritten code reaches your branch.
Free plan includes 3 agents. No card required.
Paid plans are waitlist-only during the private pilot.
Repo guardrail active
Claude claimed frontend/components/Hero.tsx
Cursor sees the file is already claimed and skips before stale context overwrites Claude's edit.
Agent traffic control
Let the right agent win before work starts.
Several coding agents can wake up with the same repo state and all believe their run is safe. Availsync turns that invisible race into a deterministic decision.
Each agent checks in with the same resource. The gate compares active claims and priority rules, then returns proceed to the winner and skip_run to the rest.
Priority arbitration
Availsync is comparing priority rules in real time.
The failure mode
Your agents can read stale context and edit the same file.
Claude edits Hero.tsx. Cursor starts from stale context and edits the same file. Without a shared claim, both runs look safe locally until one overwrites or conflicts with the other.
Decision layer
Availsync arbitrates before the agent starts work.
Resource claims
Protect a repo, project, or file path so only the right agent works there at once.
Priority rules
Let deploys, migrations, reviews, and customer-facing work win deterministically.
Runtime history
See checks, claims, blocked runs, extensions, releases, and actors later.
Workflow
How it works
01
Create agents
Add each coding agent, AI tool, or assistant with its own priority and API key.
02
Choose resource scope
Use repo-level locks by default, then split into projects only when work streams are independent.
03
Claim before work
Agents call run/start, extend the lease while working, and release it when the run finishes.
Pilot safely
Start in observe mode.
Availsync will not block your agents yet. It records what it would have stopped, so you can measure value before enforcing.
Observe
Measure first
Agents continue running. Activity shows which runs would have received skip_run.
Enforce
Protect later
Once the signal is useful, switch selected agents to enforce and block overlapping claims.
Use cases
Built for multi-agent coordination
Coding agents
Claim a repo before Codex, Claude, Cursor, or MCP-based agents edit files. Block overlapping runs with skip_run.
Server automations
Let cron jobs, CI workers, and scheduled scripts claim the same resources your agents use.
Deploy and review windows
Give deploys, migrations, review passes, and customer-impacting work deterministic priority.
Scheduling agents
Secondary flow: coordinate availability, holds, and meeting-time conflicts before agents book downstream systems.
Start with 3 agents for free.
Paid tiers are waitlist-only during the private pilot. Start free, run verification, and join the waitlist when you need more agents or protected resources.
FAQ
Questions buyers ask
Short answers for teams comparing Availsync with agent frameworks, policy tools, calendars, and homegrown locks.
Is Availsync a calendar app?
No. Availsync is a coordination API for agents. It protects repos and projects first, and also supports availability holds for scheduling use cases.
Does Availsync run my agents?
No. Your agents still run in Codex, Claude, Cursor, MCP, cron, or your server. Availsync is the coordination check they call before acting.
Is Availsync the same as a policy enforcement tool like Sift or PolicyLayer?
No. Policy tools control what your agents are allowed to do. They sit between an agent and a tool call and ask: is this permitted?
Availsync controls when your agents can act. It asks: is this window, repo, or resource already claimed by another agent?
An agent can have full permission to deploy via a policy tool and still be blocked by Availsync because another agent owns that deploy window. They solve different problems and work well together.
Do worktrees replace Availsync?
No. Worktrees are a good baseline for isolating where agents work. They keep separate checkouts, branches, and dev servers from stepping on each other locally.
Availsync coordinates whether work should start. Even with separate worktrees, two agents can branch from the same stale repo state, touch related logic, prepare overlapping deploys, or run migrations at the wrong time.
Use them together: worktrees isolate execution environments, while Availsync coordinates shared resources, priorities, and proceed or skip_run decisions across agents.
Does it stop agents automatically?
Only agents that call Availsync can be coordinated. Availsync returns proceed, skip_run, or observe-mode decisions; your agent or SDK wrapper must respect that response.
Can coding agents use it?
Yes. Codex, Claude, Cursor, MCP clients, cron jobs, and server automations can call Availsync before they touch a repo or project.
Can Availsync prevent stale context between agents?
Yes for the same resource when repo-level claims are used. Availsync does not automatically infer dependencies between different project keys yet.
Do API keys appear again?
No. The raw key is never shown as text again. During creation you can copy it once, then store it in your agent or server environment.
What happens when two agents want the same resource?
Availsync applies explicit priority rules, agent type hierarchy, agent priority, then first-created order. The blocked agent gets a clear skip_run response.
What if an agent crashes before releasing its claim?
Availsync uses leases, not permanent locks. Every work claim has an expiry time, so a crashed agent cannot hold a repo or project forever.
Long-running agents should extend the lease while they work and release it when they finish. The Node SDK withClaim helper does this cleanup in a finally path when a real claim exists.
If the agent crashes or disappears, the claim expires automatically and other agents can claim the resource again after the lease window.
What happens if Availsync is unavailable?
The SDK and MCP package surface the failure. In enforce mode, the recommended production policy is fail-closed; see the Reliability docs for details.