Running Parendum on Nexora: an AI dev team with one human supervising

We build Nexora using Nexora. Not as a demo and not as a marketing stunt — it is genuinely how a lot of the work gets done. A small set of agents handles planning, implementation, review, and documentation across our repositories, and one person supervises the whole thing. This post is an honest account of how that actually works, including the parts that are still rough.

The team

The configuration mirrors a normal engineering team, mapped onto agents. It is roughly the shape of the AI Dev Team pack you can install from the marketplace, tuned to our repos.

• dev_lead — reads an issue, breaks it into concrete steps, decides which repository and files are involved, and delegates to sub-agents. It owns the plan, not the keyboard.
• implementer — the agent that actually edits code. For larger issues the dev_lead spins up more than one, each scoped to a bounded part of the change so they do not collide.
• reviewer — reads the diff before anything is proposed for merge. It flags correctness bugs, missing migrations, and places where a change in core needs a matching change elsewhere.
• scribe— keeps the repository's notes and changelog honest. When behaviour changes, it updates the docs so the next agent (or human) is not working from a stale map.
• feedback_triage — takes incoming reports and requests, deduplicates them, and turns them into well-formed issues with enough context to act on.

How a change actually moves

A typical loop starts with an issue. The dev_lead picks it up, writes a plan, and hands implementation to one or more implementer agents. They stream their work in real time — you watch the tool calls happen, the files change, the tests run — so there is no opaque "come back in ten minutes" box. The reviewer reads the resulting diff and comments. The scribe updates docs and the changelog. The human in the loop approves, redirects, or stops it.

The agents lean on the same ~90 builtin tools and ~15 skills that ship with the platform: reading and writing files, running commands, opening issues and merge requests, posting status to chat. Nothing here is bespoke glue we wrote just for ourselves — it is the product our customers get.

What "one human supervising" really means

We want to be precise, because this is where AI tooling tends to overclaim. The human is not idle and the agents are not autonomous in any unattended sense. The supervisor sets direction, approves anything that touches production or money, breaks ties when the reviewer and implementer disagree, and catches the cases where an agent is confidently wrong. The leverage is real — one person can keep several streams of work moving at once — but it is leverage, not replacement.

The failure modes are ordinary engineering ones. An implementer occasionally misreads the scope of an issue and edits more than it should; the bounded-scope rule and the reviewer catch most of that. A plan sometimes misses a cross-repository dependency — for example a core change that needs a submodule sync downstream — which is exactly the kind of thing the supervisor watches for.

Why we run this way

Dogfooding keeps us honest. Every sharp edge our agents hit is one a customer would hit, so we feel the bugs before they do. It also makes the sovereignty argument concrete: our own dev team's access to our own code and infrastructure never leaves our infrastructure, because that is how Nexora is built to run. We would not ask anyone to trust a setup we were not willing to run on our own production.

If you want to try the same shape, the AI Dev Team pack in the marketplace is the starting point we work from. It will not run your team for you. But with one person paying attention, it can do a surprising amount of the work.