For developers running coding agents
declr gives your coding agents a shared record of tasks, decisions, ownership and handoffs. They can pick up the work, coordinate with each other and leave a useful trail. You spend less time repeating the plan and piecing together what happened.
For one agent across sessions, or several working together.
From the agent’s side
Every session starts with a context limit. Every swarm has moving parts. A shared working record gives agents somewhere to find what they need and leave what they learn.
“Get me oriented.”
The goal, relevant decisions, known issues and last checkpoint in one compact briefing.
The next session can pick up the work without you retelling its history.
“Give me work I can start.”
A next task with dependencies and existing reservations considered.
Agents can find useful work while other tasks wait for a decision or a dependency.
“Show me who owns what.”
Shared assignments and file leases show who is working where. An overlap points to the holder and their task.
Agents have the information to coordinate before an overlap becomes your problem.
“Keep track of my subagents.”
Assignments, checkpoints and blockers stay attached to the shared task graph.
You or the next orchestrator can follow delegated work after the original session ends.
“Let me leave what I found.”
A quick way to record a failure, question or discovery against its task and path.
What one agent learns is available to the agents that follow.
“Help me hand this over.”
Changes, checks and open questions travel with the task to a separate verifier.
The reviewer can see what was checked and what still needs attention.
Back on your side
Your agents leave a working record as they go. You see what is moving, what needs your decision and what is ready for review. Open a task when you need the context behind it.
approved scopeadded by agents since you approvedneeds you
The same record helps agents continue the work and helps you understand it.
Why it works
declr keeps the working record and applies a few coordination rules. Your agents use the result to decide what to do next.
If a path is already held, the agent gets the holder, task and expiry. It can narrow its scope, coordinate or choose other work.
Before completion, reported failing checks need a filed issue. The next agent has a specific finding to consult.
Completed work goes to needs_verify with its checks attached. A different actor verifies or rejects it.
Tasks belong to the roadmap. Work without a parent waits for approval, so additions stay visible.
And what it keeps on the record
Branch, worktree, base commit and last checkpoint help the next session continue.
Recorded changes on held paths tell the agent when its working base needs attention.
Recorded issues and decisions can be retrieved by path before the next edit.
Drops in
One issue in your tracker maps to one node in declr. Subtasks, leases, checkpoints, questions and evidence stay in declr and roll up as a single comment, edited in place. declr's done sets your In Review. A person closes.
Pricing
Founding cohort: the first fifty people keep this price for two years. Cancel any time.
Reserve
Tell us where you keep stepping in: repeating context, coordinating work or checking what actually finished.
Questions
declr works with the task context and metadata your agents send: decisions, checkpoints, declared paths, commit hashes and evidence. It does not need to read your repository’s source files.
Search embeddings on task titles are the only model call. Your own agent handles planning, decomposition, tagging and dependency reasoning.
Your agent does, from your brief, through the skill. declr stores it, counts it, and draws it. You approve the nodes.
No. It is the layer underneath, at agent granularity. Your board stays at human granularity and nobody on your team has to open declr except the person running the agents.
A local file is read by two agents in two worktrees and both proceed. Nothing refuses the second one in real time, and nothing stops the author from marking its own work verified. declr runs those checks at call time from one shared database, and holds the plan for the parts of the project that are not code.