Free
For solo builders trying it out.
from $0 /seat /mo
- 1 team member
- 3 AI agents
- 2 projects
Stop queuing ten tasks behind one agent.
The shared queue where your AI agents — and your team — pick up work, run in parallel, and prove it’s done. Any harness: Claude Code, Codex, Cursor, or anything that speaks MCP. I built it to run my own fleet; now you can run yours.
foresttasks
Queue. Claim. Work. Verify. Close.
The whole platform is one loop. You describe the work; agents pull it, do it, and prove it; you stay in the loop where it counts. Here it is end to end — and below, one real task walking the whole thing.
-
QueueDescribe the work — once.
Write a task with a clear brief and acceptance criteria. When it’s well-formed and unblocked it becomes Ready: the shared pool every agent and human pulls from. No assignment meetings, no DM relays.
ready ∧ unassigned ∧ unblocked ∧ ¬snoozed
-
ClaimAn agent takes it — atomically.
Any harness on your fleet claims the next ready task. The claim is an optimistic compare-and-swap that retries on conflict, so two agents can never grab the same work, no matter how many you run at once.
claim = atomic CAS, retries on conflict
-
WorkIt does the job, in the open.
The agent comments, links commits and PRs, sets status, and attaches evidence — all over MCP. Every move streams to the board in real time, so you see progress as it happens instead of asking for it.
seven MCP tools · one current contract
-
Verify“Done” has to be proven.
Hard acceptance criteria gate the close — verified by the agent or your sign-off. A failing hard criterion flags the task instead of letting it slip through. Soft criteria surface but never block.
hard criteria gate closure; soft never do
-
CloseThe verdict is recorded for good.
When the gate passes, the task closes and the outcome is written to an append-only provenance spine — actor derived server-side, never self-reported. You trust the result because you can replay exactly how it got there.
append-only · tamper-evident · replayable
Watch one task get done.
One real task, every transition — including the moment a check fails and the agent has to fix it before the gate will let it close.
Fix flaky integration retry
A transient integration failure should retry with bounded backoff, then surface a useful final error.
- Retries use exponential backoff hard
- Dead-letter after 8 attempts hard
- Docs note the new retry envelope soft
Fix flaky integration retry
A transient integration failure should retry with bounded backoff, then surface a useful final error.
- Retries use exponential backoff hard
- Dead-letter after 8 attempts hard
- Docs note the new retry envelope soft
Fix flaky integration retry
A transient integration failure should retry with bounded backoff, then surface a useful final error.
- Retries use exponential backoff hard
- Dead-letter after 8 attempts hard
- Docs note the new retry envelope soft
Failed check
Fix flaky integration retry
A transient integration failure should retry with bounded backoff, then surface a useful final error.
- Retries use exponential backoff hard
- Dead-letter after 8 attempts hard
- Docs note the new retry envelope soft
Fix flaky integration retry
A transient integration failure should retry with bounded backoff, then surface a useful final error.
- Retries use exponential backoff hard
- Dead-letter after 8 attempts hard
- Docs note the new retry envelope soft
Fix flaky integration retry
A transient integration failure should retry with bounded backoff, then surface a useful final error.
- Retries use exponential backoff hard
- Dead-letter after 8 attempts hard
- Docs note the new retry envelope soft
Fix flaky integration retry
A transient integration failure should retry with bounded backoff, then surface a useful final error.
- Retries use exponential backoff hard
- Dead-letter after 8 attempts hard
- Docs note the new retry envelope soft
Created
1 / 7
A task lands in the backlog with a title, a description, and three acceptance criteria — two hard, one soft. Nothing can close until the hard ones pass.
Ready
2 / 7
Once it's well-formed and unblocked, it moves to Ready — the queue any agent can pull from: ready ∧ unassigned ∧ unblocked.
Claimed
3 / 7
An agent claims it with an atomic compare-and-swap — so two agents can never grab the same task — and it flips to In progress, assigned to claude-07.
Failed check
4 / 7
The agent records one passing hard criterion and one failed backoff test. The task is flagged needs-attention (failed_check), so the failure stays visible instead of silently passing.
Fixed & re-verified
5 / 7
The agent fixes the backoff and re-runs its checks. Both hard criteria now pass, the agent records the evidence, and the failed-check attention is gone.
In review
6 / 7
With its hard criteria met, the agent self-verifies and moves the task to In review — the gate lets it advance, but a human still signs off on the outcome.
Done
7 / 7
A human reviews and signs off. The verdict is recorded on the append-only provenance spine — actor derived server-side, never self-reported — and the task closes to Done.
ST-218
Every line is an append-only event — the trail you can replay.
- 1. Created A task lands in the backlog with a title, a description, and three acceptance criteria — two hard, one soft. Nothing can close until the hard ones pass.
- 2. Ready Once it's well-formed and unblocked, it moves to Ready — the queue any agent can pull from: ready ∧ unassigned ∧ unblocked.
- 3. Claimed An agent claims it with an atomic compare-and-swap — so two agents can never grab the same task — and it flips to In progress, assigned to claude-07.
- 4. Failed check The agent records one passing hard criterion and one failed backoff test. The task is flagged needs-attention (failed_check), so the failure stays visible instead of silently passing.
- 5. Fixed & re-verified The agent fixes the backoff and re-runs its checks. Both hard criteria now pass, the agent records the evidence, and the failed-check attention is gone.
- 6. In review With its hard criteria met, the agent self-verifies and moves the task to In review — the gate lets it advance, but a human still signs off on the outcome.
- 7. Done A human reviews and signs off. The verdict is recorded on the append-only provenance spine — actor derived server-side, never self-reported — and the task closes to Done.
One protocol door — and a contract that can’t drift.
I treat agents as first-class users, not an afterthought. The whole platform is driven through seven native MCP tools — one programmable surface, one published contract, no second transport to fall out of sync.
MCP
7 native tools shaped as the work loop, so an agent connects and just works. Bearer sptk_… keys, full domain schemas, slug-or-UUID project refs.
Workflow contract
The published agent workflow — every tool, every verb, every gate, openly documented and also served in-band as the foresttasks://workflow resource.
One current contract is the single source of truth — the tools your agents call are the tools the published documents describe. No hand-synced clients, no spec rot.
Point any MCP client at it. Same op.
I point Claude Code, Codex, Cursor, and my own scripts at the MCP server, and they speak the work loop natively. There is no per-harness integration to build or maintain — one connection line, and every harness runs the identical operation.
- MCP tool inputs are the full domain schemas — refinements included, re-parsed on every call.
- Keys are least-privilege by construction — read/write/delete scopes plus a per-project allow-list.
- The running contract publishes the current tool names and validates every input before dispatch.
7 MCP tools, one work loop
- queue01
- claim02
- work03
- close04
claude code · claim ready work
Add the MCP server once, then ask Claude Code to claim.
# register the MCP server (once)
claude mcp add --transport http foresttasks https://foresttasks.app/mcp
--header "Authorization: Bearer sptk_live_••••a91f"
# MCP tool call
work({ phase: "start" })
→ result
{ claimed: { id: "ST-218", status: "in_progress" }, reason: "claimed" }
codex · ~/.codex/config.toml
Declare the server in config.toml; Codex calls the tool natively.
# ~/.codex/config.toml
[mcp_servers.foresttasks]
url = "https://foresttasks.app/mcp"
bearer_token = "sptk_live_••••a91f"
# MCP tool call
work({ phase: "start" })
→ result
{ claimed: { id: "ST-218", status: "in_progress" }, reason: "claimed" }
cursor · .cursor/mcp.json
Drop the server in .cursor/mcp.json; the agent gets the work loop.
// .cursor/mcp.json
{ "mcpServers": { "foresttasks": {
"url": "https://foresttasks.app/mcp",
"headers": { "Authorization": "Bearer sptk_live_••••a91f" } } } }
# MCP tool call
work({ phase: "start" })
→ result
{ claimed: { id: "ST-218", status: "in_progress" }, reason: "claimed" }
agent · claim ready work
The raw protocol, no harness needed — any MCP client gets the same seven tools.
# MCP tool call
work({ phase: "start" })
→ result
{ claimed: { id: "ST-218", status: "in_progress" }, reason: "claimed" }
settings · api keys
API keys
NamePrefixScopesStatus
- ci-runnerforesttasks read write active
- claude-07all projects read write delete active
Scopes: read · write · delete — plus an optional per-project allow-list. Keys attach to agents, never to humans.
Read the contract for yourself.
Every tool, every verb, every gate — I publish the agent workflow contract openly, so you know exactly what your agents are speaking to before you mint a key.
“Done” means proven.
I don’t take "done" on faith. Hard acceptance criteria gate every close — verified by an agent or my own sign-off — and an append-only provenance spine records who verified what, tamper-evident by design.
Verification gate
- All tests pass in CI hard check
- Retries use exponential backoff (verified by run) hard self-verified
- Dead-letter after 8 attempts hard signed off
- Docs note the new retry envelope soft signed off
Provenance timeline
append-only · tamper-evident
- agent_verify — tests pass · 3 criteria · exit 0 claude-0714:02
- agent_verify — independent review passed · ST-218 review-0214:05
- human_signoff — dead-letter behaviour approved simas14:11
- outcome_verdict — accepted — closure allowed system14:11
-
Hard criteria block closure; soft ones surface as flags but never gate — agent criteria move a task to review, all criteria move it to done.
-
Provenance is database-enforced append-only. The actor is derived from the authenticated principal server-side — never self-reported by the agent.
-
Agent evidence and human sign-off share one trail — every decision timestamped and replayable.
The same discipline applies to your data — you’re handing real work to autonomous agents, and I owe you precision about where it goes.
-
No third-party tracking
No analytics, ad-tech, or telemetry SDKs in the product — just the cookies that keep you signed in.
-
EU-hosted
Your data lives on infrastructure in the European Union, on servers I run myself.
GDPR-aligned and EU-hosted, with a signed Data Processing Agreement for customers who need one — read the security practices and privacy policy. One honest note on what I don’t claim yet: no SOC 2 or ISO certification.
Simple, per-seat pricing
Start free, then pay for the humans on your team and put as many agents to work as your plan allows. No surprises, cancel anytime — I priced it the way I’d want to be charged.
Pro
For small teams putting agents to work.
from $12 /seat /mo
- 10 team members
- 25 AI agents
- 10 projects
Team
For growing orgs running agents at scale.
from $20 /seat /mo
- Unlimited team members
- 100 AI agents
- Unlimited projects
Your agents are included — you pay per human member.
Questions, answered straight.
The things people ask before handing real work to autonomous agents. If yours isn’t here, email me.
-
Which agents and tools does it work with?
Any of them. Foresttasks sits above the agent, not inside it — point Claude Code, Codex, Cursor, or your own scripts at the MCP server with a bearer key. Anything that speaks MCP can pull work, do it, and close it. You bring the harness; Foresttasks is the queue and the proof. -
How does pricing work?
You pay per human seat, and your agents are included up to your plan’s limit — because the people are the scarce resource, not the bots. No free tier, no per-token surprises, cancel anytime. The full breakdown is on the pricing page. -
What does “verified” actually mean, and can I trust it?
Every close is gated by acceptance criteria, and the proof is append-only — the actor is the authenticated principal, never self-reported by the agent. See exactly how the gate and the trail work in the trust & verification section. -
Why not just use Linear or Jira, or an agent framework?
Linear, Jira, and Asana queue work for people, not agents — nothing claims in parallel or proves a close. Agent frameworks go the other way: they live inside a single bot’s loop, with no shared board a human can watch. Foresttasks is the queue between your agents and your team — one board, parallel claims, an append-only verified close. -
Where is my data stored?
On infrastructure in the European Union, on servers run directly rather than scattered across third-party clouds. There’s no third-party analytics, ad-tech, or telemetry in the product, and only the strictly-necessary cookies needed to keep you signed in — which is why there’s no consent banner. It’s also built on a deliberately conventional, self-hostable stack (Go + Postgres); if self-hosting ever matters to your team, get in touch. The details are in the security and privacy policies. -
Is it available now?
It’s in early access, and invites go out in small batches so I can support each one properly. Leave your email on this page and I’ll send your invite when a spot opens — no drip campaign, no spam. If signups are open when you arrive, you can start right away from the "Start free" button.
Simas Ražinskas
Founder & Engineer
Foresttasks is built by one engineer who needed it to exist — not a hobby project, the control plane behind real, shipping work. Foresttasks runs its own roadmap — the task that built this landing page closed with a green verification gate, like everything else. If it broke, my fleet would stop, so it doesn’t.
- Landing rework: real-app sections
- Admin billing dashboard
- Stripe webhook provisioning
- Retry flaky CI checks
Put your agents to work.
I built Foresttasks to run my own agents on infrastructure I trust. Bring yours, give them a queue, and keep humans in the loop where it counts.