Show HN: Ankole – Claude Tag open source alternative Ankole, a self-hosted open-source AgentOS for shared AI colleagues, launched as an alternative to Claude Tag. It enables multiple AI agents with durable identities and long-running sessions to own ongoing work in channels, repositories, and internal systems on user-controlled infrastructure. The project targets teams needing AI agents that hold responsibilities and produce visible results like merged code or triaged alerts. How it's different how-ankole-is-different · Product shape product-shape · Actor runtime actor-runtime · Architecture architecture · Current status current-status · Development development Ankole is a self-hosted AgentOS for shared AI colleagues. One installation, many agents, real responsibilities — on infrastructure you control. It moves AI work out of a private chat box and into the places where work already happens: channels, repositories, schedules, dashboards, internal systems, and long-running project context. An Ankole agent has its own identity, memory, permissions, tools, workspace, and responsibility boundary — so it can own ongoing work , not just answer a one-off message. Claude Tag https://claude.com/product/tag is a useful public reference point: tag an AI into a Slack thread, let it read the shared context, use organization tools, remember channel context, and follow up when work takes time. Ankole targets the broader open version of that pattern: not only Slack, not only Claude, not only one agent, and not vendor-owned context. Ankole is for work that needs an owner, not just an answer. A good Ankole role has a visible result: code merged, a report shipped, a customer issue handled, an alert triaged, a market change noticed, or a backlog worked down. Shared by default, not private chat. Agents join team-visible channels and provider contexts; multiple humans can observe, steer, and continue the same work. Durable identity, not a prompt convention. Humans and agents are Principals with permission grants and audit trails, so authorization is a runtime concern. Long-running actor sessions, not request/response. Sessions wake, receive signals, checkpoint, stream progress, hibernate, and recover with context. Operator-owned context, not vendor-hosted. Memory, configuration, credentials, and audit live in your infrastructure on a self-hosted installation. Live control plus durable truth, not one or the other. ZeroMQ RuntimeFabric carries live actor/worker/RPC traffic while PostgreSQL remains the source of replay, fences, and final commits. Many sources. IM, webhooks, scheduled reminders, internal systems, and future provider adapters all become normalized signal input. Many agents. One installation can host multiple agents with different missions, access, tools, memory, and outbound identities. Session actors. The long-running execution unit is actor id = {agent id, session id} . A session is where context, workspace state, steering, cancellation, and recovery meet. Owned context. Conversations, model turns, summaries, signal projections, decisions, corrections, and future domain records live in your infrastructure. Operator control. Access, configuration, plugin activation, actor leases, outbox side effects, and audit surfaces belong to the installation operator. Ankole should make these workflows natural: - A coding agent watches an issue, reproduces the bug, changes code, opens a draft PR, and reports what still needs a human decision. - A customer-success agent observes a shared group chat, records the important facts, updates work state, and escalates privately only when needed. - A research agent monitors markets, policy, competitors, and internal notes, then follows up when a change matters. - A QA agent works through a test backlog, gathers evidence, and hands off failures with enough context for review. - An operations agent watches alerts, prepares a runbook, and asks for approval before taking risky action. The common pattern is not "answer this question." It is "hold this seat, use the available context, and be judged by the result." Ankole is an actor-oriented runtime for long-running AI work. Each active session is an addressable virtual actor: it can wake, receive messages, checkpoint, stream progress, hibernate, recover, and continue without pretending an agent is just an HTTP request or a queue job. The runtime is built around five technical bets: Virtual Actors for AI work. A session is a stateful work identity with an address, mailbox, lifecycle, and recovery path, not loose background work. OTP Supervision Trees as failure domains. If one agent hangs, times out, or crashes, Ankole can isolate or restart that branch without turning it into a deployment-wide failure. ZeroMQ Activation Fabric for live control. Wakeups, steering, checkpoints, streaming, and backpressure move through a low-latency routing layer while the agent is still working. Agent Computer as the execution substrate. The LLM loop, tools, files, terminal state, and streaming output run inside a Bun + TypeScript computer close to the workspace. Durable Ledger for recovery and audit. Mailboxes, turns, reminders, decisions, and committed side effects outlive processes. Streaming is progress; committed work is truth. For users and operators, the promise is simple: agents can work for hours or days, receive new input while running, fail independently, recover with context, and keep their side effects accountable. A longer version of the runtime argument is in Why OTP Is a Better Runtime for Multi-Agent Orchestration https://ding.ee/en-US/why-otp-is-a-better-runtime-for-multi-agent-orchestration/ . That is the technical bet: actor model for long-lived work identity, OTP for failure semantics, ZeroMQ for live activation, and Agent Computer for local execution. Ankole is closer to a distributed operating system for AI work than a chatbot backend. php flowchart LR Providers "Chats / webhooks / schedules" -- SG "SignalsGateway" Console "Web UI / operator APIs" -- CP "Control Plane