How to share AI coding agent progress with your team
On this page
What outcome are we working toward? What is happening now? What evidence is ready? Who needs to do what next?
An agent conversation is useful to the person directing the run. A teammate deciding whether to start dependent work needs something shorter: the current task, the state of the implementation, and a clear next action. Pasting a long transcript moves the work of finding those answers onto the reader.
Build the handoff around the task instead. Keep the brief stable, record meaningful changes in progress, and attach review evidence when it exists. The example below shows a handoff for a display-name validation change.
Share decisions and evidence, not just activity
“The agent is working” is accurate but rarely actionable. “Validation is implemented; the whitespace-only test fails; the owner is correcting it before review” tells a teammate what they can rely on.
| Signal | Useful update | What it enables |
|---|---|---|
| Outcome | Prevent empty display names from being saved | Understand the purpose without reading the prompt history |
| Current state | Implementation complete; validation tests passing | Decide whether dependent work can begin |
| Evidence | Changed files, actual test command, PR link | Inspect the result rather than trust a summary alone |
| Next action | Reviewer checks the form’s error state | Make responsibility explicit |
Turn count and token usage can help explain an execution, but they are not completion percentages. Avoid presenting a busy run as nearly finished when no acceptance check has passed. A failed test or unanswered question often matters more than another activity update.
Separate team visibility from local execution
Agentboard’s Team workspace shares tasks, projects, and execution progress. Each person configures the local repository directory on their own machine. Local directory paths, Codex thread identifiers, and responses to local approvals belong to that execution environment.
This distinction matters during a handoff. A teammate can see the task’s progress without being the person able to answer an approval prompt on your computer. Do not instruct them to solve a local permission request merely because the board is shared. Name the person running the agent and make the pending decision explicit in the task description.
Moving a task through MCP, the API, or a teammate’s board does not remotely start Codex on another machine. On Team, dragging a task to In Progress in the local app can start a local execution. Use the task workflow guide for the setup and behavior of these actions.
Use a short handoff with verifiable details
Ask the agent for a draft at a meaningful checkpoint, then check the summary against the diff and test output. Put the result in the task description or pull request, according to your team’s practice. The template is a writing aid; it does not imply Agentboard sends a report automatically.
Task: [identifier and intended outcome]
State: [implementing / needs input / ready for review]
Result: [what changed, in one or two sentences]
Evidence: [PR or diff; exact checks run and their results]
Not verified: [checks not run, unavailable environment, remaining assumptions]
Dependency: [what another task can or cannot rely on yet]
Next action: [named owner or reviewer and one concrete action]For example: “The display-name validator now rejects blank input. Unit tests pass. The browser flow has not been checked. The reviewer should confirm the error is displayed before the form task is marked complete.” That update is more useful than “done” because it separates verified behavior from remaining work.
Keep credentials and unrelated private context out of shared summaries. Include the command and outcome needed for review; do not paste environment variables or an entire log when a focused excerpt is sufficient. Link the artifact the reviewer actually needs.
Make the pull request the review destination
A board card signals that review is needed. The pull request should contain the concrete change and evidence. Connect the Agentboard GitHub App installation, set the project’s remote repository, and ensure the PR is associated with the task. These are prerequisites for automatic status updates.
A linked non-draft PR can advance the task to In Review; a merged PR can advance it to Completed. Draft PRs do not advance the task to In Review. The status transition does not prove that a test ran, so preserve the verification details in the review artifact.
- Compare the diff with the original acceptance criteria.
- Check that the reported commands actually ran and passed.
- Inspect changed behavior that automated checks do not cover.
- Record any required follow-up before merging.
For a correction, send a precise follow-up to the existing execution: the observed behavior, expected behavior, and check to repeat. Keep the review conversation connected to the original task rather than losing it in a separate agent session.
Make blocked work visible enough to resolve
If execution pauses for input, identify the decision and the person who can make it. “Waiting for input” becomes useful when followed by “the person running Codex must approve the repository command” or “the feature owner must choose the validation rule.” Do not invent a progress estimate while that decision is pending.
When a teammate takes over, share the task brief, branch or PR, verification results, and unresolved choices. They need to configure their own local repository and start or continue work in their own environment as appropriate. A shared task is not a promise that a live local agent session can transfer between computers.
Set up one complete team handoff
Use the quickstart to run a small task, then write a handoff with the template above. Have a teammate use it to review the actual diff. If they need another explanation, add the missing fact to the task or review artifact.
Check download availability and Team plan details. To read or manage board tasks from another compatible AI client, use the MCP connection commands.