# Bento

## Docs

- [Authentication](/authentication): The bento daemon uses bearer token authentication. Tokens are issued on the server where the daemon runs, then configured on each client machine where your coding agent (Claude Code, Codex, pi) connects from.
- [CLI Reference](/cli): The `bento` CLI manages the daemon lifecycle and provides operational visibility.
- [Configuration](/configuration): Bento reads two config layers when the daemon starts:
- [Getting Started](/getting-started): Bento is an opinionated framework for running AI agents in response to events. It provides the scaffolding and plumbing to respond to a range of triggers and run agents in ephemeral containerised sandboxes, with no human in the loop.
- [Inspecting Runs](/inspect): Every pipeline run leaves a paper trail across three surfaces: the **triggers**
table (the entry point), the run's **trace** (envelope + per-phase tasks), and
the agent's **logs** (raw stdout / parsed turns). This page walks through how
to navigate them when you need to know what happened.
- [Public Access](/public-access): The daemon binds to `127.0.0.1:7890` by default. To accept GitHub webhooks or reach the daemon from another machine, expose it through a tunnel.
- [Troubleshooting](/troubleshooting): Checks the daemon process, database connection, `cloudflared` / `tailscale` availability, and webhook reachability. Most setup problems show up here with a plain-text description.
- [Filters](/triggers/filters): All event-based triggers (`github`, `linear`, `webhook`) support a `filter:` block. Filters let multiple pipelines subscribe to the same event type with different criteria — only the pipelines whose filters pass are enqueued.
- [GitHub Trigger](/triggers/github): The daemon accepts GitHub webhooks at `/webhooks/github` and the alias `/events`. Every request is verified with HMAC-SHA256 against the `webhooks.secret` in `daemon.yaml` — unverified requests are rejected.
- [Triggers](/triggers): A trigger is what causes a pipeline to fire. Each pipeline declares exactly one `trigger:` block in its YAML file. When the daemon receives an event that matches a pipeline's trigger (and passes any filters), it enqueues a run.
- [Linear Trigger](/triggers/linear): The daemon accepts Linear webhooks at `/webhooks/linear` (or any request carrying a `linear-event` header).
- [Manual Trigger](/triggers/manual): Setting `trigger.manual: true` makes a pipeline fireable on demand:
- [Schedule Trigger](/triggers/schedule): Schedule triggers use a standard 5-field cron expression evaluated by [Graphile Worker](https://worker.graphile.org/).
- [Generic Webhook Trigger](/triggers/webhook): Any HTTP POST to `/webhooks/{name}` creates a generic webhook event where the event string is the path segment `{name}`.
- [The Case for a Layered Event Matcher](/architecture/event-matcher-layered-architecture): **Design proposal — not yet implemented.** This documents the intended architecture for multi-repo routing. The current flat matcher (`matchPipelines()`) is still in use. Ground truth: `services/daemon/src/{webhook,pipeline,context}.ts`, `packages/config/src/index.ts`.
- [MCP Protocol Surface](/architecture/mcp-protocol-surface): The daemon currently exposes itself over MCP as a thin RPC layer: a handful of tools (`create_workload`, `submit_invocation`, `get_invocation`, `cancel_invocation`, `close_workload`) plus agent and skill descriptors as resources. This is a **CLI-shaped MCP server** — every interaction is a request/response tool call, and the host has to poll to observe long-running work.
- [Prompt Composition](/architecture/prompt-composition): How bento assembles the prompt an agent receives — which file or mechanism owns which part, and which message channel each part lands in.
- [Runtime Wrapper](/architecture/runtime-wrapper): Standardised metric collection across pi, claude, and codex runtimes.
- [Skill Evolve](/architecture/skill-evolve): Automated improvement of bento skills and agent prompts using session history as training signal.
- [Company Brain](/architecture/vision): The biggest blocker to AI automation of companies is no longer the models. Now the blocker is the **domain knowledge**.
- [Workload Architecture](/architecture/workload-architecture): **Phase 1 (Hono server) is complete.** Phases 2–6 (workload lifecycle, task submission, streaming, secret store, KB integration) are planned but not yet implemented.