Agent crew & pipeline

gen_agent_crew · slug agent-crew · 🧑‍🚀

Every other generator in the catalogue produces something for you to read, open or ship. This one produces Novaterra itself: a set of agents that exist in your world after the run, and the generator that drives them, wired to each other in one plan.

It is the orchestration case — author the crew, author the pipeline, connect them — expressed as an ordinary five-step pipeline, because that is what it is.

Inputs

Field	What it is
What should this crew do?	The work the team exists to do, in your own words. Be concrete about the output you want
plus the usual generator form fields	audience, tone, and how many agents to raise

What you get

• Agents, saved and assignable — real Agent rows you own, each with a role team assembly understands (researcher, writer, editor, engineer, designer, analyst, marketer, lead) and skills that actually exist.
• A generator, saved and runnable, whose steps name those agents.
• A handbook describing the crew and how to run it.

The failure this generator is built around

A model writing an agent’s skills[] is guessing at a catalogue it half-remembers, and docs.write_word for docs.write_docx, or web_search for web.search, is the normal guess, not the pathological one. A crew with a skill nobody has is not a crew that half works: the planner drops the unknown name, team assembly builds the agent without the tool its role was written around, and the run reports green having produced something with a hole in it.

So the pipeline is defended three times, and none of the defences is prose:

1. The real skill names are written into the prompt. The built-in catalogue is interpolated verbatim, so the crew designer is not guessing in the first place.
2. studio.author_agent and studio.author_generator validate every name against the live registry before a row is written, and refuse the call — naming the offending skill and the real one it was probably meant to be. Nothing half-written is saved.
3. The agents and pipeline steps declare a deliverable contract with an authored clause, so a step that ended up creating nothing fails the run rather than shipping a handbook about a crew that does not exist. The verdict comes from the authoring skill’s own reported result, never from the model’s account of it. See Outputs: deliverable contracts.

The prompt teaches the common case; the skill enforces the actual one. That division matters because the built-in list is authored once at boot while the live set is per-being — a granted plugin skill becomes visible at the refusal, which is exactly where it should.

What it will not do

It will not author a skill. studio.author_skill_bundle exists, and an LLM-authored skill is arbitrary code, so nothing authors one: that skill emits a reviewable bundle — a manifest, proposed source and a REVIEW.md — into the project workspace. It is never registered, never imported, never executed, and its installed flag is always false. Installing it stays what it always was: a person reading it, moving the directory, and granting capabilities by hand. See Plugins and extensibility.