Splitting work among specialists can help with large tasks. It also creates new ways to fail: agents that spawn agents without limit, workers that approve their own output, confident reports that nobody checked, and a chorus of voices talking over each other. JARVIS’s agent design treats each of these as a defect to prevent, not a risk to accept.
Many specialists, one voice
Behind the scenes a task may involve many specialist roles. The owner still hears one JARVIS voice. A voice guard stops specialist phrasing and internal chatter from leaking into what is spoken. The owner gets one coherent answer with its evidence, rather than a transcript of an internal debate.
Bounded decomposition
The production SpecialistPool limits how far work can be split. Decomposition can go at most four levels deep, and each level can fan out to at most eight workers. A stall detector catches agents that are stuck or looping.
Why fixed limits? Unbounded recursion is the usual way agent systems run away with time, money and GPU memory. On a single 12 GB card shared with speech, the voice and the HUD, a runaway fan-out is not just wasteful. It can starve the parts of the system the owner is actively using.
The design council and the red team
Two review structures exist in production code:
- A 12-role design council, including a deliberately hostile sceptic. It preserves dissent instead of averaging it away. A minority objection stays on the record even when the majority disagrees.
- A red team that attacks along ten vectors. It attacks every repair again, because a fix can open a new hole. It fails the gate while any high or critical attack remains open.
Their runtime status is uncertain. A generated project map shows the council and red team imported only by tests and tools, not by the running system. This site therefore describes them as implemented modules, not as services that review every task.
Nobody accepts their own work
A specialist cannot accept its own output. The project’s reasoning is compact: “self-verification is the same error twice.” Whatever blind spot produced a mistake will usually also miss it on review. Acceptance has to come from an independent verifier, such as the red team or a separate checker, and any real-world effect still has to pass the governance chain.
Specialist contracts (Advanced branch)
The Advanced Systems branch, which is not merged into production, formalises specialist work:
- Contracts for 11 roles, each with typed
Assignment,ClaimandWorkerReportrecords. - A bounded local specialist worker with no autonomous model dispatcher. It does not dispatch model calls on its own initiative.
- Checkpoints in the mission store, so specialist progress survives like any other mission state.
- A blackboard where reports are kept as CONFLICTING or UNVERIFIED instead of being merged into a false consensus. Freshness rules mark old reports STALE.
Work on shared resource reservations between specialists is on hold because of findings about how leases recover. Live proofs of this branch used fixture tasks and fixture reports, not real owner work.
Roles do not grant authority
This site summarises a set of rules as “roles do not grant authority”. That exact phrase does not appear in the project. It is an accurate paraphrase of rules that do:
- A role’s “scope is a ceiling, never execution authority”. The role limits what a specialist may attempt. It never permits anything.
- “The role is a scope label, never a claim that a specialist model supplied reasoning”. Giving a worker a role name does not mean a specialised model did the reasoning.
- Related rules elsewhere follow the same pattern. Skill confidence grants no authority, simulation grants no authority, and capability discovery has no execution or grant method.
A specialist asking to do something is exactly as powerful as the model asking: it can propose, and the runtime decides.
Reports are claims, not evidence
A worker’s report is recorded as an assertion. Even when it is backed by the worker’s citations, “A supported claim is still a worker assertion, not verified evidence”. It becomes evidence only when something independent observes the world and agrees. This mirrors the rule for tools: a dispatched action is not a verified one, and a reported result is not a verified one either. See research for how evidence is graded.
What is not proven yet
- Specialist decomposition is tested, not live-proven in the registry.
- Council and red-team wiring is uncertain. They may run only in tests and tooling.
- Specialist contracts, the local worker and the blackboard are on the Advanced branch only, not merged into production, and their proofs used fixture tasks.
- Shared resource reservations are on hold.
- No measurement is published here of how much specialist decomposition improves outcomes over a single pass.