A self-hosted AI agent that lives in your Slack workspace, powered by Claude via Amazon Bedrock. Digby responds to mentions, maintains persistent memory across conversations, can read and edit files, run shell commands, search the web via MCP, and trigger on a schedule — all from your existing Slack setup. The Slack connection is outbound-only (Socket Mode); the optional extras — the Linear agent’s webhook and the wiki — need one public origin, typically a Cloudflare Tunnel.

• Slack bot (Socket Mode) — connects outbound over WebSocket
• Linear agent — (optional) assign tickets to the same agent running in your Slack
• Persistent memory — maintains global MEMORY.md and per-channel MEMORY.md / log.jsonl / context.jsonl histories
• Shell and file system tools — persistent ~ directory: can clone repos, run apps and tools, and maintain a knowledge base
• MCP integrations — plug in any MCP server (Linear, Exa search, and more) via .pi/mcp.json, or just ask!
• Scheduled events — configures itself to trigger on cron schedules: run standup, write Friday release notes, etc.
• Wiki knowledge base — (optional) web UI at /w/ for browsing ~ as a wiki, gated by Slack OAuth
• Serve raw assets — (optional) view HTML and other artifacts directly at /r/ from the agent’s ~ directory, gated by Slack OAuth

Digby is agentic and acts on your behalf. It has a root shell, so everything in the task environment is reachable from it — GH_TOKEN, the ECS task role, your MCP keys. There is no allowlist: anyone who can message it in your workspace can drive it. That is the design; it is meant to be frictionless.

Rules you give it — digby.json, MEMORY.md, the system prompt — are asks, not boundaries. They live on a volume the agent can write to.

So give it capability deliberately:

• Scope the credentials. Use a fine-grained GH_TOKEN covering only the repos digby should touch, and keep the task role and MCP keys as tight. Assume anything in the environment is one conversation away from being used.
• Trust the room. Only expose digby to people you would trust with those credentials directly — that is effectively what you are doing.

Trusted people alone are not sufficient: digby reads untrusted content (web pages, search results, Linear issues), so a hostile page summarised by a colleague you trust is the same attack. Credential scope is the control that holds either way.

Slack (Socket Mode)
  └─ pi-digby (Node.js, AWS ECS Fargate)
       ├─ src/slack/router.ts    — event classification and routing
       ├─ src/agent/setup.ts     — AgentSession, tools, MCP runtime
       ├─ src/persistence/       — log.jsonl, context.jsonl, MEMORY.md
       ├─ src/events/            — scheduled event watcher
       └─ /data (AWS EFS)        — persistent storage across deploys

pi-digby is a single Node process. Each Slack channel runs in its own “lane” with a FIFO queue; threads get separate agent session directories. The LLM is Claude Sonnet (via Amazon Bedrock) with tool use. MCP servers are loaded at startup from .pi/mcp.json in the working directory.

• AWS account with admin credentials for the one-time stack creation (after that, deploys go through a scoped OIDC role)
• Slack workspace where you can create and install apps
• GitHub account to fork this repository — deploys run from GitHub Actions
• Node.js 20+ — local development only

All infrastructure lives in us-east-1.

Start here — it is the only step with an approval wait. In the AWS console: Amazon Bedrock → Model access (region us-east-1) → request access to Anthropic Claude Sonnet 4.6. The bot invokes the us. cross-region inference profile, which can route to us-east-2 and us-west-2, so enable access there too. Approval is usually quick, but not instant.

api.slack.com/apps → Create New App → From an app manifest → paste deploy/slack-app-manifest.yml.

Then collect the two tokens:

• Basic Information → App-Level Tokens → generate one with the connections:write scope → DIGBY_SLACK_APP_TOKEN (xapp-…)
• Install App → install to your workspace → DIGBY_SLACK_BOT_TOKEN (xoxb-…)

Fork this repository, then in your fork:

1. Enable workflows — the Actions tab on a fresh fork asks you to enable them.
2. Add Actions variables (Settings → Secrets and variables → Actions → Variables):

The deploy workflow authenticates to AWS with OIDC — no long-lived AWS keys in GitHub. The stack in the next step creates both the identity provider and the deploy role, trust-scoped to your fork.

<div class="highlight highlight-source-shell notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="aws cloudformation deploy
–profile YOUR_AWS_PROFILE
–region us-east-1
–stack-name pi-digby
–template-file deploy/cloudformation.yml
–capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM
…