Research preview

Declare your Everything wrapped around the model to make an agent run — triggers, a sandboxed workspace, tools, skills, and guardrails. Bento keeps that harness in version control instead of a dashboard. as code.

Bento runs repeatable coding-agent workflows from your repository. Declare the trigger, agent, sandbox, permissions, and destination once—then run the same pipeline on every matching event.

Works withClaudeClaudeCodexCodexDockerDockerDaytonaDaytona
Coming soonPiPiRenderRenderRailwayRailway
$curl -sSL https://install.getbento.sh | sh
Read the docs

Ecosystem

Works with the stack you already use.

Keep the tools your team trusts. Bento connects the event, agent, sandbox, and destination in one declared pipeline.

One pipeline

A pull request opens. Bento reviews it and posts the result back.

The same declared workflow runs on every matching event—without rebuilding the agent or manually steering the session.

01

Declared in the repo

The trigger, reviewer, permissions, timeout, and destination live beside the code they govern.

.bento/pipelines/pr-review.yaml
02

Run in a fresh sandbox

A pull request opens. Bento clones the repository, assembles the allowed context, and starts the reviewer.

pull_request.opened → reviewer
03

Returned with a trace

The review lands back on GitHub. Bento keeps the run inspectable and exports orchestrator traces through OpenTelemetry.

github.review → trace 9f4e
02

Configure the run

How it works

How it works

.bento/pipelines/pr-review.yamlyaml
trigger:
  github: pull_request.opened
agent: reviewer
skill: pr-review
output:
  github: review
guardrails:
  read_only: true
  timeout: 900
→ 14:02:11 pr.opened · dispatched · ✓ 437.2s

An event you already produce — a PR opening, an issue landing, a cron firing. Pick what kicks off the pipeline.

Choose who runs and the procedure they follow. Same personas, different playbooks — composed per pipeline.

Post back to the surface that triggered it — a review, a comment, a Slack message. The work lands where you work.

Bound the run: a timeout, read-only mode, or an explicit tool allowlist. Start safe, then grant more.

03

Example run

Delivered · trace 9f4e

The review landed. The run is inspectable.

bento trace 9f4ecomplete
Trigger
pull_request.opened
Pipeline
pr-review
Agent
reviewer
Sandbox
ephemeral
Guardrails
read_only · 900s
Output
github.review

Delivered to GitHub

The review returns to the pull request that triggered it.

The trace keeps the originating event, assembled context, tool activity, guardrails, and delivered output together for inspection and replay.

output: github.review

Control what every run knows. Nothing more.

Assemble context from repository files, team knowledge, prior-run notes, and scoped identity. Choose whether each source is injected, mounted as files, available for browsing, or retrieved on demand.

Bento treats Engineering what an agent sees and when — prior state, team knowledge, scoped identity, assembled into each run — rather than hand-tuning a single prompt.Read moreAnthropic as part of the harness—not another prompt to rebuild by hand.

Knowledge

Share team knowledge and practices with agents.

Your wiki, blueprints, and recipes live in the repo. One knob decides how they land in a run — pushed into the prompt, listed for on-demand reading, mounted as files, or left to a tool.

.bento/pipelines/pr-review.yamlyaml
knowledge:
  method: bm25
  delivery: prompt
  topK: 3
  maxTokens: 4000

BM25 retrieval — the top matches are pushed into the prompt as <context> excerpts.

Features

Features

01
pull_request.opened Issue.assigned 0 9 * * 1-5
↓dispatch

Typed triggers

Start from GitHub, Linear, cron, MCP, a URL, or the CLI. Validate declared inputs before dispatch.

02
target: pr-reviewclaude · account-acodex · account-bquota → fallback

Target routing

Route each pipeline through named models and accounts. Fall back when a credential is exhausted.

03
source · .devcontainer
acme/api@main
$ build sandbox · cached ✓

Repo-defined sandboxes

Build each run from the repository devcontainer, a Dockerfile, or a standard image on Docker, Podman, or Daytona.

04
run contractvalidated
timeout900s
read_onlytrue
env[GH_TOKEN]

Guardrails & secrets

Declare timeouts, read-only mode, tools, and environment grants. Compute short-lived secrets only when a run starts.

05
run #12notes
run #13notes
run #14←prior runs injected

Durable context

Per-target workspaces retain the cloned repo, prior results, and bounded history for the next matching run.

06
args:
issue: number
tone: string = concise
from: event.issue.number
URL → validate → dispatch ✓

Typed pipelines

Declare strict inputs, defaults, and event mappings. Invalid work is rejected before an agent starts.

07
orchestrator
↓
reviewsolverelease
typed · authorised · traced

Capabilities & companions

Compose governing skills, reference skills, protocols, and typed specialist operations in one pipeline.

08
trigger
run
turn
tool
replay trace 9f4e ↻

Traces & replay

Inspect every trigger, run, turn, and tool call. Replay an event and preserve the complete attempt trail.

09
prompt preview11.1k / 50k
instructions1.2k
context7.8k
history2.1k

Prompt inspection

Preview the fully assembled prompt and its block-level token budget before spending an agent run.

Own your harness

Own the harness, not the other way around.

The harness is just code in your repo. Switch providers whenever you like, run it on your own hardware, keep your data to yourself. Most agent platforms can't say that — your code on their cloud, your team on their models, your data in their logs.

Nothing to get locked into. Just your harness, your way.

FAQ

Before you wire up a pipeline.

01What is Bento?

Bento is a repository-native orchestrator for coding agents. A trigger starts a declared agent in a sandbox, assembles its context, applies its guardrails, and sends the result to the configured destination.

02Is Bento another coding agent?

No. Bento runs agents such as Claude Code and Codex. It provides the operational layer around them: triggers, sandboxes, context, credentials, guardrails, memory, delivery, and traces.

03What can start a pipeline?

GitHub events, Linear issues, cron schedules, webhooks, MCP calls, and manual dispatches can all start a pipeline. Each trigger resolves to one declared workload.

04Where does the agent run?

Every run uses the sandbox backend declared for the pipeline. Bento supports local Docker and Podman containers, remote Daytona sandboxes, and just-bash for lightweight isolated execution.

05How does Bento control what an agent can do?

A pipeline explicitly declares credential mounts, allowed tools, timeouts, token budgets, and read-only mode. If a credential is not mounted into the sandbox, the agent cannot use it.

06Where do results and run data go?

Results return to the configured output, such as a GitHub review, Linear update, or Slack message. The trigger, assembled context, tool activity, guardrails, and output remain available in the run trace.

07Do pipelines stay in version control?

Yes. Pipelines are YAML files in your repository, beside the code they govern. Changes can be reviewed, tested, and rolled back through the same workflow as the rest of your code.