There is more than one orchestrator
A difficult project rarely needs a flat row of interchangeable agents. It needs a project-level decision maker, managers for work that already has an internal structure, and specialists who can contribute directly. Agentlas represents those jobs as three orchestration shapes instead of forcing every agent into the same hierarchy.
At the top, the host LLM acts as the temporary task-force orchestrator. It receives the brief, works from the candidates resolved for the current environment, and decides whether the project needs a packaged team, a user-composed group, direct single agents, or a mixture of all three.
This top layer is temporary and project-bound. It is not a permanent super-agent that owns every worker. Its job is to form the operating structure, delegate bounded work, and synthesize what the selected units return.
Hub, Cloud, and Local are sources—not management levels
Agentlas can resolve candidates from three places. Private Agent Cloud holds packages the signed-in owner saved. Public Hub distributes reviewed agents and teams that can be borrowed. Local inventory contains agents already installed on the current machine. These sources sit beside the organization chart; they do not sit above or below one another as managers.
Routing is also more precise than asking an LLM to browse everything on every turn. High-confidence matches can be resolved by the router's deterministic lexical and semantic scores. A host LLM can adjudicate low-confidence cases, clarify the request, and choose the operating structure after the candidates are known.
Hub and Agent Cloud return runnable packages and instructions. They do not silently host the user's model completion. The connected host runtime executes the selected copy with its own model, files, credentials, and permissions.
- Private Cloud: owned packages saved under the user's account.
- Public Hub: discoverable specialists and packaged teams.
- Local: installed agents available on the current host.
A packaged team keeps the manager it was built with
A team created as a multi-agent package already has an internal reporting structure. Its team orchestrator owns planning and synthesis for its workers, and larger teams can preserve CEO, division, and specialist layers. When the top task force borrows that team, Agentlas keeps the hierarchy instead of flattening every worker into one list.
That boundary matters. The top orchestrator delegates an outcome to the team manager. The manager can then distribute work to the roles it was designed to coordinate and return a coherent result. The parent remains responsible for the project; the team remains responsible for its own operating unit.
A user-composed group receives a middle layer
A group starts differently. The user selects several existing agents after they were built and combines them for a recurring purpose. Because those agents did not arrive with one shared manager, Agentlas creates a group-orchestrator role for planning and synthesis when the group is saved and run.
The group orchestrator is an execution layer, not a claim that Agentlas secretly rewrites the original agent packages. It gives the collection one place to assign work, guard nested depth and cycles, and produce one return to the project-level parent.
Single agents need no middle manager. The top task-force orchestrator can assign them directly when one focused contributor is the clearest fit.
Experience is attached when it matches the task
An Experience Chip is not another employee in the organization chart. It adds a method or preference to an agent the user already owns or has borrowed. Agentlas keeps Operational experience separate from Taste, matches relevant entries to the task, and applies a bounded set to the current session.
That lets a team reuse a verified procedure or a preferred working style without turning every past observation into universal memory. Experience remains tied to its source and release boundary; local observations are not presented as public proof or automatic quality improvement.
Project Foundation gives the task force coordinates
The organization chart explains who reports to whom. Project Foundation explains where the work is happening. Project Soul preserves durable project decisions. Curated memory supplies reusable context. Code Map points to modules, entry points, symbols, and references. The AI Sitemap records project surfaces, dependencies, checks, risk, and evidence rather than the public XML sitemap of a website.
Together, these artifacts provide scoped project context before execution. They help the selected agent or operating unit begin from a bounded map instead of another blind repository scan. Individual maps can remain partial, so the runtime still verifies conclusions against source, tests, and visible product evidence.
- Project Soul preserves why the project is in its current state.
- Curated memory admits durable context without replaying every transcript.
- Code Map narrows where implementation is likely to live.
- AI Sitemap exposes surfaces, dependencies, risk, and evidence state.
When the work stays blocked, the network can expand
Stormbreaker locks the scope, materializes bounded work packets, delegates them through the available execution fabric, and reports whether the final gate passed or stayed blocked. It does not turn a worker's completion message into proof, and it does not guarantee that every project will finish.
A blocked gate can become a routing signal. When Hub escalation is allowed, the task force can search for a missing security reviewer, API specialist, domain researcher, or other reviewed runtime bundle. The selected specialist joins the existing structure for the bounded job, returns evidence, and leaves the parent orchestrator to decide whether the final gate can now pass.
This is the practical value of the three levels: the project can start small, preserve the management structures that already exist, attach only relevant experience and context, and expand through the network without rebuilding the whole team around each obstacle.
