Comment on a Sprint

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.

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: Sprints, one goal, and delegation. Built in.

Read the guide

• Guide: Comment on a Sprint

More in Sprints Planning

• Give Your Team an AI 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: 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: 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: 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: 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: 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: 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: 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: 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: 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
• Hire an AI employee
• Pricing