You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
6.**Capabilities** (NEW — agent roles + what they do)
20
+
7.**Integrations** (NEW — table)
21
+
8. How It Works (message flow diagram)
22
+
9. Architecture (detailed tree)
23
+
10. Operations
24
+
11. Tests
25
+
12.**Adding Agents** (NEW)
26
+
13. Security Stack
27
+
14. Security Details
28
+
15. License
29
+
30
+
This front-loads the "try it now" path (Why → Requirements → Install → Config), then explains what you get (Capabilities, Integrations, How It Works) for people who want to dig deeper.
"title": "README: Add \"Adding Agents\" section — how to create new agent roles",
4
+
"tags": [
5
+
"readme"
6
+
],
7
+
"status": "done",
8
+
"created_at": "2026-02-17T05:03:49.567Z"
9
+
}
10
+
11
+
OpenClaw has skills registry / workspace docs. We should briefly explain how to add custom agent roles — it's one of our strengths.
12
+
13
+
Short section near the end (after Tests, before Security):
14
+
15
+
### Adding Agents
16
+
17
+
Baudbot ships with three agent roles but you can add more. An agent role is just a skill file:
18
+
19
+
1. Create `pi/skills/my-agent/SKILL.md` with role instructions
20
+
2. Add a startup block to the control agent's `startup-cleanup.sh`
21
+
3. Deploy: `~/baudbot/bin/deploy.sh`
22
+
23
+
Skills are markdown files with frontmatter. The agent loads them at session start and follows the instructions. See `pi/skills/dev-agent/SKILL.md` for the pattern.
24
+
25
+
Keep this very short — point to the existing skill files as examples.
OpenClaw prominently lists its channels (WhatsApp, Telegram, Slack, etc.). We should do the same for our integrations, but honestly — we have fewer, so keep it tight.
12
+
13
+
Add an "Integrations" section (after Capabilities, before Requirements):
Note: Unlike OpenClaw which supports 15+ messaging platforms, Baudbot focuses on Slack as the primary human interface. Email (AgentMail) is for agent-to-agent and automated workflows. Adding more channels (Discord, Teams) is straightforward — the bridge pattern is extensible.
**Hardened infrastructure for always-on AI agents.**
7
7
8
-
Baudbot is an open framework for running always-on AI agents that support software teams — coding agents, automated SREs, QA bots, monitoring, triage, and more. Agents run as isolated Linux processes with defense-in-depth security. Baudbot assumes the worst: that an agent *will* be prompt-injected, and builds kernel-level walls that hold even when the LLM is fully compromised.
8
+
Baudbot runs AI agents as isolated Linux processes with defense-in-depth security. Agents code, test, deploy, monitor, and triage. They work on real repos with real tools. The infrastructure assumes agents *will* be prompt-injected and builds kernel-level walls that hold when the LLM is compromised.
9
9
10
-
**Built for Linux.** Baudbot uses kernel-level features (iptables, `/proc` hidepid, Unix users) that don't exist on macOS or Windows. Every PR is integration-tested on fresh **Ubuntu 24.04** and **Arch Linux** droplets.
10
+
Built for Linux. Uses iptables, `/proc` hidepid, and Unix user isolation. Every PR is integration-tested on fresh Ubuntu 24.04 and Arch Linux droplets.
11
11
12
12
## Why
13
13
14
-
Every AI agent framework gives the model shell access and hopes for the best. Baudbot doesn't hope — it enforces:
14
+
Every agent framework gives the model shell access and hopes for the best. Baudbot enforces:
15
15
16
-
-**OS-level isolation**— dedicated Unix user, no sudo, can't see other processes
-**Source/runtime separation**— agent can't read or modify its own infrastructure code
19
-
-**Dual-layer command blocking**— dangerous shell patterns caught before execution at two independent layers
20
-
-**Self-healing**— permissions hardened on every boot, secrets redacted from logs automatically
16
+
-**OS-level isolation.**Dedicated Unix user, no sudo, can't see other processes.
17
+
-**Network control.** iptables per-UID egress allowlist. No listeners, no reverse shells.
18
+
-**Source/runtime separation.**Agent can't read or modify its own infrastructure.
19
+
-**Dual-layer command blocking.**Dangerous patterns caught at two independent layers.
20
+
-**Self-healing.**Permissions hardened on every boot, secrets redacted from logs.
21
21
22
-
Agents work on real files in real repos — no sandbox friction. They make real git branches, run real tests, and push real PRs. But they can't exfiltrate data, escalate privileges, or phone home.
22
+
No sandbox friction. Agents make real branches, run real tests, push real PRs. But they can't exfiltrate data, escalate privileges, or phone home.
The installer detects your distro, installs dependencies, creates the agent user, sets up the firewall, and walks you through API keys interactively. Takes ~2 minutes.
40
+
The installer detects your distro, installs dependencies, creates the agent user, sets up the firewall, and walks you through API keys. Takes ~2 minutes.
|**sentry-agent**| Watches Sentry alerts, investigates via API, reports triage to control agent |
76
+
77
+
Agents can read/write files, run shell commands, create git branches and PRs, build Docker images (via a security wrapper), message each other across sessions, monitor email inboxes, automate cloud browsers, and manage shared todos.
Slack is the primary human interface. Email is for agent-to-agent and automated workflows.
91
+
92
+
## How it works
93
+
94
+
The control agent spawns sub-agents in tmux sessions and starts the Slack bridge. Messages flow through layered security:
95
+
96
+
```
97
+
Slack → bridge (access control + content wrapping) → pi agent → tools (tool-guard + safe-bash) → workspace
98
+
```
99
+
100
+
Every layer assumes the previous one failed. The bridge wraps content and rate-limits, but tool-guard blocks dangerous commands even if wrapping is bypassed. Safe-bash blocks patterns even if tool-guard is evaded. The firewall blocks exfiltration even if all software layers fail.
101
+
102
+
## Architecture
103
+
104
+
```
105
+
admin_user (your account)
106
+
├── ~/baudbot/ ← source repo (agent CANNOT read)
107
+
│ ├── bin/ deploy, firewall, security scripts
108
+
│ ├── pi/extensions/ 🔒 tool-guard, auto-name, etc.
Deploy is a one-way push: `~/baudbot/bin/deploy.sh` stages source to `/tmp`, copies as `baudbot_agent` via `sudo -u`, stamps an integrity manifest, and cleans up.
Baudbot runs a **control-agent** that spawns specialized sub-agents in tmux sessions and starts a Slack bridge. Out of the box it ships with a dev-agent (coding), sentry-agent (monitoring/triage), and a control-agent (orchestration) — but you can add any agent role. Messages flow:
170
+
An agent role is a skill file. Baudbot ships three but you can add more.
113
171
114
-
```
115
-
Slack → bridge (access control + content wrapping) → pi agent → tools (tool-guard + safe-bash) → workspace
116
-
```
117
-
118
-
Every layer assumes the previous one failed. The bridge wraps content and rate-limits, but tool-guard blocks dangerous commands even if wrapping is bypassed. Safe-bash blocks patterns even if tool-guard is somehow evaded. The firewall blocks exfiltration even if all software layers fail. Defense in depth, all the way down.
119
-
120
-
## Architecture
121
-
122
-
```
123
-
admin_user (your account)
124
-
├── ~/baudbot/ ← source repo (agent CANNOT read)
125
-
│ ├── bin/ deploy, firewall, security scripts
126
-
│ ├── pi/extensions/ 🔒 tool-guard, auto-name, etc.
0 commit comments