# Nexent: a zero-code platform that generates AI agents from a prompt

> Nexent is an MIT-licensed Python platform that turns a natural-language description into a runnable agent, shipped through Docker or Kubernetes. The deployment scripts are the most documented part; the agent-generation internals are not.

**ModelEngine-Group/nexent** — Nexent is a zero-code platform for auto-generating production-grade AI agents using Harness Engineering principles, unified tools, skills, memory, and orchestration with built-in constraints, feedback loops, and control planes.

- Repository: https://github.com/ModelEngine-Group/nexent
- Stars: 5,890 · Forks: 732
- Language: Python
- License: MIT
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/modelengine-group-nexent

## What Nexent is for, and who it is aimed at

Nexent describes itself as a zero-code platform for auto-generating production-grade AI agents. The pitch in the README is that you describe requirements in natural language and get an executable agent, with no drag-and-drop orchestration graph to wire up. The stated design basis is something the project calls Harness Engineering, which in the README's framing means unified tools, skills, memory and orchestration, plus built-in constraints, feedback loops and control planes.

The people this is written for are the ones who would otherwise assemble an agent from a framework plus a vector store plus a scheduler. The repository is Python, MIT-licensed, and ships both a backend and a frontend directory, so it is a full application rather than a library you import. If you are looking for a pip-installable package that gives you a function to call, the repository layout does not suggest that is the shape of the project. It suggests a service you deploy and then drive through its interface.

One thing worth flagging early: the README does not present Nexent as a research framework. The feature table lists multi-model integration, A2A agent collaboration, a two-tier memory mechanism, progressive skill disclosure and a personal-grade knowledge base. That is a product feature list, and it tells you the intended user is someone running agents in a private environment rather than someone publishing papers.

## How the pieces fit together: deployment model, memory and skills

What is actually visible from the repository is the deployment architecture. Nexent is a multi-service application. The top-level entries include backend/, frontend/, sdk/, deploy/, docs/ and a pathology-ai/ directory, and the deploy scripts reference an infrastructure component plus application, data-process and supabase components. That last one is the clearest structural signal: the platform expects a Postgres-family database and its auth layer to be present, which is why supabase is a selectable component rather than an optional extra.

On the agent side, the README names two mechanisms worth understanding. The first is layered memory, described as two tiers: user-level and user-agent-level. The distinction matters because it determines what persists when you talk to the same agent from a different session versus what persists when a different agent talks to you. The README states the tiers exist; it does not document the eviction policy or how conflicts between the two tiers are resolved.

The second is progressive skill disclosure, described as dynamically loading a Skill into context to conserve the context window. That is a real constraint being managed: rather than putting every tool description in the prompt, the platform loads skills as they become relevant. The README gives the intent but not the selection algorithm. If your workload depends on predictable tool availability, that gap is something you would have to close by reading the source.

The orchestration layer also speaks A2A, the agent-to-agent protocol, for multi-agent cooperation. The README calls this distributed workflows. It does not document the transport, whether agents discover each other or are configured explicitly, or what happens when a peer is unreachable.

## Installing Nexent with Docker and running a first agent

The README gives Docker as the recommended path for individuals and small teams, and Kubernetes for enterprise production. The prerequisites for Docker are Docker 24 or newer and Docker Compose v2 or newer. The minimum resources stated for Docker are 4 CPU cores, 8 GiB of memory and 40 GiB of disk; the recommended figures are 8 cores, 16 GiB and 100 GiB. Both x86_64 and ARM64 are listed.

The documented entry point is the root deploy.sh, which the README says only forwards to the target deploy script. The native Docker implementation lives at deploy/docker/deploy.sh.

```bash
git clone https://github.com/ModelEngine-Group/nexent.git
cd nexent
bash deploy.sh docker
```

Run interactively, this opens Bash TUI menus for component selection, port policy and image source. The README states that infrastructure is required, while application, data-process and supabase are selected by default and can be turned off to get a smaller deployment. Use b or Backspace to step back and q to quit.

If you want the script to skip the menus, pass --defaults. It will then use a saved deploy.options file or the built-in defaults.

```bash
bash deploy.sh docker --defaults
```

The same choices can be passed non-interactively with --version, --components, --port-policy development|production and --image-source general|mainland|local-latest. After a successful deployment, the non-sensitive choices are written to deploy.options in the deploy directory for reuse.

Runtime configuration is read from deploy/env/.env. The README says an existing deploy/env/.env is kept as-is; if it does not exist, the scripts first reuse docker/.env and then fall back to deploy/env/.env.example. Monitoring settings are generated separately from deploy/env/monitoring.env.example into deploy/env/monitoring.env. That fallback order is the thing to check after your first run: if your provider credentials are not taking effect, confirm which file the script actually loaded.

Uninstalling is a separate script. The README documents that it can preserve or delete data volumes, either interactively, via --delete-volumes true|false, or with a delete-all argument that removes containers and persistent data.

## Where Nexent gets thin: offline installs, rollback and the Python surface

The offline path is documented in more detail than most projects manage, and it is also where the sharp edges are. Building a package is done with bash build.sh --package --target docker --compress true, or with deploy/offline/build_offline_package.sh. The README states the resulting package contains image tar files, load-images.sh, push-images.sh, the root deploy and uninstall entrypoints, deployment scripts, SQL files, manifest.yaml and checksums.txt. Deploying from a package uses saved deploy.options or built-in defaults without opening the TUI, unless you add --config.

The constraint is that package deploys do not prompt. If the saved options do not match the target host, you find out at deploy time rather than before. Pushing to an internal registry has its own wrinkle: when --push-images is used without a prefix, deploy.sh asks for the prefix before push-images.sh prompts for the registry username and password. That is two separate prompts across two scripts, which is easy to get wrong in automation.

The larger gap is rollback. The README documents uninstall thoroughly, including volume preservation flags, but it does not document downgrading a deployment or reverting a failed upgrade. Releases are tagged (v2.3.0, v2.4.0, v2.5.0), so version pinning exists as a concept, but the procedure for going back is not in the README.

The second gap is programmatic access. There is an sdk/ directory in the repository, but the README does not document a Python API for generating agents. Everything described in the README is deployment and configuration. If your plan is to call Nexent from another service to mint agents on demand, the README does not tell you how, and you would be reading sdk/ to find out.

A third, smaller issue: the README asks readers to star the repository before getting started. That is a marketing ask sitting in the installation section, and it is the kind of thing that makes the rest of the documentation harder to trust at a glance.

## Nexent compared with assembling LangGraph or CrewAI yourself

The honest comparison is not Nexent versus another zero-code agent builder, because the README does not name one. It is Nexent versus writing the orchestration yourself in a Python agent framework such as LangGraph or CrewAI.

The difference in approach is where the complexity lives. With a framework, you write the graph, you choose the memory store, you decide how tools are described to the model, and you own the deployment. You get a library and a blank page. Nexent inverts that: you get a deployed service with a database, a frontend, an auth layer and a set of opinions about memory tiers and skill loading already baked in. Your job shifts from writing orchestration code to describing an agent in language and configuring the environment around it.

That trade is real in both directions. A framework gives you a diffable artifact you can review in a pull request. Nexent gives you a running system whose generated agents are not, as far as the README shows, checked into your repository as code. If your team's review process depends on reading agent definitions before they ship, that is a meaningful difference and the README does not address it.

On the other side, the operational surface is smaller with Nexent. You are not picking a vector database, wiring an auth provider and writing a scheduler. The README's component list (infrastructure, application, data-process, supabase) is the whole stack, and the deploy script installs it. For a small team without a platform engineer, that is the entire argument for using it.

## Licence, maintenance and what an upgrade actually costs

Nexent is MIT-licensed. The repository carries both a LICENSE and a NOTICE file, which is worth noting: a NOTICE file usually accompanies third-party attribution requirements, so if you redistribute Nexent inside a product, read NOTICE alongside LICENSE rather than assuming MIT alone settles the question. That is an observation about the file layout, not legal advice.

The last push to the default branch, develop, was on 2026-08-29. The most recent release, v2.5.0, carries the same timestamp, with v2.4.0 on 2026-08-05 and v2.3.0 on 2026-07-16. The cadence visible in those three tags is roughly one minor release per month. The repository is not archived.

Upgrade cost is where the deployment design helps and hurts. It helps because the same deploy/env/.env drives both Docker and Kubernetes, and because non-sensitive choices persist in deploy.options. Re-running the deploy script for a new --version is the documented path. It hurts because the README does not document a downgrade or rollback procedure, so the cost of a bad upgrade is not stated anywhere you can plan against. If you run this in production, take your own database backup before upgrading, because the platform's persistent state lives in the data volumes that uninstall.sh can delete.

There is also a Kubernetes-specific cost. The minimum memory listed for Kubernetes is 16 GiB against 8 GiB for Docker, and the recommended figures are 64 GiB and 200 GiB of disk. That is not a small jump, and it reflects the fact that the Kubernetes path renders Helm ConfigMap and Secret overrides and manages persistent volumes through --persistence-mode, --storage-class, --local-path and related flags. You are paying for the orchestration layer whether or not you need it.

## Conclusion

Adopt Nexent if you want an agent stack you can stand up with bash deploy.sh docker on your own hardware and you are comfortable reading deploy/ scripts to answer questions the README does not. Do not adopt it if you need a documented Python API for generating agents programmatically, or if you cannot give a Docker host 8 GiB of memory and 40 GiB of disk. Before committing, verify two things: that the model provider you intend to use is reachable through the OpenAI-compatible interface the README claims, and that the .env keys written by the deploy script match the providers you actually have credentials for.

## FAQ

### What is Nexent?

Nexent is a zero-code platform for auto-generating AI agents, built on what the README calls Harness Engineering principles. It provides unified tools, skills, memory and orchestration with built-in constraints, feedback loops and control planes, and it is written in Python under the MIT licence.

### How do I install Nexent?

The README recommends cloning the repository and running bash deploy.sh docker, which requires Docker 24 or newer and Docker Compose v2 or newer. An interactive TUI lets you choose components, port policy and image source, or you can pass --defaults to skip it.

### How much memory does Nexent need?

The README lists 8 GiB of memory as the Docker minimum and 16 GiB as recommended, with the Kubernetes minimum at 16 GiB and 64 GiB recommended. Disk minimums are 40 GiB for Docker and 100 GiB for Kubernetes.

## Sources

- [Official README](https://github.com/ModelEngine-Group/nexent#readme)
- [Project repository](https://github.com/ModelEngine-Group/nexent)
- [Release notes](https://github.com/ModelEngine-Group/nexent/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/modelengine-group-nexent