A toolkit for creating specialized, self-improving agent systems from a specification and the knowledge your work already has.
ZeneraNeo turns a clear description of a job into an agentic system built for that job. Give it the documents, policies, API schemas, files and integrations the work depends on; describe the outcome and its constraints; then let the meta-agent design the specialists, tools, skills, memory, handoffs, retrieval and execution strategy that fit.
ZeneraNeo is for recurring work that needs more than one general-purpose chat: technical investigation, policy review, operations triage, software delivery, analysis, and workflows that must show their evidence. The result is a project you can run, inspect, improve, review and share.
This is an open-source side project for experimentation and chore work. It is not the official Zenera AI Platform, and it carries no support or stability promises.
You need Node.js 24+ and Podman (agents run commands in a container).
Install the packages:
npm i -g @zenera/cli @zenera/neo @zenera/meta @zenera/rag @zenera/gymzen key add openai
zen meta model --pickzen init my-project
zen open my-projectzen open my-project opens the project in your default editor.
Start editing SPECIFICATION.md.
SPECIFICATION.md is the file where most of the work on your project happens.
Use it to describe the purpose of the project, its models, its agents, and
other details. It is free-form: you can describe the agents in your own words,
and the meta-agent turns that description into the actual system.
SPECIFICATION.md may include, but is not limited to, these items:
- Purpose - what the project is for.
- Models - the chat and embedding models the project uses.
- Setup - what must be done before the first run, such as downloading data and building indexes.
- Agents - what each agent does, its rules and its tools.
- Knowledge - existing, read-only materials the agents can read, such as documentation indexes and API schemas.
- Memory - what the agents should remember between runs, and when to look in memory first.
❓ Why are different models configured?
Because both are needed:
- The meta-agent model (
zen meta model --pick) is used byzen metato build the project. It writes the agents, scripts and configuration, so choose a strong reasoning model. It is set once per machine and is not part of the project.- The project models (the
## Modelssection ofSPECIFICATION.md) are used by the generated agents when they run. They are stored in the project (agents.yaml), so anyone who clones it runs the same system. They include an embedding model for indexes and memory. A chat model cannot be used for embeddings, and changing the embedding model requires re-indexing.
See a complete example in
SPECIFICATION.md of
example 01.
Worked examples available now:
- 01 - Documentation RAG: answers questions about the Hugging Face Transformers documentation from an index built out of it.
- 02 - API Integration: finds a meeting request in a mock mailbox, checks mock calendar availability and, after you confirm, creates an event and sends a confirmation.
Once SPECIFICATION.md is filled in, run this in the CLI:
zen meta run my-project /spec-sync-projectIt generates and updates the system.
Check whether SPECIFICATION-FEEDBACK.md exists.
The meta-agent does not guess: if something is unclear, it asks.
SPECIFICATION-FEEDBACK.mdis a questionnaire.- Every question carries two to four written-out answers, each with a
[ ]box. - Put an
xin the box of the answer you want, delete the ones you do not, or write your own in their place. Any of these counts as an answer. - Apply the feedback:
zen meta run my-project /spec-apply-feedbackEnter the project directory:
cd my-project
zen checkto verify that the project loads and the models answer.zen run my-project "your question"to run it. Without a question it opens an interactive terminal app.
zen inspectto open the report of the last run: its trajectory and improvement opportunities.
When you are standing inside a project, the project name is optional: a bare
zen run,zen checkorzen inspectmeans the project you are in.
The meta-agent is the agent that builds your system. It ships as @zenera/meta, which adds zen meta to the CLI, and works on your project as a developer would:
- reads
SPECIFICATION.mdand generates the project from it: agents, prompts, tools, skills, memory rules and setup scripts; - runs the setup (for example, builds the search indexes) and checks that the result works;
- asks questions in
SPECIFICATION-FEEDBACK.mdwhen the specification is unclear, instead of guessing; - reads the trajectories of your runs and proposes improvements to the specification.
You describe the job in SPECIFICATION.md; the meta-agent writes the system.
The agents it creates are the ones you later run with zen run.
People define the job; they should not have to hand-design every agent, prompt,
handoff, tool, memory rule and evaluation loop required to do it well.
SPECIFICATION.md is the source of intent: the work to perform, the knowledge
to use, the boundaries to keep, and the criteria that define success.
ZeneraNeo's meta-agent turns that intent into a working system, then autonomously tests it, examines its observable trajectory, and proposes improvements to the specification. The next system is generated from that improved intent. This is a continuous loop for making a specialized system more effective without losing the human-defined purpose and constraints.
The loop is deliberate. A run is not only an answer; it is evidence about the system that produced it. ZeneraNeo records the trajectory, evaluates the result against the specification, identifies changes that improve quality, accuracy, latency or token use, and turns those findings into reviewable updates.
Projects are ordinary Markdown and YAML, so the intent, generated system and proposed changes can be versioned in Git and reviewed like any other software. Each run leaves an inspectable trajectory of the prompts, agent handoffs, tool calls, results and usage that produced it. Teams can examine that record themselves or give it to a meta-agent to evaluate outcomes, diagnose weak steps and propose the next improvement with evidence.
- Specialized agents with distinct responsibilities, models and execution boundaries, instead of one prompt asked to do everything.
- Teams that coordinate through explicit handoffs, parallel work and strategies matched to the task.
- Knowledge systems over documentation and API schemas, with retrieval that can discover, inspect and verify evidence.
- Tools and integrations selected for the job, with file access, sandboxed commands and generated integrations where they are needed.
- Durable memory that carries useful context between runs without relying on an ever-growing chat transcript.
- Evaluation and observability through self-tests, success criteria and trajectories that explain what happened, how long it took and what it used.
- Shareable projects expressed as Markdown and YAML, ready for source control, code review and reuse by another team.
| Package | Role |
|---|---|
@zenera/cli |
The zen command-line workflow for creating projects, generating agent systems, running them, testing them and inspecting their trajectories. |
@zenera/neo |
The TypeScript runtime for applications that need agents, models, tools, skills, memory, trajectories and project loading directly in code. |
@zenera/engine |
Runs a project the way zen run does - keyring, sandbox, sessions, run records - for a server or any other host that is not the CLI. |
@zenera/meta |
The meta-agent behind zen meta: builds a project from its specification, runs its commands, keeps its evaluation dataset and fine-tunes its prompts against it. |
@zenera/rag |
Advanced retrieval for agent knowledge: semantic, full-text and hybrid search over documents, plus graph-aware API schema indexing and search. |
@zenera/gym |
Stateful mock APIs from OpenAPI and Swagger descriptions, populated from a story of the world and reference documents. |
@zenera/cli installs zen; @zenera/meta, @zenera/rag and @zenera/gym
extend it with their own subcommands. Install only the capabilities a project needs.
- Specification-driven projects
- Agent configuration
- Projects and sharing
- Agent knowledge and document retrieval
- API integrations
- Memory
- Who a run acts for
- Fine-tuning and writing rubrics
- Every model through a Bifrost gateway
Early days and moving fast - issues, questions and pull requests are welcome. MIT.