Genet

One organism.
Many stems.

The question is not how many agents you can run. It is whether a second one is doing new work.

The idea

Most stacks treat headcount as capacity. Genet treats it as a cost. A task starts with one lead agent, the orchestrator. The lead may propose sub-agents, each with the skill its sub-task needs. Policy gates in code decide whether any of them run. Default is a single agent.

Three ways to staff the same task. A single agent uses one context. An always-split crew pays for a planner, workers and a merge on every task. Genet's lead proposes sub-tasks and policy gates decide whether a fan-out happens at all; otherwise the lead works alone.Single agentone contextTaskAnswerAlways-split crewevery task fans outTaskAnswerGenetfans out only whenthe gates approveTaskAnswerAgentreads, reasons, answers1 context holds everythingPlanneralways splitsWorkerWorkerWorkerMergeLeadproposes sub-tasksPolicy gates3 checksisolated contextsSub-agentSub-agent2+ approvedLeadmergesotherwiseLead works alone
Same task, three ways to staff it. A crew pays for a planner, workers and a merge on every task. Genet's lead proposes, and the gates decide whether a fan-out happens at all.

The team is small, and every agent can switch skills, with specialists added only when a sub-task needs one. The lead owns the roster, the goal stays fixed while the method changes, and work fans out only when a single agent would fail at it.

Agent counts have become a headline number, with products advertising hundreds of sub-agents on one task. A count says what was spent, not what was gained. Genet is built for a small, cohesive team instead: the lead knows what each member can do, members differ in what they see and may open, everyone works from the same goal, and the outcome is the lead's. Every agent is the same model, so a member is a position any agent can fill, and each one added must do work the others could not. The kernel keeps the situation they share current, checks it at fixed decision points, and can stop a run that cannot finish before it spends the rest. It also keeps a record of each position from past runs, which it can show the lead as a card for each member before it plans. The team design sets out what comes next, and the architecture page maps the code.

Who decides what

Models propose; code disposes. A model only ever returns a JSON artifact. Everything that changes the team, the tools or the budget is decided in code and written to an audit log.

Models only return JSON. Every change to the team, the tools or the budget is decided by code in the control plane and logged. There is no path from a model to the roster except through the schema check and the policy gates.MODEL PLANE · any LLM · output is untrustedCONTROL PLANE · Genet kernel · codeLead modelorchestratorSub-agent modelsone per approved sub-taskSchema checkJSON only; extra keys refusedPolicy gates3 checks, in orderRosterwritten only hereTool allowlistper skillSandboxread-only workspaceJSON artifactproposalsapprovedstarts, isolated brieftool requestsresultsno direct writeBudget meter: briefs are sized before they are sent, calls in flight count, and the run halts at the capAudit log: every gate record, tool call, verdict and halt
There is no path from a model to the roster except through the schema check and the policy gates. Tools only read, only inside the workspace the operator declared, and never a hidden file such as .env.

Shared ownership

Decisions have one owner; the outcome is the team's. When a sub-agent's reply is malformed or its call to the model fails, the run goes on: the others' results are merged, and the lead covers the failed part. After any failure, the kernel writes a blameless review from the record, never from model text, and turns each kind of failure into one fixed lesson that every agent reads on the next run.

One sub-agent's reply is malformed. Its part goes back to the lead, who merges the other results, covers the part and hands the product to the verifier. After any failure the kernel writes a blameless review, and its lessons reach every brief in the next run. Authority violations, budget halts and crashes still stop the run at once.ONE RUNLeadproposes · decidespart-asub-agentpart-bsub-agentpart-csub-agentLead mergesand covers part-bits part goes backreply malformedVerifierchecks the productAFTER ANY FAILURETeam reviewwhat failed · each part · what was doneLessonsfixed sentences, at most 10Next runevery brief reads themthe next run starts with what this one learned
A failed part is not lost, and a failure is not wasted. Authority violations, budget halts and crashes still stop the run at once.

Three gates

can someone else → should we → could we. It is admission control for sub-agents, in that order, failing closed. "Should we" needs a measurable reason: either the operator declared that the sub-tasks must stay isolated, or the material does not fit in one agent's context and splitting makes every share fit. Could-we is last on purpose: the tier must allow a split, and the budget and the worker cap must cover every sub-agent plus the merge and the verifier.

Five proposed sub-tasks pass three gates in order. Two are refused at gate one because the work is already covered, one at gate two because it names no failure and goes back to the lead. Two clear all three gates and run as parallel sub-agents; a fan-out needs at least two.Lead proposes5 sub-tasksnote-anote-bnote-cnames no failure: back to the leadsummarysummary.md already existsverifyverification is the verifier's job1 · Can someone else?covered · staffed · repeat · verifier2 · Should we?named failure · measured need3 · Could we?tier · budget · cap · skill2 legalparallel sub-agentsa fan-out needs two or more
Every proposal gets a gate record. Refused work is either already covered or goes back to the lead; a fan-out needs at least two approvals.

Terms

LeadOrchestrator. The only agent that proposes changes to the team.
Sub-agentA worker with an isolated context. It never sees the other sub-agents' work.
GatesAdmission control: already covered, a named failure, and tier, budget, cap and skill.
SkillA role brief and tool profile. Tools are read-only and allowlisted.
Budget tierTight: a single agent. Normal: may replan. Open: may fan out.
Run logTrace and audit log. Every gate record, tool call, verdict and halt.
Team reviewThe kernel's blameless review of a run that had a failure, built from the record.
LessonsOne fixed sentence per kind of failure, carried in every later brief.

Proving it

taskorg compare runs the same tasks three ways: one agent, an always-split crew, and Genet. The model, tools and budget are the same for all three. The claim is that Genet matches the better baseline's accuracy at close to single-agent cost. A perfect simulated reader shows the mechanism. With a roomy context, Genet stays a single agent at 1.20× its cost. With a tight one, a single agent fails where the material overflows, and Genet fans out on exactly those tasks, at 0.94× the cost of a crew. Live runs on Claude Haiku 5.5 found one agent enough at every size tried, up to 20 companies a question: a single agent got every answer, and an always-split crew lost answers as the work grew. Genet stayed one agent, at 1.2 to 1.6 times its cost. At an 8,000-token cap, where one agent cannot fit the larger questions, no lead split a question that fit, and Genet verified 13 of the 18 that did not, where a single agent verified none. A crew given the same size notes also verified 13 of those, at more tokens, and lost 3 of the 12 that fit, which Genet kept single. The evidence so far supports Genet's governance and cost, and does not show accuracy gained by splitting where one agent fits.

python -m taskorg.cli compare --dry-run          # plan and call ceiling
python -m taskorg.cli compare --adapter sim      # structural cost at $0
python -m taskorg.cli compare --adapter live     # a real model

Untrusted by default

Genet treats three things as untrusted: what the model endpoint sends back, what a model asks for, and what is in the workspace. The API key goes only to the host you named, over HTTPS (plain HTTP only to this machine), and redirects are refused. A reply is capped at 8 MB, and one deadline covers the whole exchange. A call is sized before it is sent, with room for its reply, the endpoint is asked to stop the reply at the call's cap, a malformed reply gets one retry, one reply runs at most 8 tools, and a saved run is checked before it loads. To report a vulnerability, use Report a vulnerability on the repository's Security tab.

Status

Version 0.9.2, a kernel rather than a platform. About 1,720 tests run with no network and no key, 400 of them against a hostile stand-in model that tries to make calls loop or slip past the token count. A mutation check deliberately breaks 297 rules, one at a time, and a test catches every one. The comparison has run with the simulated reader, against stand-in endpoints, and on Claude. The live runs found 23 problems the simulation could not show. Twenty are fixed. The verifier, which could not open a source, now gets the riskiest ones by default, and on Claude it caught every planted error whose file it was shown; their record and tapes are in the live test log.

Try it

Python 3.11 or later. No runtime dependencies.

git clone https://github.com/jrodriguez4505/Genet.git
cd Genet
pip install -e ".[dev]"
pytest -q
python -m taskorg.cli run --context "One paragraph holds everything needed."

Apache-2.0. Kernel, not a cloud. Not the playwright. Code: github.com/jrodriguez4505/Genet. Partnerships: open an issue.