What teams run on Botman.

From a thread to a reviewed PR.

A task starts as a Slack message or a card on the board. The feature-development workflow runs it through spec, architecture, code, and tests — each step a different agent, each output an artifact or PR, each gate a human decision. Your engineers review; the agents do the typing.

Bug triage is the same shape, shorter: reproduce, root-cause, fix, open the PR with the failing test attached.

• Coder, tester, and analyst agents on your repos, scoped by GitHub App to the ones you pick
• Human gate before merge; checks gate to auto-advance when CI passes
• Every run keeps its transcript, usage, and the PRs it opened

Status that writes itself from what actually happened.

Routines do the recurring parts: a standup digest every morning from yesterday’s runs and tickets, a ticket sweep every half hour that labels and assigns, a Friday status report built from the week’s run history — delivered to the channel that needs it.

In between, anyone can ask the agent in chat where a task stands, and the answer comes from the board and the runs, not from memory.

• Routines: once, every N minutes, daily, weekly — delivered to the dashboard, Slack, or Discord
• Linear and Slack connected once, granted to the agents that need them
• Blockers and failed steps surface in Home → Needs you

Design specs and prototypes, reviewed in the thread.

A designer agent drafts the design spec from the product spec — screens, states, empty and error cases — and builds a clickable HTML prototype as a chat artifact. The team reviews it in the same thread; every revision is a new version of the artifact.

With a browser tool on the runner, the agent can also walk your live product and report what diverges from the spec.

• Prototypes as versioned HTML artifacts beside the conversation
• Multiplayer threads — design, product, and engineering in one review
• Playwright browser tool for checking the shipped UI against the spec

Launch comms drafted from what shipped.

When a workflow merges a feature, a marketing agent drafts the release notes, the launch brief, and the social thread from the actual PR and spec — not from a summary someone had to write. A weekly routine pulls the numbers from PostHog into a performance digest.

Drafts land as artifacts in a shared thread, so marketing and product edit together before anything goes out.

• Release notes and launch briefs grounded in the merged PRs
• Weekly analytics digest as a routine
• Nothing is posted without a human gate

The recurring checks, run on a schedule and behind gates.

A daily dependency audit across every repo, opening PRs for patches. Deploys that stop at a human gate. Incident summaries assembled from logs and the timeline in Slack. Support tickets triaged, labelled, and routed on a 30-minute routine.

Anything that touches infrastructure is classified as such — deploy and infra actions stay blocked in restricted mode until an admin enables them, and every decision is in the audit trail.

• Action-class policy: deploy/infra and secret reads blocked by default
• Per-job containers and iron proxy egress for anything that runs code
• Exportable security report for every allowed and blocked action

If the work repeats and lives in your tools, an agent can run it.

Research briefs from the web and your Notion. Customer support in Discord with a read-only, curated context. Finance close checklists. Hiring pipelines. The agents are generic — the workflows, routines, and tool grants you give them are what make them yours.

• Create an agent with its own instructions, model, tools, and guardrails
• Describe a workflow or a routine in chat and it is created
• Same security model for every agent, whatever the job