openTag reviews

openTag makes the most sense for teams that want an AI agent to live inside Slack or Lark and act on work from a shared thread. A user mentions the agent in a conversation, the task moves to the computer running the agent, and the reply comes back into the same workspace. For readers deciding whether this model fits their team, that chat-first handoff is the defining behavior: it is not a separate dashboard for occasional prompts, but a channel-based worker that sits where the team already talks.

The suitability question turns on control. openTag says there is no AI provider lock-in and that users can bring their own subscription or API key. It also runs the agent on the user’s own Mac or Linux machine rather than in openTag’s cloud, and its default setup does not store conversations, code, or memory on openTag’s servers. That combination matters for teams that want the agent’s work to stay tied to their own machine and their own provider relationship, rather than to a fully hosted assistant.

Its memory model is another reason some teams will find it a better fit than a plain chat bot. Context Tree stores team context as markdown in a Git repository the team hosts itself, so decisions, notes, and patterns can remain available to later agent tasks. openTag also says it can connect to more than 1,000 services, including GitHub, Notion, Google Drive, Jira, and Figma, which points to use cases where the agent needs more than chat history to do useful work.

The buying questions are fairly concrete. openTag is free to use, while the user pays for AI usage through an existing provider plan. The product says it can work with Claude or Codex subscriptions, or with an API key, and it recommends an API key for shared workspaces. Claude itself offers a free tier, Pro, and Max plans, while openTag’s setup requires a Mac or Linux computer with Claude, Codex, or Pi installed and a Slack or Lark workspace. For buyers, that means openTag is a closer match when the team is comfortable with local setup and already expects to manage model access separately.

The main limitation is not hidden in the product; it is part of the current support boundary. openTag is documented for Slack and Lark, with Teams and Discord listed as roadmap items rather than current support. So the best fit is a team that already works in one of those two messaging apps and wants an agent that can be summoned from the same place it will answer back.

Back to openTag