Requests from Slack, client calls and Sentry become tickets with the context attached. Claude Code and Codex open the repository, pull the plan for that exact application over 135 MCP tools and work under your team's rules. Progress lands back in the Slack thread where the question was asked.
Already have access? Sign in to the app
Built for teams where agents write code too
Most project tools were designed for people clicking through a browser, then given an API later. Falrow was designed from the start for teams whose coding agents do real work, so the plan, the rules and the context around the work suit an agent as well as a person.
Someone keeps them in sync by hand, or an agent works from whichever one it was pointed at.
The same records behind the app, Slack, the REST API and every MCP tool call.
Your coding agent works from the real plan
Falrow runs its own MCP server on the same database as the app. Claude Code, Codex or any MCP client signs in once, then reads the plan for the repository it is standing in, picks up tickets and records progress, with the permissions of the person who connected it.
An illustration with demo data. Tool names and behaviour are the server's own.
# your workspace's MCP endpoint
claude mcp add --transport http \
falrow https://<your-workspace>/api/mcpBrowser sign-in with OAuth and a consent screen, or a workspace token that expires after 90 days. Plus an agent package with a development workflow skill for Claude Code and Codex.
From the client call to the cycle, without retyping
If you build for clients, the reason behind a ticket is usually a conversation. Falrow keeps the customer, the meeting and the resulting tickets linked, so the developer and the agent can both see why the work exists and who it is for.
## Next steps
- Add Arabic to the booking flow
- Send staging link for sign-off by Friday
- Quote phase two: staff scheduling
- Ask about their hosting contract
The same records, whichever side of the work you are on
Nobody gets a separate tool, because a separate tool is the thing that has to be kept in sync. Each team reads the records it needs and writes the ones it owns.
Put your team, your clients and your agents on one plan
We are opening workspaces to a few teams at a time. Bring a real application and the agent you already code with, and we will set it up with you.
Structure your team and your agents both follow
Several applications, several clients, one team. The workspace records what each application is built with, who picks up which kind of ticket, and when cycles start and end, so nobody, human or agent, has to guess.
Applications with a tech stack
Website, web app, CRM, mobile app, API, MCP server or internal tool, each with its database, hosting, functions, frontend, backend and git repository on record.
Ticket types with their own rules
Bug, change, feature or task. Each type can have a default owner, a starting stage and the stages it may use, and projects can require an owner, estimate or closed blockers before Done.
Cycles on a schedule
Recurring cycles for the whole workspace or per project: 1 to 56 days long, with a cooldown, up to 12 planned ahead. Roll unfinished work over after a review, or automatically.
Delivery dates from history, not from hope
Reports are rebuilt from each ticket's recorded history, so work that moved between projects, was reopened or was deleted still counts where and when it really was. Ask “when will this be done?” and get a range with a probability, in the app or from your agent.
See where work piles up
Daily counts per stage category, and per custom stage, over a rolling window of 1 to 90 days. Filter by project or cycle.
| Day | Todo | In progress | In review | Done | Total |
|---|---|---|---|---|---|
| 1 | 9 | 4 | 2 | 2 | 17 |
| 2 | 9 | 5 | 2 | 3 | 19 |
| 3 | 8 | 5 | 3 | 4 | 20 |
| 4 | 8 | 6 | 2 | 6 | 22 |
| 5 | 9 | 5 | 3 | 7 | 24 |
| 6 | 8 | 6 | 3 | 9 | 26 |
| 7 | 8 | 6 | 2 | 11 | 27 |
| 8 | 9 | 5 | 3 | 12 | 29 |
| 9 | 8 | 6 | 3 | 14 | 31 |
| 10 | 8 | 6 | 2 | 16 | 32 |
| 11 | 8 | 5 | 3 | 18 | 34 |
| 12 | 7 | 6 | 3 | 19 | 35 |
| 13 | 8 | 6 | 2 | 21 | 37 |
| 14 | 7 | 5 | 3 | 23 | 38 |
A date range, with odds
12 open tickets in scope. 2,000 simulations resample your past weeks of completions and return the chance of hitting your deadline.
From request to forecast in four moves
The same loop for a client follow-up and a production bug, and the same loop whether a person or an agent does the step.
Capture from anywhere
Press C in the app, type /falrow create in Slack, convert a client meeting, start from a template, or let your agent open the ticket. Triage rules route it.
- Bug, change, feature or task
- Triage routing and snooze
- Duplicate resolution
Plan the cycle
Pull work into a scheduled cycle, check capacity per person, and attach milestones. Unfinished work rolls over after you review it, or automatically.
- Per-project schedules
- Capacity and availability
- Milestones and roadmap
Build with your agent
Open the repository. Your agent matches it to the application, reads the plan and updates tickets as it goes. If a teammate got there first the write is rejected, never applied over theirs.
- plan_context by git remote
- Version-checked updates
- Documents on tickets
Measure and forecast
Cumulative flow, time in stage and cycle time percentiles show how work actually moved. The forecast turns that history into a delivery date with odds.
- Rebuilt from history
- Monte Carlo P50-P95
- Saved, shared reports
Every door opens onto the same records
The app, your agents, Slack, Sentry, your notetakers and the API do not sync copies of each other. They read and write one database, under one set of roles and version checks, so there is nothing to drift.
MCP for Claude Code, Codex and more
A Streamable HTTP MCP server with OAuth 2.1 sign-in, a workspace resource, and prompts for a daily update and for planning open tickets. Plus an agent package with a development workflow skill.
Falrow in Slack
Mention @Falrow or use /falrow to create, find, take and move tickets. Each ticket gets a thread that tags whoever asked, and progress is posted there.
Meeting notetakers
Granola, Fathom, Fireflies or tl;dv with your own API key, stored encrypted. Preview privately, import once, turn actions into tickets.
How meetings workREST API
Authenticated /api/v1 for projects, tickets, cycles, milestones, customers, notes, documents, saved views and reports, plus search, bulk edits, transitions, rollover and meeting conversion. The same service layer as the app and MCP.
PATCH /api/v1/issues/{id}
{ "priority": "High", "version": 7 }Sentry
Route each Sentry project and environment to an application. Errors above your minimum level become one bug ticket per Sentry issue, owned by your type rules.
How routing worksGitHub & importers
Applications record their repository so agents find the right plan, but pull request sync and backlog importers are not built yet. Tell us if you need them.
One codebase. One database file. Yours.
The web app, CRM, REST API and MCP server are one TypeScript application on one SQLite database. It is built to run on a server you control, so your plan, your client records and your meeting notes do not have to live in someone else's cloud.
And for the humans: C creates a ticket where you are,⌘K searches everything, in light or dark.
Bring a real project, not a sandbox
We are opening workspaces to a few teams at a time, especially teams that build several applications and already code with Claude Code or Codex. Tell us what you build and we set it up with you.