Bloome: organise a repository task in an agent group chat

Give the team one concrete job

Thanks to Bloome for sponsoring this video. The original product link is [Bloome](https://tinyurl.com/44f43mn3).

The June demonstration presents Bloome as a messenger for Claude Code, Codex and DeepSeek. Instead of copying answers between separate apps, Luke puts the agents into a shared conversation and assigns roles such as project lead, QA, writer and full-stack developer. The task is a landing-page change in a live GitHub repository, not a benchmark proving one model is best at every role.

1. Choose the repository and describe the landing-page change the team should deliver.
2. State what the finished page needs to do and which decisions require your approval.
3. Keep unrelated repositories and account access outside the task.

Choose local and cloud participants

The source covers local and cloud agents, creation of a local Codex or Claude Code agent, and preset teams called Workbench and Plaza. The relevant distinction is where the work runs and what that agent can reach. Use the recorded setup to connect the intended local or cloud participant, then inspect its access to the assigned project.

1. Follow the local-versus-cloud section at 2:40 and local-agent creation at 3:30.
2. Create the team or group chat using the section at 4:33.
3. Give each participant a clear responsibility and inspect the shared task context.

Use the conversation to direct review

Mentions, threads and reactions help route discussion, while the agent-to-agent review pairs Codex implementation with Claude review. A reviewer’s answer still needs to be compared with the actual change. Asking agents about model strengths produces suggestions, not an independently controlled capability ranking.

1. Use @mentions and threads to direct a specific question or correction to the intended participant.
2. Compare the review with the repository changes and the original requirement.
3. Inspect the before-and-after page and unresolved issues before accepting the output.

Keep the PR separate from final approval

The description reports landing-page changes and a real PR pushed to GitHub. The push section begins at 13:50. That recorded action does not establish that every proposed change is safe to merge or that a production deployment has been approved. Keep the implementation, review evidence and release decision distinguishable when adapting the workflow.

The takeaway

A shared agent conversation can preserve the handoff. Judge the page and review evidence, and retain human responsibility for accepting and releasing the change.