{"slug": "show-hn-ankole-claude-tag-open-source-alternative", "title": "Show HN: Ankole – Claude Tag open source alternative", "summary": "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.", "body_md": "[How it's different](#how-ankole-is-different) · [Product shape](#product-shape) · [Actor runtime](#actor-runtime) · [Architecture](#architecture) · [Current status](#current-status) · [Development](#development)\n\n**Ankole is a self-hosted AgentOS for shared AI colleagues.** One installation, many agents, real responsibilities — on infrastructure you control.\n\nIt 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.\n\n[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.**\n\nAnkole 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.\n\n**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.\n\n**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}`\n\n. 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.\n\nAnkole should make these workflows natural:\n\n- A\n**coding agent** watches an issue, reproduces the bug, changes code, opens a draft PR, and reports what still needs a human decision. - A\n**customer-success agent** observes a shared group chat, records the important facts, updates work state, and escalates privately only when needed. - A\n**research agent** monitors markets, policy, competitors, and internal notes, then follows up when a change matters. - A\n**QA agent** works through a test backlog, gathers evidence, and hands off failures with enough context for review. - An\n**operations agent** watches alerts, prepares a runbook, and asks for approval before taking risky action.\n\nThe common pattern is not \"answer this question.\" It is **\"hold this seat, use the available context, and be judged by the result.\"**\n\nAnkole 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.\n\nThe runtime is built around five technical bets:\n\n**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.\n\nFor 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/).\n\nThat 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.\n\n``` php\nflowchart LR\n  Providers[\"Chats / webhooks / schedules\"] --> SG[\"SignalsGateway\"]\n  Console[\"Web UI / operator APIs\"] --> CP[\"Control Plane<br/>Phoenix / OTP\"]\n\n  SG --> CP\n  CP --> PG[(\"PostgreSQL<br/>durable truth\")]\n\n  CP <-->|\"RuntimeFabric<br/>live routing\"| Worker[\"Agent Computer<br/>Bun / TypeScript worker\"]\n\n  Worker --> Tools[\"Tools<br/>browser / terminal / files / model calls\"]\n  CP --> Kernel[\"Rust Kernel<br/>AuthZ / runtime primitives\"]\n```\n\nAt a high level:\n\n**SignalsGateway** accepts provider ingress and normalizes it into durable actor events.**Control Plane** owns durable state, actor orchestration, configuration, identity, and authorization.**RuntimeFabric** connects actors, workers, and RPC lanes for live execution over ZeroMQ while PostgreSQL remains the durable source of replay, fences, reconciliation, and final commits.**Agent Computer** executes turns and tools in an isolated worker container.**PostgreSQL** remains the durable record for accepted events, state, fences, and final commits.\n\nAnkole is an early engineering distribution, not a polished end-user product or hosted SaaS. The subsystems below exist as working code in this repository today — the honest caveat is polish and API stability, not vaporware.\n\n| Area | Status |\n|---|---|\n| Control plane | Phoenix/OTP application under `app/control_plane` . Owns durable state, configuration, actor orchestration, Principal/AuthZ, and APIs. |\n| Agent Computer | Bun/TypeScript worker runtime under `app/agent_computer` . Runs the agent loop and local tools inside an isolated Linux worker image; not a standalone CLI. |\n| Kernel | Rust crate under `app/kernel` , loaded by Elixir (Rustler) and Bun (N-API) for crypto, identifiers, AuthZ evaluation, and ZeroMQ transport. |\n| Frontend | Vite + React surfaces under `app/webapps` , built into the Phoenix static shell. |\n| Local services | PostgreSQL is provided through the devkit Docker Compose setup. |\n| Design docs | Architecture and runtime design documents live under `docs/design-docs` . |\n| Public API stability | Internal APIs are still evolving. Expect breaking changes between releases. |\n\nThis repository is the active Ankole control-plane and runtime workspace. It is still an engineering distribution, not a polished end-user release.\n\n`app/control_plane`\n\n- Phoenix/OTP control plane for Principal/AuthZ, AppConfigure, setup, console, plugin registry, I18n, SignalsGateway, actor runtime, RuntimeFabric, and PostgreSQL-owned durable state.`app/kernel`\n\n- shared Rust foundation loaded by Elixir and Bun for crypto, identifiers, phone/JWT helpers, AuthZ evaluation, protobuf envelopes, and ZeroMQ RuntimeFabric transport.`app/agent_computer`\n\n- Bun + TypeScript Agent Computer worker for the local LLM loop, provider adapters, tools, skill loading, files, terminal state, and worker daemon.`app/webapps`\n\n- Vite + React frontend applications for auth, setup, and console surfaces, built into the Phoenix static shell.`app/library`\n\n- built-in agent skills and starter templates such as`MISSION.md`\n\nand`SOUL.md`\n\n.`app/locales`\n\n- shared TOML translation catalogs consumed by the control plane and browser surfaces.`libs/uikit`\n\n- shared UI primitives for Ankole webapps.`libs/feishu_openapi`\n\n- local Lark/Feishu OpenAPI client library.`libs/slack_openapi`\n\n- local Slack Web API, Socket Mode, and OIDC client library.`internals/plugins`\n\n- private first-party provider/plugin code that is kept with the repo but not presented as the public plugin boundary.`tools/devkit`\n\n- workspace automation for local services, app database helpers, code generation, and analysis.`docs/design-docs`\n\n- current design documents for principal identity, authorization, configuration, I18n, plugins, RuntimeFabric, SignalsGateway, and provider adapters.\n\nRuntimeFabric is the live control-plane-to-worker fabric. It carries actor traffic, bounded RPC, and worker-file frames over ZeroMQ while PostgreSQL remains the source of durable replay, fences, reconciliation, and final commits. SignalsGateway is the provider-ingress layer: external chats, webhooks, and provider events become actor events without turning source facts into execution state.\n\nAnkole defaults to Bun for workspace scripts and Elixir/Phoenix for the control plane.\n\n```\nbun install\n\n# Local support services and workspace helpers\nbun kit --help\nbun services:start\nbun services:status\n\n# Control plane\nbun control-plane:setup\nbun control-plane:dev\nbun control-plane:test\n\n# Agent Computer container image and tests\ndocker build -f app/agent_computer/Dockerfile -t ankole-agent-computer:0.1.0 .\nbun agent-computer:test\nbun agent-computer:type-check\n\n# Other Bun packages\nbun webapps:build\nbun feishu-openapi:test\n```\n\nAgent Computer is designed to run as a Linux container runtime. For strong\nbubblewrap command isolation, run Docker with `--cap-add SYS_ADMIN`\n\n,\n`--security-opt seccomp=unconfined`\n\n, and\n`--security-opt systempaths=unconfined`\n\nunless you provide an equivalent custom\nseccomp/profile setup. In Kubernetes, put the equivalent\n`capabilities.add: [\"SYS_ADMIN\"]`\n\n, `seccompProfile`\n\n, and `procMount: Unmasked`\n\non the Agent Computer container `securityContext`\n\n. If strong bubblewrap is\nunavailable, the worker may downgrade to weak bubblewrap (container `/proc`\n\nbind-mounted into bwrap) and emits a startup warning. It never falls back to\nunsandboxed model-facing commands.\n\nPackage-local validation is preferred while the workspace is moving quickly:\n\n```\nbun run --filter @ankole/control-plane test\nbun run agent-computer:test\nbun run --filter @ankole/agent-computer type-check\nbun run --filter @ankole/webapps type-check\nbun run --filter @ankole/feishu-openapi test\n```\n\nOnce the control plane is running, the worker bootstrap helper renders the Docker command used to start an external Agent Computer worker against the local RuntimeFabric endpoint:\n\n```\ncd app/control_plane\nmix ankole.actor_runtime.worker_bootstrap --endpoint tcp://127.0.0.1:6010 --worker-id worker-a\n```\n\nProduction bootstrap configuration uses standard infrastructure names such as `DATABASE_URL`\n\nand `SECRET_KEY_BASE`\n\n. Runtime application configuration belongs in Ankole's PostgreSQL-backed AppConfigure surface rather than process-local environment variables.\n\nBrain requires PostgreSQL 18 with `pg_search`\n\npreloaded and both `pg_search`\n\nand `vector`\n\ninstalled. Model profiles and the destructive-vs-incremental\ndatabase procedure are documented in the\n[Brain operations guide](/AgentBull/ankole/blob/main/docs/operations/Brain.md). Its dedicated real-model\nacceptance path is `tools/e2e/run --brain-real-llm`\n\n; it is not part of the\ndefault test gate or `--all`\n\n.", "url": "https://wpnews.pro/news/show-hn-ankole-claude-tag-open-source-alternative", "canonical_source": "https://github.com/AgentBull/ankole", "published_at": "2026-07-13 18:26:08+00:00", "updated_at": "2026-07-13 18:35:03.815484+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "ai-tools"], "entities": ["Ankole", "Claude Tag", "ZeroMQ", "PostgreSQL"], "alternates": {"html": "https://wpnews.pro/news/show-hn-ankole-claude-tag-open-source-alternative", "markdown": "https://wpnews.pro/news/show-hn-ankole-claude-tag-open-source-alternative.md", "text": "https://wpnews.pro/news/show-hn-ankole-claude-tag-open-source-alternative.txt", "jsonld": "https://wpnews.pro/news/show-hn-ankole-claude-tag-open-source-alternative.jsonld"}}