Skip to content

How It Works

The platform turns conversations into action through a five-step pipeline. You talk to Buck in Slack, Jira, or the Dashboard — it figures out what needs doing and gets it done.

For the full technical architecture, see the Architecture reference.

A user starts work in one of four ways:

  • Slack: @buck in a channel or thread
  • Jira: Assign a ticket to Buck, or comment on a ticket he’s working on
  • Dashboard: Create a session directly from the web dashboard
  • Pull Requests: Open a PR (automatic review) or comment @buck on a PR

Events arrive as webhooks and are published to NATS JetStream subjects (webhooks.buck.{type}). Buck’s consumer pulls events from its namespace. Per-session ordering ensures events for the same conversation execute sequentially via sharded mutexes.

Buck uses Claude (via AWS Bedrock Converse API) to reason about the event — searching code via Sourcegraph, checking observability via Grafana, creating Jira tickets and dashboard sessions, and dispatching Claude sessions to EKS pods.

Buck dispatches an ephemeral EKS pod with Claude Code for implementation. Pods run in tmux with terminal access, MCP plugins (Sourcegraph, Grafana, PostHog, Playwright), and full codebase access. By default, Claude decides what to do — in plan mode, it only produces a plan for review.

The pod reports results back to the agent via runner API (pod-bound JWT). Buck posts the plan or PR link to Slack/Jira. Sessions can pause (saving state to S3) and resume later with follow-up instructions.

ModeBehavior
DefaultClaude reads the task, plans, and implements in one session
PlanClaude reads the codebase and posts a detailed plan for human review
CapabilityBuck
Terminal accessYes (WebSocket tunnel from dashboard)
Pause/resumeYes (S3 state persistence)
Real-time statusYes (SSE pod status updates)
Block Kit interactionsYes (plan approval buttons)
Multimodal inputYes (images from Slack threads)