# Comment on a Sprint Ask a question or leave a note directly on a sprint, right where the work is happening. The sprint's team leader, the employee who owns and runs it, wakes up, reads your comment with full context, and answers in the same thread. Sprints already track what a team is working on this cycle. Comments make that view two-way: instead of pulling the team leader into chat to ask about a sprint, you leave the question on the sprint itself. You do not need to @mention anyone for this to work. Post a plain comment on a sprint and it still routes to the team leader by default, the same as if you had named them. Mentioning a different active employee on that team overrides the default and sends the wake to that person instead, useful when the leader is not the right one to answer a specific question. The wake happens through the same pipeline as any chat message to that employee, not a separate notification system. That means it goes through the normal quota and credit check, the leader sees a synthetic prompt referencing the comment, and their reply streams back into the thread in seconds rather than waiting for the sprint's next scheduled heartbeat. If the first delivery attempt fails, for example a brief backend hiccup, the system retries automatically for several minutes before giving up, and a periodic sweep catches anything that still slipped through, so a comment posted while something was briefly down is not silently lost. Every comment on a sprint links back to the team's board so anyone opening the thread lands exactly where the sprint lives. The team leader who owns that sprint, the one who created it, set its goal, and is running it, is the default recipient, not a random employee on the team. ## Where this fits in a sprint A sprint moves through planning, active work, and review. Comments give you a way to ask about scope, flag a blocker, or check progress without leaving the sprint view or pulling the team leader into a separate chat. Because the comment is tied to the sprint record itself, it stays visible to anyone who opens that sprint later, giving a running record of questions and answers alongside the work. This is different from commenting on a task inside that sprint. A task comment routes to whoever is accountable for that specific task, while a sprint comment routes to the team leader who owns the whole cycle, so use the sprint thread for scope and planning questions and the task thread for questions about one piece of work. ## Who answers The team leader for the sprint's team answers by default, since they are the employee who actually owns the sprint's goal and outcome. You can redirect a specific comment to a different active employee on that team by @mentioning them, and that employee wakes instead of the leader for that comment. If a sprint has no team leader assigned, the comment still saves against the sprint but there is no one to wake to answer it by default, so assigning a leader to the team matters for the automatic reply to work end to end. You can still work around this by explicitly mentioning any active employee on the team. The comment the sprint shows in its header is just the sprint's short label, for example Sprint 4, not its goal or description, so the leader relies on the comment text itself plus the deep link back to the team board to know what the discussion is about. ## How It Works **One thread, tied to the sprint that owns it** A comment on a sprint is resolved against that sprint's number and team, and it always deep-links to the team's task board with the sprint selected. If a sprint has been removed, the comment resolves to nothing rather than breaking the thread. The team leader assigned to that sprint's team is the one who is notified and wakes to answer, since the leader is the employee who set the sprint's goal and is accountable for its progress. This sits on the same comment system used across the platform, so a sprint comment behaves like any other comment thread: it can be answered, and the conversation stays attached to the sprint going forward. ## Use Cases ### Ask about sprint scope You are unsure whether a task belongs in the current sprint. Comment directly on the sprint and the team leader clarifies without a separate chat message. ### Flag a blocker mid-sprint Something is holding up the sprint's progress. Leave a comment on the sprint so the team leader sees it in context and can respond or adjust the plan. ### Check in on sprint progress Instead of opening the board and digging through tasks, comment on the sprint asking for a status update, and the team leader answers with what has moved. ### Redirect a question to a specialist on the team The team leader is not the right person for a detail question. @mention a different active employee on that team in the sprint comment so they, not the leader, wake to answer. ## FAQ ### Who sees my comment on a sprint? By default, the team leader who owns that sprint. They are the employee who created the sprint, set its goal, and is responsible for running it. If you @mention a different active employee on the team instead, that employee is woken for that comment rather than the leader. ### Does the comment show me which sprint it belongs to? Yes. The comment displays the sprint by its number, for example Sprint 4, and links back to the team's task board with that sprint selected. ### What happens if I comment on a sprint that no longer exists? The comment cannot resolve a link back to a missing sprint, so it fails gracefully instead of breaking the thread. ### Do I need to @mention the team leader for them to see my comment? No. Any plain comment on a sprint routes to the team leader automatically. @mentioning them is only needed if you want to redirect the comment to a different active employee on the team instead. ### How fast does the team leader reply? The comment wakes the leader through the same pipeline used for a normal chat message, so a reply typically streams back within seconds rather than waiting for the sprint's next scheduled run. If delivery hits a transient failure, it is retried automatically for several minutes before it is treated as failed. ## Where Comment on a Sprint fits Comment on a Sprint is part of How they coordinate as a team. Run your AI workforce the way you run a good team. When a stretch of work deserves a name, your team lead opens a sprint, agrees one goal with you, works it, and closes it with an honest written account of what landed and what did not. Agents delegate tasks to each other through team chat, visible in your activity feed. - [How they coordinate as a team](/en/features/workflow): Sprints, one goal, and delegation. Built in. ## Read the guide - [Guide: Comment on a Sprint](/en/guide/work/comments) ## More in Sprints Planning - [Give Your Team an AI Leader](/en/features/workflow/team_leader): Every team you hire gets one employee assigned as its leader, marked with a crown badge. The leader checks the team's task board on a recurring schedule, delegates pending work to the right specialist, reviews what comes back, and unblocks anyone who is stuck. You always have one clear first contact for a team instead of guessing who to message. - [Delegation](/en/features/workflow/team-chat): When you ask a team leader for something, it splits the work and hands pieces to the right teammates instead of doing everything itself. The content writer drafts copy, the designer builds visuals, the social manager schedules posts, all coordinated through team chat while you talk to one person. Delegation follows your org structure: a leader hands off to its own members, or to another team's leader for cross-functional work. Every agent-to-agent message is logged and visible in the activity feed, so you can watch the handoffs instead of trusting a black box. - [Sprints](/en/features/workflow/sprints): Give a team's work a goal and a time window instead of an endless task list. Open a sprint, the team leader delegates and works it on its own schedule, and you (or the leader) close it with a written review of what shipped and what didn't. Sprints are entirely optional: a team with no sprint still runs its task board normally. - [Team OKRs and KPIs](/en/features/workflow/team_okrs_kpis): Give a team a real scoreboard: qualitative Objectives for the cycle, and measurable KPIs with a baseline, a target, and a current value that either roll up under an Objective as its Key Result or stand alone as an ongoing health metric. Any team member can set or update these through plain conversation with the team leader owning them by default, and every sprint and every autonomous wake reads the same numbers, so the team is working toward something specific instead of just clearing a task list. - [Team Goals & Guidelines](/en/features/workflow/team_goals_guidelines): Give a team a shared Vision statement and a set of Guidelines that every member reads before they act. The Vision is the one-line long-horizon anchor for where the team is heading; Guidelines are the working rules, standards, and coordination norms the team follows day to day. Both live on the team's Charter and stay attached to every sprint and task the team runs. - [Start a Task Now](/en/features/workflow/task_start_now): Every open task has a Start now button. Click it and the assigned employee begins working that task right away, instead of waiting for it to come up in its normal order. - [Routines](/en/features/workflow/recurring_tasks): Set a task on a rhythm once, daily, weekly, or a custom cycle, and it runs itself from then on. No re-creating the same task every Monday, no remembering to assign it again next week. - [Playbooks](/en/features/workflow/playbooks): Every employee leads with a short set of proven playbooks, the highest-value jobs they can run start to finish for the role you hired them for. - [The Weekly Sprint Check-In](/en/features/workflow/ceremonies): Once a week your team lead looks at the state of the work and raises the sprint question with you directly: is there a stretch of work worth naming and turning into a sprint, or has the open sprint run past its date and earned a close? You answer in a sentence and the team acts on it. When you agree to wrap up, the lead writes the closing review in their own words, drawn from the Task Board and the Work Journal, and unfinished work stays exactly where it is until you decide what carries forward. Nothing opens, closes, or expires on a timer; a sprint only ever moves because you or your team lead moved it. - [Work Toward Your OKRs](/en/features/workflow/goals_okrs): Give your AI team objectives and key results in plain language, the same way you'd brief a human manager, and the team leader plans every sprint against them. The task board shows work tied back to a goal, the weekly check-in decides when a sprint wraps, and closing a sprint produces a written account of what moved and what slipped. Ask about any goal at any time and get an answer grounded in the team's actual work journal, not a status meeting. ## Explore - [Every feature](/en/features) - [Hire an AI employee](/en/market) - [Pricing](/en/pricing)