Task and Sprint Planning

Height holds a team's tasks, grouped into lists or sprints, with statuses like open, in progress, and done that reflect where each piece of work stands. A Beam agent can read a task's status and due date, and apply the team's rule for what counts as stalled, such as no change in five working days. When a task matches that rule, the agent notes it in a summary sent to the project lead ahead of planning. It does not reassign tasks or change priorities. Deciding whether a stalled task needs a new owner or deadline, or should be dropped, stays with the team.

Pull Request Linked Status

Height can link a task to a pull request in a connected code repository, so the task's status reflects what stage the code change is at. A Beam agent can read that pull request's state, such as opened, in review, or merged, and update the task's status to match, the same update a developer would make by hand. It applies only the mapping the team already defined between pull request states and task statuses. If the pull request and task fall out of step in a way the mapping does not cover, the agent leaves the status alone and flags it for a human.

Team Collaboration on Issues

Comments and updates on a Height task often carry the context a team needs to understand why something changed or what is blocking it. A Beam agent can read new comments on a task and, where a comment matches an approved pattern, such as a customer reporting the same bug reported elsewhere, post a note linking the two tasks together for the team to see. It does not merge or close tasks on its own. Where a comment raises something ambiguous, like a customer request that might change scope, the agent leaves the task open and routes the comment to a human for a decision.