The repository is the source of truth.
The instructions that govern software work belong beside the software itself. Pipelines should be reviewed, tested, versioned, and rolled back through the same process as code.
About Bento
Coding agents should work like software, not chat.
The model is only one part of the machine.
Coding agents are excellent inside a session. Give one a repository, a clear task, and enough time, and it can review a pull request, investigate an issue, or prepare a change. But the session usually begins with a person assembling the same pieces by hand: the right checkout, the right context, the right credentials, the right instruction, and the place where the result should go.
That manual setup hides the hardest part of making agents useful. The difficult question is not whether a model can produce code. It is whether the surrounding system can run the same work safely, repeatedly, and visibly whenever the work appears.
Bento exists for that surrounding system. It turns triggers, agents, skills, sandboxes, context, guardrails, and outputs into a declared pipeline. The model can change. The operational contract remains.
Harness as code
Put the operating instructions beside the software they govern.
Infrastructure became dependable when configuration moved out of private dashboards and into version control. Agent workflows need the same transition.
A Bento pipeline is a small file in the repository. It states what event matters, which agent and skill run, what the sandbox may access, and where the result returns.
That makes the workflow legible to the team. A reviewer can see when it runs. An operator can see what it can touch. A future maintainer can understand why the automation exists.
More importantly, the pipeline can evolve with the code. The workflow that reviews a system lives under the same history as the system itself.
Principles
The shape of dependable agent work.
Work begins with an event.
A pull request opens. An issue is assigned. A schedule fires. Bento turns the event into a bounded workload without asking a person to reconstruct the task in a chat window.
Isolation comes before autonomy.
More capable agents need clearer boundaries. Every run starts in a declared sandbox with explicit credentials, tools, budgets, timeouts, and destinations.
Context is engineered, not pasted.
Repository files, team knowledge, prior-run notes, scoped identity, and retrieved material should arrive deliberately. The model should see what this run needs and nothing more.
A run should explain itself.
The event, assembled prompt, tool activity, guardrails, attempts, and delivered output remain inspectable. Repeatability without observability is just a faster way to lose the plot.
The model is replaceable. The harness is yours.
Claude and Codex are runtimes, not foundations. Teams should be able to route work between providers, change models, and move infrastructure without rewriting how the work operates.
Teams ready to move beyond manually steered sessions.
Bento is for engineers who already know that coding agents can do valuable work and now need that work to happen more than once. It is for teams turning a good prompt into a reviewed process, a local experiment into shared infrastructure, or a single agent into a set of bounded specialists.
It is deliberately vendor-neutral. Use Claude, Codex, Docker, Podman, Daytona, GitHub, Linear, Slack, or the observability stack you already operate. Bento connects those pieces without pretending to own them.
The goal is simple: when useful software work appears, the right agent should be able to pick it up, operate inside known boundaries, return the result, and leave a trace a human can understand.
Research preview
The harness is becoming the product.
Bento is an active research preview. The work now is to make agent pipelines easier to declare, safer to run, richer in context, and simpler to inspect without hiding the machinery that teams need to trust.