Running work
How work moves from prompt to merged change, and the three ways it starts.
Beeuni runs work inside a session, with its own branch and sandbox. Changes to project files can be reviewed and merged into the default branch through a change request (CR). This page explains that workflow and the three ways to start a session.
Sessions
A branch and a sandbox for one unit of work.
Change requests
The reviewed merge back to the default branch.
Runtime
Env vars, tokens, and the sandbox image a session runs in.
Notifications
Who hears about a finished turn, a question, a share, or a failing trigger. Behind a feature flag.
What happens when a session starts
- Beeuni creates the session row and cuts a branch from the default branch. The branch name is the session id.
- Beeuni resolves a sandbox image: the default image, or your own
.beeuni/Dockerfileif the manifest declares one. - The session starts with the project files in
/workspace. - The agent works. It uses secrets through the environment variables Beeuni sets, then commits and pushes to the session branch.
- The agent opens a change request. You review it and merge it — the only way work reaches the default branch.
Three ways work runs
A session starts one of three ways.
| Mode | How it works |
|---|---|
| On-demand | You ask in chat and get the result now. |
| Human-assisted | The agent works and checks in with you for the calls that matter. |
| Automated | A trigger — a schedule or webhook — starts the session end to end. |
Related
Projects
A git repo with a manifest.
Agents
A markdown persona with scoped tools.
Models
Which model a session uses, and who pays.
Triggers
Schedules and webhooks that start sessions.
Connectors
Scoped reach into external apps.
Slack & channels
Chat surfaces that start sessions.
Computers
Machines distinct from session sandboxes.
Accounts
Principals, roles, and assignments — who can do what.