Your team’s coding agents, working in the open.
Describe an outcome from the board, the command line, or a Slack or Discord thread. An agent picks it up in its own sandbox, with no more permission than you hold, and the whole team can watch it work.
Add CSV export to audit
Working/api/v1/audit.csv and streams rows, so large logs don’t load into memory. Tests pass. acme/api#418 · Add CSV export to the audit logAgent work, moved out of one person’s terminal
Most agent work happens on someone’s laptop and stays invisible until a pull request appears. Hyperbeam moves it one level up, where the whole team can see it.
- 1
Describe the outcome
Anyone on the team writes a brief the way they would brief a colleague: on the board, at the command line, or by mentioning the bot in Slack or Discord. Pick the repositories, the agent, the model, and what it may do.
Fix the flaky checkout test. Don’t change the payment mocks. Done when CI passes ten runs in a row.acme/webClaude Codegithub:open_pr - 2
An agent works in its own sandbox
Each session gets a fresh, locked-down sandbox with your project’s toolchain. Every tool call, file edit and blocked request is streamed to the page as it happens, and when a decision is yours, the agent asks.
npm test -- checkoutAllowedgithub: push to hyperbeam/fix-checkout-9a41e07c - 3
The team reviews together
Workstreams move from scoping to building to review. Answer an agent’s questions, reply to it, add another one, discuss it with the team, and merge the pull request when it is right.
ScopingBuildingIn review
Everything around the agent, in one place
Hyperbeam doesn’t replace your coding agent. It gives it a place to work that your team can see, steer and trust.
A shared board
Every workstream, the agents on it, what each is doing right now, and the pull requests they produced. Live, for everyone.
From Slack and Discord
Mention the bot to start an agent, reply in the thread to direct it, and answer its questions with a button. Each person acts as themselves.
It asks when it needs you
Agents ask when a decision is yours, and you hear when one of yours asks, finishes or fails: in Hyperbeam, or by direct message.
A conductor
One agent scopes a request, starts worker agents across repositories, and is told as each reports back.
Any harness, your toolchain
Claude Code, Codex, Gemini CLI, OpenCode or your own ACP agent, on the model you pick, in an image with your project’s compilers and tools.
Skills and team notes
How your team writes migrations, runs tests and reviews code, in the open SKILL.md format, and notes agents add to as they learn.
Agents never hold your GitHub or tool credentials
A sandbox holds a run token that identifies its session, revoked the moment the session ends, and the model API key its agent needs. Everything else it does outside the sandbox goes through Hyperbeam, which checks it, adds the credential, and records it.
- 14:02:19AllowedGemini CLI for Jordan ·
linear: create issuelinear:write - 14:02:16BlockedGemini CLI for Jordan ·
push hyperbeam/fix-nav-0c7d2e19Jordan can’t write to acme/web - 14:02:13AllowedCodex for Priya ·
npm installallowlisted - 14:02:10BlockedOpenCode for Alex ·
POST pastebin.comnot on the allowlist - 14:02:07AllowedClaude Code for Priya ·
push hyperbeam/audit-csv-3ff6c49bgithub:write
Permissions belong to people
An agent can do only what the person who started it may, per repository. Grants are checked against what that person holds now, so removing a permission takes effect on their running agents immediately.
- A worker started by a conductor holds at most what the conductor holds.
- Anyone can watch a session. Only people who hold its grants can direct it.
- Agents read the web through the gateway, by default only at URLs a person, a search or an earlier page gave them, so a hostile page can’t get them to send your code out in a URL.
- A custom MCP server’s tools stay hidden until an admin approves each one, and are hidden again if the server changes one.
- Integration credentials are encrypted at rest and never enter a sandbox.
| Grant | Lets an agent |
|---|---|
| github:read | clone registered repositories; read issues and pull requests |
| github:write | push branches (not the default branch); comment; create issues |
| github:open_pr | open pull requests |
| github:merge_pr | merge pull requests; push to the default branch |
| gitlab:read … merge_pr | the same four on GitLab, where pull requests are merge requests |
| web:read | read public web pages a person, a search or a fetched page pointed it to |
| <connection>:read · write | use a connected service’s read or write tools, such as linear:write or sentry:read |
Turn a good request into a button
A workflow is a saved, parameterised launch: which repositories, skills and permissions, and what to ask for. Anyone can run it from the board by filling in the blanks, or from CI with the command line.
name: ship-feature
description: Build a feature across the API and the web app
role: conductor
repos: [acme/api, acme/web]
skills: [house-style]
grants: [github:write, github:open_pr, linear:read]
inputs:
- name: feature
description: What to build, and how you will know it works
prompt: |
Build this feature: {{feature}}
Scope it first, then delegate each repository's changes to a worker.
Open a pull request per repository and report the links.hyperbeam run "Fix the flaky checkout test" --repo acme/web --model sonnet --follow
hyperbeam workflow ship-feature -i feature="CSV export" --follow
hyperbeam ls
hyperbeam send 3ff6c49b "Also update the changelog" --follow
hyperbeam stop 3ff6c49bOne Helm chart. Runs where your code does.
Open source under the Apache 2.0 license, with images published for amd64 and arm64. Install the chart on any Kubernetes cluster, on one EC2 instance with the Terraform module, or on a Raspberry Pi.
helm install hyperbeam deploy/helm/hyperbeam \
--namespace hyperbeam --create-namespace \
--set masterKey="$(openssl rand -base64 32)" \
--set publicUrl=https://hyperbeam.example.comYour infrastructure, your data
The control plane and Postgres run where you put them. Nothing leaves except what your agents are allowed to reach.
Locked-down sandboxes
One pod per live session, non-root, no service account token, no added capabilities, under the restricted Pod Security Standard.
Idle sandboxes go away
Sandboxes are torn down after 15 idle minutes. A message wakes the session in a fresh one, from the branch it pushed.
Bring your own keys
A team API key per harness, or each person’s own. Encrypted at rest with a master key you hold, or one wrapped by AWS KMS.
Tested end to end
End-to-end tests run a real server and real runners driving a scripted agent, against stand-ins for GitHub, GitLab, MCP servers, Slack and Discord. The Helm chart is checked by hand on Kubernetes.
Testing and limits- Permissions, invites, roles and immediate revocation
- The full session lifecycle through the runner and ACP, including resume
- The git proxy with default-branch protection; pull and merge requests
- Conductors, questions and notifications
- MCP connections, OAuth sign-in, web access and the egress allowlist
Because it’s the best move.
Give your agents a place the team can see.
Run it on your laptop and connect your first agent, then install it for the team.