Baudbot

Always-on, multiplayer dev-assistant for eng teams - write code, act on alerts, and more

💬 Join us on the Modem Discord: https://discord.gg/MKkTFvQ4

Baudbot runs a persistent AI control agent on Linux, connected to Slack, with worker agents that take tasks from request to PR. It works on real repositories with real tools (git, test runners, Docker wrapper, cloud browser automation), keeps persistent memory, and reports progress back in-thread.

Built for teams that want autonomous execution speed without giving up operational control.

⚠️ WARNING: Baudbot is in alpha/early testing. If you use this, prepare to fix things. It might burn tokens. Be careful!

What Baudbot does

• Shared Slack interface for the whole team. Anyone in allowed channels can hand work to the same agent system.
• Always-on response and fast handoffs. The control agent stays live, triages work instantly, and spins up task-scoped coding agents.
• End-to-end coding loop. Branch, code, run tests, open PR, watch CI, push fixes, report status.
• Linux-native execution. Agents can run the same project commands your engineers run (including guarded container workflows).
• Persistent team memory. The system learns repo quirks, recurring fixes, and collaboration preferences across restarts.
• Self-improving operations. Agents can update non-security skills/extensions and propose upstream improvements via PRs.

Team agent, not a personal copilot

Baudbot is designed as shared engineering infrastructure, not a single-user desktop assistant:

• multiplayer by default (Slack threads, shared todos, multiple sessions)
• persistent service, not one-shot chat
• autonomous task execution with humans in review loops
• admin-managed runtime with deployment + rollback controls

Requirements

System package dependencies (installed by baudbot install): git, curl, tmux, iptables, docker, gh, jq, sudo.

Quick Start

curl -fsSL https://raw.githubusercontent.com/modem-dev/baudbot/main/bootstrap.sh | bash
baudbot install

baudbot install has a guided config flow: pick an LLM provider, choose Slack integration mode (managed broker vs custom app), then opt into optional integrations (Kernel/Sentry).

After install:

# deploy latest source/config to runtime
sudo baudbot deploy

# start the service
sudo baudbot start

# check health (includes deployed version + broker connection/health status)
sudo baudbot status
sudo baudbot doctor

Upgrade later:

sudo baudbot update

Connect/talk to the control agent:

sudo baudbot debug

Install with a specific pi version (optional):

BAUDBOT_PI_VERSION=0.52.12 baudbot install

Slack broker registration:

sudo baudbot broker register

Need to rotate/update a key later?

sudo baudbot env set ANTHROPIC_API_KEY
# or: sudo baudbot env set OPENAI_API_KEY sk-... --restart

See CONFIGURATION.md for required environment variables and secret setup.

The Slack broker (optional)

The primary way to talk to Baudbot remotely is through Slack.

You have two choices:

1. Create/manage your own Slack app (hard)
2. Use our hosted Slack broker + control plane at https://baudbot.ai (easy) [ALPHA]

What the Slack broker does:

• One-click install to connect your Slack workspace to your Baudbot instance
• Broker forwards messages to your Baudbot instance (encrypted)
• Broker strips PII and sensitive values
• Broker tool-restricts access to individual Slack users, channels, etc (COMING SOON)

The broker does not have access to your Baudbot instance. Baudbot is pull-only; it doesn't expose additional ports or host a control plane.

Core agents

Architecture at a glance

Slack
   ↓
control-agent (always-on)
   ├─ todo + routing
   ├─ dev-agent(s) in isolated worktrees
   └─ sentry-agent for incident triage
        ↓
git commits, PRs, CI feedback, thread updates

Baudbot uses source/runtime separation: admin-managed source and immutable releases are deployed into an unprivileged agent runtime.

Security as an enabling layer

Baudbot is built for utility and containment:

• isolated baudbot_agent Unix user (no general sudo)
• per-UID firewall controls + process isolation
• source/runtime separation with deploy manifests
• startup deploy-manifest integrity verification (warn/strict modes)
• read-only protection for security-critical files
• session log hygiene (startup redaction + retention pruning)
• layered tool and shell guardrails (policy/guidance layer, not sole containment)

See SECURITY.md for full threat model, trust boundaries, and known risks. In particular: many controls here are defense-in-depth (helpful for drift prevention/detection and keeping healthy agents on-task), while hard containment comes from OS/runtime boundaries.

Documentation

• docs/team-workflow.md — request lifecycle and orchestration model
• docs/agents.md — agent roles, responsibilities, and session model
• docs/memory.md — persistent memory design and operating rules
• docs/linux-runtime.md — Linux execution model, tools, and constraints
• docs/operations.md — day-2 operations (start/stop/update/rollback/audit)
• docs/architecture.md — source/runtime/release architecture
• docs/releases.md — semver policy and manual release workflow
• CONFIGURATION.md — full env var reference
• SECURITY.md — deep security model and vulnerability reporting
• CONTRIBUTING.md — contribution workflow

Tests

# All tests (unified Vitest runner)
npm test

# JS/TS suites only
npm run test:js

# Shell/security script suites only
npm run test:shell

# JS/TS coverage
npm run test:coverage

# Lint (Biome + ShellCheck) + typecheck
npm run lint && npm run typecheck

# ShellCheck only
npm run lint:shell

Sponsor

Sponsored by Modem.

<a href="https://modem.dev?utm_source=github&utm_medium=oss&utm_campaign=oss_baudbot&utm_content=readme_footer">
<picture>
<source media="(prefers-color-scheme: dark)" srcset="https://modem.dev/images/logo/svg/modem-combined-white.svg">
<source media="(prefers-color-scheme: light)" srcset="https://modem.dev/images/logo/svg/modem-combined-black.svg">
<img src="https://modem.dev/images/logo/svg/modem-combined-black.svg" alt="Modem" width="220">
</picture>
</a>

License

MIT