Skip to content

Platform

One platform. No bolt-ons.

Everything a team needs around the agent, in the same product, on every device.

Everything around the agent, at a glance

Agents

Named personalities with their own prompt, skills and tools. Hire one from the library or write your own.

Read moreabout Agents

Each one above is a section of this page. Two more have a page of their own.

Agents

Named personalities with their own prompt, skills and tools.

An agent is a name and a handle, a system prompt, a set of specialties, and the skills and tools it is given. Mention one in a workspace's chat to put it to work, or give it recurring work on the Schedule.

Hire from library

A catalogue of ready-made personalities:

  • project manager
  • team lead
  • full-stack engineer
  • sales
  • growth
  • SEO
  • GEO
  • content
  • design
  • QA
  • security
  • DevOps
  • data

Hiring one copies it into your organization, so tuning its prompt afterwards is yours to do. An improved version of a persona reaches new organizations rather than overwriting an agent you have already adjusted.

Tools are picked per piece of work

MCP tools are registered separately and chosen per task rather than attached to the agent. The same SEO specialist can have web search on the weekly crawl and nothing on the monthly summary, without two copies of the agent. Only the tools a schedule lists exist for that execution. The restriction is real, not advisory.

A fresh box, booted as the persona

When a scheduled task runs as an agent, its prompt is written as the box's standing instructions and its skills into the box's skills directory. The work never goes to the agent's own long-lived container.

That container accumulates state from everything the agent has ever done, and a recurring task's continuity is supposed to come from its briefing, where it can be read and switched off, not from a leftover working directory.

Recurring work, each run in a fresh box, with a memory of what earlier runs found.

A scheduled task is recurring work. Each execution gets its own box, is handed the task's description, and reports back as it goes. Once, every day, selected weekdays, or every N days.

  • Send a task to the agent

    A prompt, in a fresh box. It may name an info-only workspace, in which case the prompt goes into that workspace's box, repos checked out and context to hand. That is what “audit this every Monday” is.

  • Send a task to a named agent

    The same dispatch, with the box booted as that persona and restricted to the tools you tick for this task. An unticked tool does not exist for that execution.

  • Post a chat message

    No box at all. A message into a workspace's chat on a schedule.

  • A watchdog

    A task that has not reported itself started within 15 minutes, or finished within 60, is marked failed and an admin is told. A run that silently never happened is the failure this exists to catch.

Continuity: why run 40 differs from run 1

Scheduled work used to go nowhere, and the reason was structural. Every execution got a brand-new box, the box was destroyed afterwards, the brief told the agent to treat the request as standalone, and nothing a run learned was written anywhere a later run could find. Run 1 and run 40 were the same run with a different date.

Now a task publishes under subjects and reads them back. On every dispatch DevBench assembles a “what previous runs of this task already established” section, the last few executions with their outcomes and the documents they published, and folds it into the prompt. The closing line says the opposite of what it used to: this is one execution of a recurring task, continue from what is above, and leave something the next one can continue from.

The Continuity tab answers, in plain language, why a task is not accumulating anything: seventeen runs and zero documents; continuity switched off; runs lost to a signed-out session; runs closed by the watchdog rather than reported. Consolidate folds a task's whole history into one digest document that supersedes the previous digest.

Scripts kept alive in a box, restarted when they exit.

A poller, a sync, a queue reader: something that should keep running in a workspace's box whether or not anyone has the workspace open.

DevBench restarts a watcher that exits and posts to the workspace's chat when it does, so a watcher that quietly died is not something you find out about a week later. It can run continuously, on an interval, or at fixed times of day, with everything that box has.

Its script, its output and its run history are all on the page. The logs are the box's own stdout; the run history is start-to-exit per run, which is what tells you whether “it is running” means running or crash-looping. Edit the script and a running watcher restarts with the new one. Stop takes it out of service until you start it again.

devbenchinside the box

  • $ devbench watcher add <name> --script-file <path> --interval <n>

    Create one from inside the box.

  • $ devbench watcher list

    This workspace's watchers and their status.

  • $ devbench watcher logs <name> --tail 100

    The watcher's own output.

  • $ devbench watcher runs <name>

    Its start-to-exit run history.

  • $ devbench watcher edit <name> --script-file <path>

    Change its code or schedule.

Shared skills with named credential profiles.

A tool is a script the whole organization shares: a scraper, a query runner, a headless browser, a research helper. Any workspace's agent can run one, so a capability written once is available everywhere instead of being re-implemented per box.

One tool, a profile per environment

Each tool carries a base environment and any number of named credential profiles. A profile is a set of variables under a name, staging, prod, so the same tool runs against different environments without a second copy and without pasting keys into a prompt.

Secret values are stored encrypted and never returned by the API; a run picks a profile with --env, and one-off values can be added at the call site.

Written once, run by any workspace's agent

The one-line description you give a tool is what an agent reads when deciding whether to use it. Pick the interpreter, python3, bash, and so on, paste the script, and any workspace's agent can run it.

devbenchinside the box

  • $ devbench tools list

    The team's shared tools and skills.

  • $ devbench tools show <name>

    A tool's info, env vars and profiles.

  • $ devbench tools run <name> --env prod -- <args>

    Run one under a named credential profile.

Releases

One version across every repo.

A release ships a chosen set of repositories together, under one version. Which repos are in it is a setting; a repo nobody added is not released.

It runs entirely through your own provider token. No container is involved.

  1. 1

    Gate

    For every tracked repo, the source branch must be fully merged into the gate branch. If one is not, the release is blocked and named; you run that promotion first.

  2. 2

    Cut

    release/<version> is branched from the source in each repo.

  3. 3

    Record

    The commits that are actually shipping are written into the changelog. A commit lands even where a repo has no changes, so the protocol is uniform.

  4. 4

    Ship

    The release branch is merged into production.

  5. 5

    Tag

    The release branch is tagged v<version>.

  1. sourcefirst stage
  2. gatebefore production
  3. productionlast stage

Three branches carry a release, and all three are read from your git flow rather than named here: source is the flow's first stage, production its last, and the gate the stage immediately before production. A flow with fewer than three stages has no distinct gate, so the check passes trivially. A single-stage flow cannot release at all, and says so.

Show commits in this release on a past release lists exactly what shipped. Resume any pending/failed repos picks up one that did not finish.

One record of everything that happened to you.

A workspace finishing provisioning, an agent finishing a change, a mention, a merge that landed, a deploy that failed, a backup that ran partial. Newest first, grouped by day, and pushed to your phone.

  • Markdown renders

    A notification written as a proper post renders as one, with its first line as the row title. Open workspace takes you to what it is about.

  • Two channels on the phone

    Chat and Inbox arrive on their own Android channels with their own collapse keys, so an assignment is not replaced on your lock screen by the next chat message from the same workspace.

  • Quiet means quiet

    A workspace you have not subscribed to on the phone does not buzz: not for its messages, and not for its assignments. The in-app Inbox and the unread badges are unaffected.

  • Owners hear what only owners can fix

    A cloud account whose credentials stopped working, an integration that failed its check, a backup that could not reach a box. These go to owners, throttled per thing, so a broken account does not become wallpaper.

Team

Owner, maintainer, member. Grown by invite code, not sign-ups.

Access is a person's role plus a workspace's assignees. The rule is applied to the query itself, so no screen can leak a workspace by forgetting a check.

  • Owner

    Workspaces they reach
    Every workspace in the organization
    Also
    Roles, invite codes, API keys, organization settings

  • Maintainer

    Workspaces they reach
    Every workspace in the organization
    Also
    Chooses which show on their own board

  • Member

    Workspaces they reach
    Only the workspaces they are assigned to, plus any they created
    Also
    Nothing more

Can manage deployments is a separate flag

No role implies it, not even owner. “Owners and maintainers” would make “who can deploy to production?” a question with two answers that drift apart, and it would bind trusting somebody with infrastructure to a decision about workspace visibility. A maintainer who reaches every workspace is not automatically the person you want spending money in the AWS account. An owner may grant it to themselves; that is how an organization gets its first person who can deploy to production.

It gates Apps and run recipes, databases and their seeds, the organization's deploy settings, cloud accounts, where an environment points and its update script, and deploying or stopping anywhere but DevBench compute. Reads are gated too. Two things stay open to everybody: previews on DevBench compute, and an environment's URL, login and notes.

Invite codes

There is no self-serve organization. A code is how somebody joins: it carries the role they join as, and can have an expiry and a use limit. No emails are involved; you hand over the code. You cannot change your own role, which is what stops an organization losing its last owner by accident.

The defaults every workspace inherits.

Eight tabs, grouped by what each decides. Each workspace has its own settings on top: General, Automation, Git & merging, Security, Notifications, and a Danger zone kept apart from the routine toggles on purpose.

  • AI

    The agent login every workspace shares, and the organization's standing instructions: the stack, the review etiquette, the library that must never be used again. They are written into every workspace's instructions under a managed heading and rewritten wholesale on each push, so editing the text converges every box and clearing it removes the rule. Saving and Apply to all workspaces are separate, deliberate acts.

  • Workspace defaults

    What every new workspace's container is built with, on top of the built-in language toolchains. Switching an extension off uninstalls it from workspaces created afterwards.

  • Board stages

    The columns: rename, reorder, add, delete. The default column is also the one whose workspaces may keep a box running. A stage still holding workspaces cannot be deleted, and the refusal names it and its count.

  • Integrations

    Your personal GitHub and GitLab tokens, used to import repos and let workspaces push.

  • Notifications

    Where events from outside DevBench arrive, an inbound webhook, and how they reach the team.

  • Git flow

    An ordered list of stages, each with a key, a label and a branch. The first is what work is cut from; the last is production. Every branch in the flow is protected from direct agent pushes.

  • Backup

    Below.

  • App

    Versions: the desktop app, and the devbench CLI inside your workspace boxes.

A few hundred kilobytes that hold everything you configured.

Every workspace's repos already live at GitHub or GitLab. Everything else, the workspaces, the git flow, the environments, the deploy recipes, the tools, the agents, the watchers, the schedules, exists in one database, and re-entering it by hand is days of work nobody has a record of.

  1. 1

    Push

    Every eligible workspace's repos are committed and pushed to their own branches, the same call the Push button uses. A stopped box can be started for it. An info-only workspace is skipped: “nothing is ever pushed from here” is a promise, and a backup is not a reason to break it.

  2. 2

    Record

    The configuration is serialized to gzipped JSON, each repo appearing as the branch and commit its work was pushed to. The repository contents are never in the file.

That ordering is what makes the size claim true: a hundred workspaces come out as a few hundred kilobytes rather than tens of gigabytes, small enough that every backup is kept. What is deliberately not in it, git objects, container images and volumes, and every kind of history, is recorded as a count, so a file opened a year from now says plainly what it is not.

Secrets are off by default. Turned on, each travels as the ciphertext already in the database; the plaintext is never written. A backup with secrets is only usable on an install holding the same encryption key, which is what makes it safe to leave one in a bucket.

Restoring

The dry run is the default, and it is performed with the same walk as the real restore, inside a transaction that is thrown away. It is also the diff: comparing two DevBench installs is exactly “restore this file into that org and tell me what moves”, answered in both directions.

  • Nothing is ever deleted.

    Something the target has and the backup does not is reported and left alone.

  • Merge is the default.

    Existing rows are untouched unless you ask for overwrite; restoring twice changes nothing the second time.

  • Code is not restored, because it was never taken.

    A restored workspace points at the same repository and branch, and its box is provisioned as normal.

What cannot come back is reported rather than skipped in silence: user accounts, other people's git tokens, the inbound webhook secret, media file bytes, and, under a different encryption key, every credential. A wrong key is detected up front by test-decrypting one value, so it is reported once, and the rest still restores.

devbenchon your machine

  • $ devbench backup

    Run a backup. Download configuration in the app answers immediately, skipping the push.

  • $ devbench backup list

    Past backups, newest first.

  • $ devbench backup diff <file>

    What restoring this file would change, in both directions.

  • $ devbench backup restore <file> --apply

    Actually restore it. Without --apply it is the dry run.

The same account, everywhere.

The web app, the desktop app, the mobile app and the command line all talk to the same server with the same account. There is no mobile-only backend and no desktop-only API; each is a client of the DevBench you already run.

Web

The full app. Everything on these pages, and the editor.

The board with its three views; each workspace's Overview, Chat, Tasks, Changes, Git, Deploy, Media, Collaboration and Settings tabs; the shared editor and the session beside it; Docs, Merge requests, Releases, Agents, Schedule, Watchers, Tools, Cloud, Apps, Inbox, Tasks for you, Team, Usage, Monitor, Settings and API keys. And a Guide, one article per topic, each with a recorded walkthrough made by devbench video.

Opening a workspace gives you a browser-based VS Code with every repo cloned and checked out on the workspace's branch. It is the same container for everyone in the organization: two people opening the workspace are in one editor and one terminal session, not two copies.

Invite only

We set your organization up with you.

Tell us about your team and the repositories you would bring; we reply within a working day.

Request accessSee the plans