The agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.
Slack harness for local ACP coding agents
OpenTag gives Slack a persistent teammate that runs on your own machine instead of in a hosted chat app. You mention it in Slack, the Control Plane queues the work, the Runner invokes a configured agent through ACP on the local checkout, and the results return to the same thread with evidence.
Builders who want their agent work to start in Slack and finish with a visible, evidence-backed reply in the same conversation.
You can keep agent work tied to one Slack thread while the actual coding happens on a machine you control.
What it does
Slack request intake
Accepts requests by mention in Slack and keeps them queued until the paired Runner is ready.
Paired local execution
Runs Claude Code, Codex, Cursor, and other ACP-capable agents on the user-controlled Runner machine.
Threaded status and evidence
Posts progress, decisions, blockers, and verified results back into the originating Slack thread.
Self-hosted control plane
Keeps coordination state, leases, approvals, and evidence on the self-hosted Control Plane instead of in chat.
GitHub draft PR support
Can publish draft PRs and read back publication and evidence without auto-merging changes.
OpenTag skill for setup help
Includes an agent-readable skill so coding agents can help with local installation and configuration.
How to get it
- 1Prerequisites: Docker Compose, PostgreSQL through the included Compose profile, and a…
git clone https://github.com/amplifthq/opentag.git cd opentag/deploy/compose cp .env.example .env docker compose --env-file .env up --build
- 2Run
npm install -g @opentag/cli@0.11.0 opentag setup --relay https://relay.example.com opentag start
- 3Setup configures and pairs one Runner, GitHub Project Target, and ACP executor. The…
opentag doctor opentag status
- 4Run
@OpenTag investigate the failing check and propose a fix
README

English · 简体中文
OpenTag
Your persistent AI teammate in Slack, running on a computer you control.
OpenTag gives an engineering channel a teammate that remains reachable through your self-hosted Control Plane, even when its paired computer is offline. Mention it in Slack to queue work; when the Runner is ready, it invokes your coding agent through ACP against the local checkout and reports status, decisions, and evidence back in the same thread.
Your source code, local checkout and worktrees, coding-agent login/session, and GitHub credential stay on the Runner. Slack credentials and the Control Plane's service credentials stay on the Control Plane. It keeps coordination truth—not a copy of your development machine.
Quick start
1. Start the self-hosted presence
Prerequisites: Docker Compose, PostgreSQL through the included Compose profile, and a public HTTPS origin that Slack can reach.
git clone https://github.com/amplifthq/opentag.git
cd opentag/deploy/compose
cp .env.example .env
docker compose --env-file .env up --build
Before the last command, replace every placeholder in .env and create the
file-backed Slack and relay-content secrets described in the
Compose guide.
2. Pair the computer where work happens
npm install -g @opentag/cli@0.11.0
opentag setup --relay https://relay.example.com
opentag start
Setup configures and pairs one Runner, GitHub Project Target, and ACP executor.
The paired-only runtime requires the trusted self-hosted Control Plane URL and
bootstrap pairing credential; it has no standalone local mode.
When prompted, enter the exact OPENTAG_SLACK_PROJECT_TARGET_ID used by the
active Slack binding; setup registers it through the Runner credential and
verifies the Control Plane readback before pairing completes.
If this machine ran a pre-reset OpenTag checkout, point OPENTAG_CONFIG_HOME
and OPENTAG_STATE_DIR at new empty directories. The paired Runner does not
reinterpret or rewrite an earlier config or SQLite database.
Use opentag pair only to finish an interrupted pairing or pair an existing
unpaired configuration. Verify the exact installation before the first real
request:
opentag doctor
opentag status
3. Work with the teammate in Slack
@OpenTag investigate the failing check and propose a fix
If the Runner is offline, the request remains visibly queued. If work needs a
decision, Slack shows the exact action that needs attention. A provider timeout
or ambiguous side effect remains outcome_unknown; OpenTag does not invent a
success or blindly replay it.
Why a teammate, not another agent dashboard
- Present in the channel — the self-hosted relay receives Slack requests and can explain that the Runner is offline instead of disappearing with the laptop.
- Works where the code already lives — the coding agent runs on the paired, user-controlled computer with its approved local Project Target.
- Keeps one conversation — requests, queue state, approvals, blockers, and final evidence return to the originating Slack thread.
- Reports facts, not theater — executor output, Run state, GitHub publication, and provider delivery remain separate facts with separate evidence.
- Writes only through explicit authority — draft PR publication is a distinct, governed stage; OpenTag does not auto-merge or let chat text broaden access.
How it works
flowchart LR
S[Slack channel] --> C[Self-hosted Control Plane]
C --> P[(PostgreSQL)]
C --> R[Paired Runner]
R --> A[ACP coding agent]
A --> W[Local checkout]
R --> G[GitHub draft PR and readback]
C --> S
Slack is the only Source App in the supported team profile. GitHub is a Project Target plus an optional publication and evidence provider; it is not a second request inbox. One paired Runner is the execution owner. The Control Plane owns the canonical Work, Attempt, lease, approval, Effect evidence, channel projection, and terminal assessment.
The console exposes each active Slack binding as a long-lived Teammate. Its work state is derived from facts that already exist: Project Target, fresh Runner readiness, and the binding's current Work. It adds no Teammate table, second lifecycle, or mutable presence state.
Teammate work states
| State | What it means |
|---|---|
ready | The Teammate's Project Target, Runner, and fresh readiness all exist. |
queued | A request is durably waiting for the paired Runner. |
working | The current fenced Attempt is assigned or running on a ready Runner. |
needs_attention | A decision, reconciliation, or conflicting active work needs a human. |
runner_offline | The Teammate remains in Slack, but its Runner has no fresh readiness receipt. |
setup_required | The Slack binding, Project Target, or Runner is incomplete. |
These states are projections, not commands. They cannot claim, retry, cancel, or settle work.
Deliberately narrow
The current product path is:
Slack presence → self-hosted Control Plane → one paired Runner
→ one ACP coding agent → optional GitHub draft PR/evidence → Slack
This repository does not currently claim managed hosting, high availability,
other Source Apps, GitHub webhook ingress, multi-Runner scheduling, ambient
memory, automatic merge, or a general software-factory planner. There is no
local_direct compatibility mode: the supported product always pairs a Runner
with the self-hosted Control Plane.
AI agent integration
OpenTag's Runner launches configured coding agents through ACP and keeps raw tool output out of the team thread. The repository includes an agent-readable install guide and an OpenTag skill so Codex, Claude Code, and other coding agents can help with local setup without asking users to paste secrets into chat.
Verify the repository
corepack pnpm install --frozen-lockfile
corepack pnpm typecheck
corepack pnpm test
corepack pnpm build
These checks prove local source behavior only. They do not prove a deployed relay, a live Slack delivery, a GitHub publication, or installation-level availability.
Documentation
- Compose installation
- Slack Source App setup
- GitHub Project Target and publication
- Control Plane deployment
- Always-on ingress with local execution
- Configuration reference
- Team-relay canary
Contributing
Contributions are welcome. See CONTRIBUTING.md for the local development workflow and pull-request checks.
License
Files in the repo
- .codegraph
- .github
- apps
- assets
- deploy
- docs
- packages
- scripts
- skills
- .dockerignore
- .gitignore
- CHANGELOG.md
- CONTEXT.md
- CONTRIBUTING.md
- LICENSE
- package.json
- pnpm-lock.yaml
- pnpm-workspace.yaml
- README.md
- README.zh-CN.md
- SECURITY.md
- tsconfig.base.json
- tsconfig.json
- vitest.config.ts
Discussion (0)
Ask about usage, or say what you built with itSign in to join the discussion.
No comments yet. Be the first to say what this is good for.
More harnesses
from vibe coding to agentic engineering - practice makes claude perfect
🌊 The original agent meta-harness. Deploy intelligent multi-player swarms, coordinate autonomous workflows, and build conversational AI systems. Features adaptive memory, self-learning intelligence, RAG integration, and native Claude Code / Codex / Hermes and many more Integrated
Practical patterns, starters & CLI tools for loop engineering with AI coding agents. Design systems that prompt and orchestrate agents (inspired by Addy Osmani and Boris Cherny). Includes loop-audit, loop-init, loop-cost.
Git. Ship. Done - Core

The most RAM efficient harness