EvoNexus: a Claude Code CLI wrapper that turns one agent into 38

The problem EvoNexus targets is not agent capability, it is agent addressability

Most people running the Claude Code CLI end up with a single general-purpose assistant and a growing pile of prompt files. The README frames EvoNexus as the answer to that: a layer that turns one CLI installation into a named team, split into 17 business agents covering operations, finance, community, marketing, HR, legal, product, data and learning retention, and 21 engineering agents covering architecture, planning, code review, testing, debugging, security, design, cycle orchestration and retrospective. The audience is explicit in the repository description: the operating system for AI-powered businesses. In practice that means a small company or an internal platform team that wants recurring work (meeting sync, email triage, community health, financial metrics) to have a stable owner rather than being re-prompted each time. The README states plainly that this is not a chatbot, and the feature list backs that up with routines, HTML report generation and a scheduler. The interesting claim is not that 38 agents exist. It is that they are files, not services.

Agents are markdown files, and that single decision shapes everything else

The README says agents are .md files containing system prompts, with no SDK and no compile step. Adding an agent means dropping a file into .claude/agents/, and reusable bundles go through the plugin system introduced in v0.33.0, which the release title calls the plugin contract release. Skills follow the same pattern: 190 or more markdown capabilities organised by domain prefix, with names like social-, fin-, int-, prod-, mkt-, gog-, obs-, discord-, pulse-, sage-, hr-, legal-, ops-, cs-, data-, pm- and dev-. The engineering layer is documented as following a canonical 6-phase workflow in .claude/rules/dev-phases.md, and 19 of those 21 engineering agents are derived from oh-my-claudecode, an MIT-licensed project by Yeachan Heo, with Helm and Mirror described as native. Memory is two-tier: a CLAUDE.md file plus a memory/ directory, described as an LLM Wiki pattern. The consequence of the markdown-first choice is that the boundary between configuration and prompt engineering dissolves. You get diffable, reviewable agent definitions that live in git, which is a genuine advantage over agent frameworks where behaviour is scattered across Python decorators. You also get no type checking, no schema validation visible in the README, and no obvious way to unit-test an agent prompt short of running it.

Provider switching runs through OpenClaude, not through EvoNexus itself

The multi-provider claim deserves to be read carefully. EvoNexus runs natively on Anthropic's claude CLI by default. To reach OpenAI, Google Gemini, OpenRouter (the README says 200+ models), AWS Bedrock, Google Vertex AI or Codex Auth, it routes through OpenClaude, an npm package published as @gitlawb/openclaude. The README says the switch happens from the dashboard with no code changes, and that agents, skills and workflows stay the same. So the portability is real but it is delegated: EvoNexus is not implementing an abstraction layer over six provider APIs, it is depending on a third-party bridge. That matters for two reasons. First, your provider compatibility is bounded by what OpenClaude supports, not by what EvoNexus documents. Second, the README's own disclaimer is unusually direct about the relationship with Anthropic: EvoNexus is independent and unofficial, not affiliated with, endorsed by or sponsored by Anthropic, and users must supply their own Claude Code installation and credentials. Anyone evaluating this for a company should treat that disclaimer as the accurate description of the support relationship, not the marketing copy around it.

The dashboard, the routines and the heartbeat model

Beyond the agent files, EvoNexus ships a React plus Flask web dashboard with authentication, roles, a web terminal and service management. Routines are split into 7 core and 20 custom, described as daily, weekly and monthly ADWs managed by a scheduler. Heartbeats are the mechanism worth understanding: proactive agents that wake on a schedule, run a 9-step protocol, and then decide whether to act. That decision step is the difference between a cron job and an agent, and it is also where the cost model lives, since the README lists JSONL logs, execution metrics and cost tracking per routine as observability features. The Goal Cascade provides a Mission to Project to Goal to Task hierarchy, and Tickets are persistent conversation or work threads with atomic checkout, which suggests the project expects more than one agent to contend for the same work item. Integrations are listed at 19 or more: Google Calendar, Gmail, Linear, GitHub, Discord, Telegram, Stripe, Omie, Bling, Asaas, Fathom, Todoist, YouTube, Instagram, LinkedIn, Evolution API, Evolution Go and Evo CRM, mostly reached over the Model Context Protocol. Optional semantic search comes from MemPalace, described as local ChromaDB vectors with one-click install. Note the Brazilian payment and ERP providers in that list. They are a strong signal about the project's primary user base.

Getting it running: what the repository actually tells you

The README's Quick Start section is linked from the header navigation but the supplied text does not include its contents, so I cannot give you the install commands without inventing them. What can be stated from the material: the project is Python, the default branch is main, and the runtime prerequisite is a working Claude Code CLI installation with your own credentials, or OpenClaude for alternate providers. Agent files belong in .claude/agents/, the engineering workflow rules live at .claude/rules/dev-phases.md, and persistent memory is split between CLAUDE.md and a memory/ directory. Slash commands are the invocation surface, with /clawdia, /flux, /pulse and /apex named in the README as ways to call agents directly from the terminal. Custom agents follow a custom-* naming convention and are gitignored, which is a deliberate choice to keep personal or client-specific agents out of the shared repository. Before you plan a rollout, read docs/introduction.md, which the README points to for the plugin system, and check the release notes for v0.33.0 since it is the release that defines the plugin contract.

Where EvoNexus is the wrong tool

The plugin contract only became a named release in v0.33.0, and the version history in the supplied material shows three releases inside April 2026 alone: v0.32.2 on the 24th, v0.32.3 on the 25th, v0.33.0 on the 26th. That cadence is a warning for anyone planning to build on the plugin API, because a contract that new will move. The markdown-first design has a second failure mode: with 38 agents and 190 or more skills, discoverability depends entirely on naming conventions and directory structure, and the README offers no index. If two agents claim overlapping responsibility, nothing in the described architecture resolves the conflict except the human reading the files. The heartbeat model raises a cost question the README does not answer: agents that wake on a schedule and then decide whether to act will consume tokens on the decision even when the answer is no, and while cost tracking per routine is listed as a feature, there is no published guidance in the supplied material on expected spend. Finally, if your team does not already use the Claude Code CLI, adopting EvoNexus means adopting two dependencies at once, the CLI and the operating layer, and the disclaimer makes clear that Anthropic supports neither arrangement.

The honest alternative is a plain agent framework, and the difference is where behaviour lives

The obvious comparison is a code-first agent framework such as LangGraph, CrewAI or the Claude Agent SDK, where an agent is a class or a graph node and orchestration is expressed in Python. EvoNexus inverts that: orchestration is expressed as markdown files in .claude/agents/ plus a scheduler, and the runtime is the Claude Code CLI rather than your own process. The practical difference shows up in three places. Testing: a code-first framework lets you assert on agent state transitions without spending tokens, while a markdown agent can only be validated by running it. Portability: a code-first framework owns its provider abstraction, whereas EvoNexus delegates that to OpenClaude. Time to first value: dropping a .md file into a directory and invoking it with a slash command is faster than writing a graph, provided the CLI is already installed and you accept the file-based model. The other comparison worth naming is oh-my-claudecode itself, since 19 of the 21 engineering agents are derived from it under MIT. If engineering workflow is all you need, going to the upstream project directly avoids the business-agent layer entirely.

Maintenance cost, licence status and the fork question

The repository metadata supplied here reports the licence as NOASSERTION, while the README badge and its link point to Apache 2.0. GitHub returns NOASSERTION when it cannot match a licence file to a known template, which can mean a modified licence, a non-standard LICENSE file, or a detection failure. I cannot tell you which applies from the material available, and I am not in a position to give legal advice. What I can say is that the discrepancy is the first thing to resolve if you intend to redistribute EvoNexus, embed it in a product, or fork it, because Apache 2.0 and an unresolved licence are different propositions. There is a second attribution layer: the 19 engineering agents derived from oh-my-claudecode carry MIT obligations, and the README credits Yeachan Heo by name, which is the right instinct but does not by itself satisfy the licence. On ongoing cost, the upgrade surface is larger than the version number suggests. A release like v0.33.0 that changes the plugin contract can invalidate custom agent bundles, and with 38 agents, 190 or more skills and 27 routines in the tree, a rebase against upstream is a review task, not a pull. Budget for reading release notes before every minor bump.

Editorial conclusion

Adopt EvoNexus if your team already lives inside the Claude Code CLI and wants a repository-shaped place to put business routines, scheduled reports and a local dashboard without building that scaffolding yourself. Do not adopt it if you need a stable, versioned plugin API today, if you cannot read Portuguese-adjacent documentation conventions comfortably, or if your organisation treats licence clarity as a procurement gate: the repository metadata reports NOASSERTION while the README badge and link point at Apache 2.0, and that discrepancy should be resolved with the maintainers before you fork or redistribute. Verify first that the v0.33.0 plugin contract is documented well enough for the agents you intend to write, and confirm which of the 21 engineering agents you actually need, since 19 of them are derived from oh-my-claudecode under MIT and carry that project's attribution obligations.

Official sources

1. evolution-foundation/evo-nexus on GitHub
2. Issues
3. Project website
4. README
5. Releases