OpenTag is a local-first, source-thread-native framework designed to integrate coding agents—such as Claude Code or Codex—into existing team collaboration platforms (Slack, GitHub, GitLab, Lark/Feishu, Telegram, and Discord). By transforming standard communication threads into governed agent work loops, it enables teams to manage agent interactions directly within their existing workflows while maintaining strict security, auditability, and local control.

Core Methodology and Architecture

The system operates as a mediator between external communication platforms and local execution environments. Its architecture is composed of four primary components:

1. Platform Listener: A gateway that hooks into the target communication platform to ingest events. It bridges the gap between collaborative threads and the local dispatcher.
2. Local Dispatcher: Serving as the central orchestration hub, the dispatcher manages the lifecycle of an agent request. It performs context packet curation, verifies permissions, checks executor capabilities, and maintains a local agent work ledger.
3. Local Runner: This component executes the agent logic on the user's local machine. It maintains the "local-first" philosophy, ensuring that source code and sensitive data remain within the local checkout rather than a centralized cloud service.
4. Executor Adapters: OpenTag provides specialized adapters for coding agents like Claude Code and Codex. The system treats these agents as black-box execution engines that process local context and return structured artifacts.

The Agent Work Protocol

OpenTag treats the source thread as the primary "approval surface." The workflow follows a structured loop:

• Contextualization: When an agent is mentioned (e.g., @opentag investigate this), OpenTag generates a context packet.
• Action Receipt: Before committing any changes to the system of record, the agent produces a "compact receipt." This receipt outlines the proposed mutations, requiring the user to explicitly confirm execution via an "Apply" button or interface.
• Auditable Ledger: Every request is persisted in a local SQLite-backed store. The ledger records:
  • $S_e$: The source event trigger.
  • $A_d$: The admission decision (approval/denial).
  • $C_p$: The context packet snapshot.
  • $E_c$: The executor capability state.
  • $A_o$: The resulting artifacts and final outcome.

The system ensures that the entire state transition is transparent. The audit trail remains accessible via the CLI using commands such as $opentag status --run <run_id>$, allowing for granular verification without flooding the original communication thread with debug logs.

Technical Implementation and Privacy

OpenTag is built on a modular Node.js architecture (v20+). Security is enforced through local-only credential storage, where platform tokens are stored with restricted file system permissions. By utilizing background services (via LaunchAgent on macOS or systemd --user on Linux), the dispatcher remains resident, allowing for asynchronous execution and persistent monitoring of platform events.

The framework emphasizes an "artifact-first" rather than "chat-first" communication model. Instead of lengthy conversational responses, OpenTag compresses outcomes into actionable artifacts—such as pull request intents or diagnostic reports—providing links back to the local repository and the secure work ledger for deeper inspection. This minimizes noise in collaboration tools while maximizing the reliability and traceability of AI-driven coding tasks.