# Avernet: an Ant Group agent coordination layer whose context and memory are still marked planned > Avernet is an Apache 2.0 infrastructure layer for persistent multi-agent systems, from InclusionAI, deployed across 12 Ant Group business groups. It offers identity, execution, a coordination network, AgentEvolve and TaskGuard, and it is direct about what is not in the public repository: context and memory are planned, and the public demo is explicitly not a demonstration of permission isolation, audit depth or failure recovery. **inclusionAI/Avernet** — Distributed agent coordination platform where agents live, connect, coordinate, execute, and evolve together. - Repository: https://github.com/inclusionAI/Avernet - Stars: 646 · Forks: 67 - Language: Python - License: Apache-2.0 - Published: 2026-09-17 · Updated: 2026-09-17 · Language: en - Canonical page: https://hysenlabs.com/projects/inclusionai-avernet ## Context and memory are the one capability area still marked planned The capability list uses a four-value legend, and one row is worth reading twice. The status note says every core capability area is deployed internally in production, that public open-source coverage varies by component, and that coverage is being released incrementally. Trusted core covers identity, authentication, permissions, security, audit and lifecycle. Execution infrastructure covers heterogeneous engines, bot-as-a-service runtimes, containers and clusters. The coordination network covers discovery, relationship building, team formation, routing, collaboration and governance. Shared intelligence and evolution is the interesting row: bot diagnosis, repeatable Bench evaluation, goal-driven or diagnosis-driven optimization and recoverable Pack versions are all available through AgentEvolve, orchestration is available through the coordination layer, and then context and memory remain planned. That sits awkwardly beside the project's own framing as infrastructure for persistent agents and compounding organisational memory, and beside the fourth bottleneck it says it exists to solve, knowledge not accumulating as organisational capability. The evolution and evaluation machinery is real and public; the memory substrate underneath it is not there yet. ## The public demo disclaims five production properties by name The demo section is unusually forthright, and the specific list of what it does not show is more useful than the list of what it does. It is intended to show local onboarding and the coordination flow, workbench interaction, integration of local test bots, and a reproducible starting point for public evaluation. Then it states plainly that it is not intended to fully demonstrate the production-scale properties of the platform, and it names them: large-scale connection envelopes, permission isolation, audit depth, failure recovery, and long-horizon organisational collaboration. Five named gaps, each of which is a thing you would only discover in production. That is a deliberate choice rather than a marketing one, because a coordination layer whose permission isolation does not hold up is worse than one that never claimed to have any. It also means the evaluation surface for an outside user is the demo plus five local test bots, so any judgement you form from trying it is a judgement about onboarding and the workbench, not about the platform the company runs. ## Twelve business groups and a 90% completion rate with no published method The deployment claim is the most quoted line in the readme and the least specified. It says Avernet is production-tested at Ant Group and that as of early July 2026 it supports multi-agent deployments across 12 business groups, with a 90% or higher task completion rate in measured multi-agent workflows. What follows that sentence is nothing: no denominator for the completion rate, no definition of a task in this context, no description of which workflows were measured, no baseline to compare against, and no explanation of how many of the 12 groups run which capabilities. It is a claim with a date and two numbers attached, which is more than most projects publish and less than you would need to weigh it. The honest way to read it is as evidence that the architecture survives contact with an organisation, not as a performance figure. That reading is reinforced by the status note in the next section, which says all core capability areas are deployed internally while public coverage varies by component, so the thing being measured at scale is not the thing you can install. ## Plugin or gateway is a decision about who is allowed to call whom Two integration paths lead into one collaboration network, and the difference is directional rather than technical. Plugin integration is for OpenClaw, local agent runtimes and custom bot processes, and it works by agents actively connecting to Avernet through a plugin or a runtime for registration, onboarding, message receiving and result reporting. The agent initiates, so the agent decides when to show up, and Avernet never has to know how the agent was started. Gateway integration is for existing bot platforms, multi-instance agent services and external scheduling systems, and it works the other way round: Avernet dispatches tasks to the external platform, which schedules the agents and reports results back when the work completes. There the platform owns scheduling and Avernet pushes work in. The architecture diagram collapses both into a single hub, with three labelled inputs, local agents in plugin mode, an agent runtime behind a websocket bot route, and an existing bot platform through a downlink gateway. Which path you take determines where retries, timeouts and backpressure live, and that is the decision to make before writing any integration code. ## The documented layout is headed ocb/ and the repository root says something else The repository layout section in the readme does not match the repository. The block is headed ocb/ and lists a .env example, a Dockerfile with an ocb suffix, a compose file, docs, scripts, a src directory containing frontend, bcs and plugin, tests, an agents file, the two readmes. The actual top level is a different set of names: apps, devops, docker, docs, engine, middleware, scripts, singlebox and spec, alongside two context files, an agents file, a configuration directory, githooks and the two readmes. So the documented source layout has no src at the top level in what was collected, the container files are named differently, and the directories that carry the actual structure, engine, middleware, singlebox and spec, do not appear in the layout block at all. This is normal drift in a repository with two context files and a Chinese readme, and it is worth flagging because the layout block is what a new contributor reads first. The directory names are the better guide: singlebox is the recommended install path, spec is where the contracts presumably live, and engine and middleware are where the machinery is. ## singlebox is the recommended install and it brings up five bots The recommended local path is a two-command script rather than a compose file: ```bash ./singlebox/singlebox.sh install-tools ./singlebox/singlebox.sh ``` The first command installs tooling, the second brings the stack up, and what comes up is described as an Avernet process, a frontend workbench and five local test bots, with the workbench served on port 8000 bound to loopback. So a fresh evaluation gives you one process to run, a browser to open, and five bots to watch coordinate, which is the fastest possible route to seeing whether the onboarding and coordination flow is understandable. Docker is available and documented separately, along with quick start and dependency guides, but it is presented as the advanced route rather than the default. The five bots are the detail that makes this a demo rather than a test: they are seeded local agents, not connectors to real runtimes, which is consistent with the demo section's own list of what is not being shown. Nothing in the quick start asks you for credentials from an external bot platform, so you can reach the workbench without deciding which integration path you want. ## Date-based tags three releases apart, then two months of commits The versioning scheme is a calendar date in the tag name, and the three published releases sit close together: v2026.07.28 published on 2026-07-29, v2026.07.30 published on 2026-08-01, and v2026.08.04 published on 2026-08-05. Two of the three are therefore published the day after their tag date, and the naming makes a tag sortable by intent rather than by publication. The other side of that coin is that the newest tag is v2026.08.04 and the last push is dated 2026-10-01, so two months of work sit after the last release with no tag to point at, which is the same unreleased-main-branch situation the release notes elsewhere warn about for comparable projects. The number that tells you more is the issue count. There are 129 open issues against 595 stars and 63 forks, which is a ratio that suggests either an active internal user base filing real work or a project whose public backlog has stopped being triaged. Either reading argues for pinning a tag and reading the issue tracker before you depend on it. ## A contributor security note and no security policy file The security section is four lines long and it is addressed to contributors rather than to users or operators. It says not to commit secrets, tokens, cookies, private keys, private service endpoints, local databases, runtime logs or machine-specific configuration. It then says that if credentials have already been committed, you should revoke or rotate them before cleaning repository history, which is the correct order of operations and rarer than it should be. What is not here is as notable as what is. The repository contains no security policy file, no disclosure process, no contact for reporting a vulnerability, and no statement about how internal deployments authenticate agents to each other, which for a coordination layer is the question a security reviewer asks first. The trusted core capability area lists authentication, permissions and audit as production concerns, so the machinery exists; none of it is described in the public readme. If you are evaluating Avernet for a shared environment, permission isolation and audit depth are exactly the two properties the demo also disclaims, and they are the two you will have to take on trust. ## Conclusion Avernet is worth reading as a statement of what an organisation-level agent platform needs, because the four bottlenecks it names, discovery, alignment, speed and retention, are the right four, and the capability areas it maps onto them are honest about their state. Read it as a product to adopt and the answer is different. The component you would most want for a persistent agent, memory, is marked planned, the public demo disclaims permission isolation, audit depth and failure recovery by name, and 129 open issues against 595 stars is a support surface you should plan around. The integration design is the part most worth stealing: plugin for agents that call in, gateway for platforms you dispatch out to, and a single coordination network above both. Before you invest, confirm three things: which capability areas are actually available in the repository today rather than in production at the company, whether your agents can live with stateless context while memory is unfinished, and whether a two-month gap between the newest release tag and the last push matches your tolerance for pinning a platform dependency. ## FAQ ### What is Avernet? Avernet is an Apache 2.0 open-source infrastructure layer for building and operating persistent, coordinated, multi-agent systems at organisational scale, from InclusionAI. It covers a trusted core for identity, permissions, security and audit, execution infrastructure for heterogeneous engines and containers, a coordination network for discovery and team formation, and building blocks for agent and canvas apps. ### Can Avernet remember context between sessions today? No, and the project says so. In the shared intelligence and evolution capability area, bot diagnosis, Bench evaluation, optimization and recoverable Pack versions are available through AgentEvolve, and context and memory are listed as planned. The readme also flags permission isolation and audit depth as production-scale properties the public demo does not demonstrate. ### How do I connect an agent to Avernet? There are two paths. Plugin integration is for OpenClaw, local runtimes and custom bot processes, where the agent connects in for registration, onboarding, message receiving and result reporting. Gateway integration is for existing bot platforms and external schedulers, where Avernet dispatches tasks out and the platform schedules agents and reports results back. ### How do I run Avernet locally? Clone the repository and run the singlebox script twice: first install-tools, then the script itself with no arguments. That brings up an Avernet process, a frontend workbench and five local test bots, with the workbench on http://127.0.0.1:8000/. Docker setup is documented separately as the advanced path. ### Is all of Avernet open source? Not according to its own status note, which says all core capability areas are deployed internally in production while public coverage varies by component and is released incrementally. The readme uses a four-value legend, available, partial, in progress and planned, precisely because the answer differs per component. ## Sources - [inclusionAI/Avernet on GitHub](https://github.com/inclusionAI/Avernet) - [Issues](https://github.com/inclusionAI/Avernet/issues) - [License: Apache-2.0](https://github.com/inclusionAI/Avernet/blob/dev/LICENSE) - [README](https://github.com/inclusionAI/Avernet/blob/dev/README.md) - [Releases](https://github.com/inclusionAI/Avernet/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/inclusionai-avernet