The command line is where a lot of real work happens. Configuration, deployments, code review, ops — if you work with software, you spend a meaningful chunk of your day staring at a terminal or writing in a chat box to coordinate with tools and teammates. We think that gap — between what a language model can do and what your team can actually reach — is worth closing. That is what we are building with bclaw.sh.

What is bclaw.sh?

bclaw.sh is a toolkit for deploying domain-specific AI agents at work. It sits on top of Hermes Agent by Nous Research — a platform for building and running AI agents natively in Telegram — and adds the scaffolding, runtime, and conventions needed to take an agent from a one-off experiment to something a whole team can rely on.

The fundamental idea: your team should not be using a generic chatbot. You should have an agent that knows your stack, has access to your tools, and operates with a specific job description.

The pieces

Hermes Agent is the engine. It provides real-time streaming, tool calling, MCP support, persistent memory across conversations, multi-agent orchestration, and bring-your-own-model flexibility. It runs natively in Telegram, which means your agents live where your team already communicates — no new dashboards, no browser tabs to context-switch into.

create-bclaw is the scaffolding CLI. Run npx create-bclaw <project-name> and you get an opinionated project skeleton — backend, CLI layer, API gateway config, and web frontend — wired up and ready to extend. Think of it as create-react-app for agent deployments: skip the boring parts and start on what matters.

harness is the execution environment. Each agent runs inside a harness container that defines what the agent can see and do: which tools are mounted, which credentials it holds, what its system prompt looks like, and what guardrails it operates under. The harness is what converts a capable general-purpose model into a focused, auditable, safe-to-run-at-work agent.

What does this look like in practice?

This blog is one example. HomuncuCLAW is a bclaw-style agent deployed against this site. It runs inside a harness container that has access to the abbey codebase, the live database over Tailscale, kamal deploy tooling, and a single trusted Telegram channel. It can publish posts, promote drafts, edit content, deploy code, and report site health — all from a chat message, with confirmation rails on destructive operations. No browser, no SSH, no context switching.

That pattern — scoped tools, single trusted operator, clear job description, hard prohibitions — scales to any team workflow. A deployment agent that knows your CI pipeline. A support agent that can read your runbooks and open Jira tickets. A data agent that can query your warehouse and post summaries to Slack. Each one purpose-built, each one running inside a harness that defines exactly what it is allowed to do.

Why Telegram?

Telegram is fast, has a solid bot API, supports file and media transfer, threads well, and your team probably already has it. More importantly, Hermes Agent treats Telegram as a first-class runtime — not a thin notification layer, but the actual interface where the agent thinks, responds, and does work. That changes the interaction model from "ask a chatbot" to "talk to a colleague who happens to be a machine."

What we are working on

bclaw.sh is early. The scaffolding CLI exists. The harness runtime exists. HomuncuCLAW exists and runs this blog. The next steps are:

• Reference harness configurations for common team workflows (eng, ops, support)
• Multi-agent coordination patterns — agents that delegate to each other
• A web UI for non-Telegram teams
• Hardened audit logging and permission layers for enterprise environments

If any of this sounds useful for what you are building, the repos are public and feedback is welcome.