Botman agents are teammates you can hand real work to. They connect to your tools, work inside them like you do, and come back with finished work — from a machine you own, behind a door you control, with the models you already pay for.
Give work to an agent the way you’d message a colleague — in the dashboard, in Slack, or in Discord. It takes the project from start to finish, keeps context on how your team works, and comes back only when it needs your approval.
Share the thread and your teammates join it. Everyone’s messages land in one conversation, attributed by name, and the agent answers with the whole thread in view.
Create an agent, give it a job, and add another when the work grows — one on the product, one on tickets, one on research. Agents work in parallel, hand work to each other inside workflows, and keep going 24/7.
Each agent is a definition you own: a role, standing instructions, a model, the tools it may use, and guardrails. Start from the built-in roster or write your own — every edit is versioned.
Connect GitHub, Slack, Linear, Notion, Google Workspace, Vercel and PostHog once, with OAuth. Grant each agent only what it needs; brokered calls keep the long-lived token out of its hands.
“Every Monday at 8, summarize last week’s tickets.” That sentence is a routine — once, hourly, daily or weekly, delivered to the dashboard, Slack or Discord — and it survives the machine being replaced.
Chain agents into a workflow: each step names an agent, takes the previous step’s output, and ends at a gate. Parallel branches run in parallel. You watch the run instead of routing the work.
Sensitive steps — merging, deploying, touching infra — pause for a human. Approve from the dashboard or from chat; the run picks up exactly where it stopped.
Every agent writes down what it learns as it works: how your team names things, who approves what, which edge case bit last time. That memory is shared across your agents and injected into every session — show one agent a job today, and a different agent knows it tomorrow.
When an agent solves something worth repeating, it saves the procedure as a skill — versioned, readable, editable in Settings. And when it sees a better way to run a workflow or a sharper brief for an agent, it files a proposal with its rationale and evidence. You review; nothing about your agents or workflows changes without a human saying yes.
Hosted agent products give each bot a computer in someone else’s cloud. Botman agents run on a machine you own: code, credentials, and model calls never leave it. Every job runs in a room — its own container — whose only way out is an Iron Proxy door that opens to the hosts that unit was defined to reach and injects credentials at the boundary. Every allowed and blocked action is written to an audit trail you can export.
The runner installs on a VM or box you own and connects outbound to the control plane. No inbound ports. Your code, credentials, and model calls stay on that machine.
Every conversation, workflow run, and routine run gets its own room: a container from a pinned job image with capabilities dropped, no-new-privileges, pids/memory/CPU limits, a non-root user. Jobs run inside it; the runner’s home and other rooms are never mounted.
Model keys and cloud credentials are configured in your terminal, on the runner — never pasted into a dashboard, never stored by Botman. Sessions hold inert placeholder tokens; the real secret is swapped in at the door, outside the room.
A room’s only way out is its own Iron Proxy sidecar — digest-pinned, open-source — raised for each job with that job’s policy and removed after it. Default-deny: unlisted hosts, raw TCP, DNS bypass, IPv6, and cloud metadata endpoints all fail. An idle room has no way out.
Each agent declares the connectors and runner tools it may use. GitHub tokens are minted per job, short-lived, and scoped to that job’s repositories.
Every tool call is classified: read context, write task, write connector, write code, deploy infra, read secret, admin config. Restricted mode blocks the write classes until an admin enables them.
Workflow steps can require sign-off before the next one starts. Approve, retry, skip, or cancel from the dashboard or from chat.
Every allowed and blocked action is recorded as a metadata-only security event — actor, surface, action class, target, decision, reason. Proxy audit logs are ingested alongside. Export it all as JSON.
A workflow is an ordered set of steps. Each step names an agent, takes its inputs from the task or from earlier steps, runs on the model you chose for it, and ends at a gate — automatic, human approval, or passing checks.
Runs snapshot the workflow, then execute step by step inside one room on your machine, so later steps read earlier steps’ files directly. Watch each agent work in real time, open the artifacts and PRs it produces, and approve, retry, skip or cancel any step.
You’re not locked to one lab’s model. Sign in with your Claude subscription or API key, or bring OpenAI and OpenRouter keys — configured on your runner, in the terminal, never pasted into a dashboard and never stored by Botman.
Pick a model per agent and per workflow step: a heavier model for architecture, a faster one for tests. Model calls go from your runner straight to your provider.
Agents are generic; the job you give them is not. A few we see every week — each one running on the customer’s own runner.
Ships the feature overnight. Specs it from the thread, builds it on a branch, writes the tests, opens the PR — and leaves the merge for you.
[bug fixer]Reproduces the report, finds the root cause, opens a PR with the failing test attached, and posts the summary back in the thread it came from.
[project manager]Sweeps tickets every half hour, writes the morning standup from yesterday’s runs, and lands a Friday status report in #product from real run history.
[designer]Turns the product spec into screens and states, builds a clickable prototype as an artifact in the thread, and revises it as the team comments.
[marketer]Drafts release notes, the launch brief and the social thread from what actually merged, then leaves them as drafts for you to approve.
[operator]Runs the dependency audit daily, opens patch PRs, assembles incident summaries from logs and Slack, and holds every deploy at a human gate.
Install the runner on any Linux VM or box you own with a curl one-liner. It connects out to the control plane, installs its own toolchain, and keeps itself updated. The control plane holds definitions and state; your machine does the work.
No Kubernetes, no YAML, nothing to expose. A second machine is the same command again.
The agents have a computer of their own — a machine you provide. Code, credentials and model calls never leave it; every job runs in a room behind an Iron Proxy door; and you choose the model. Hosted products run your work on their computer, with their model.
On any Linux VM or box you own. One command installs the runner. It connects outbound to the control plane; nothing listens for inbound traffic. Add a second machine with the same command.
Claude through your subscription or API key, plus OpenAI and OpenRouter keys — configured on your runner, in the terminal. Pick a model per agent and per workflow step.
Memory and skills the agents write for themselves are used immediately, and you can read and edit both in Settings. Changes to agents and workflows are proposals: the agent files its rationale and evidence, you apply or reject, and applied changes are versioned and affect future runs only.
They share one runner, but each conversation, workflow run and routine run gets its own room — its own container, files and door. Rooms never see each other, and the runner’s home is never mounted into one.
In the dashboard, in Slack, or in Discord — the same agent, the same memory. Share a dashboard thread by link and teammates join it.
An AI teammate you can trust with real work — on your own infrastructure. A 20-minute walkthrough: install a runner, create an agent, hand it a job, share the thread.