Delegating Work

The three ways a Cosmos Expert can hand off work — workers, subagents, and Expert-to-Expert interactions through integrations.

Delegating Work

Cosmos gives you three ways for one Expert to hand work off to another agent, letting a manager session keep coordinating the workflow while a specialized agent takes on a focused sub-task:

• Workers — a manager Expert launches another Expert as a separate session with its own VM, Environment, integrations, and permissions.
• Subagents — a session spins up a lightweight helper agent that shares the broader coding workflow but carries no Cosmos Expert configuration.
• Expert-to-Expert interactions — two Experts coordinate indirectly through an integration they both work in, such as a pull request, rather than a direct launch.

Reach for delegation when a workflow needs parallel or specialized execution — for example, Project Builder launching implementation workers, or PR Author responding to comments a reviewer Expert posts on its pull request.

Why delegate work?

The main reason to delegate is focus. In theory, one very broad Expert could try to do every task in a workflow. In practice, specialized Experts produce better results because the system prompt sets what the agent pays attention to.

For example, PR Author is focused on building: implementing the requested change, opening the pull request or merge request, fixing CI failures, resolving merge conflicts, and driving the change toward merge. Deep Reviewer has a different focus — its prompt is tuned to be critical and catch bugs, asking whether an interface can be an attack vector, which inputs will crash the code, and what corner cases the implementation missed. Those are not the questions PR Author reasons about as thoroughly, because it is optimized for a different job.

The three options at a glance

	Worker	Subagent	Expert-to-Expert
What it is	A separate Expert, launched as its own session	A lightweight helper agent inside the same workflow	Two Experts coordinating through a shared integration
Configuration surface	Full Cosmos Expert: own Environment, integrations, permissions	Own prompt, context, and model — but no Expert config	Each is a full Expert; they never launch each other
Scope	Organization or Space	Repo	Wherever the shared integration reaches
Coordination surface	Manager ↔ worker messages	Manager ↔ subagent, in-session	The integration itself (e.g. PR comments)
Weight	Heavyweight	Lightweight	Loosely coupled, event-driven
Best when	A sub-task needs its own Environment or side effects	Focused research, validation, or review in one codebase	Agents can hand off through events humans can inspect

All three share some traits: each delegated agent has its own context window, its own system prompt, can define its own model, and runs in parallel with the manager, reporting progress back.

Workers

A worker is an Expert. Because of that, a worker is more heavyweight: it runs as a separate Cosmos session with its own VM and Environment, can define its own integrations, and can take side-effecting actions — posting comments, creating tickets, writing to external systems — depending on its permissions. Workers are scoped to either the whole organization or the Space they belong to.

Unlike subagents, a session should be explicitly prompted about when to launch a worker, because a worker is a separate session with its own runtime environment and external permissions — Cosmos does not launch one implicitly.

Use a worker when:

• The parent Expert should coordinate the workflow but not do every task itself.
• A sub-task needs its own Environment, integrations, or external side effects.
• Multiple independent tasks can run in parallel as separate Cosmos sessions.
• You want a clear parent session that tracks delegated work.

Configuring workers. An Expert can be given a fixed list of worker Experts or allowed to discover available Experts at runtime. Keep worker permissions narrow — the parent should only be able to launch workers that make sense for its workflow. See Automations for how worker sessions appear alongside trigger-created sessions.

Subagents

A subagent is just an agent — the standard delegation concept used by many coding tools: a focused agent that helps with research, validation, implementation, or review inside the same broader coding workflow. It has its own prompt and context, but it does not carry a Cosmos Expert’s configuration surface (no separate Environment, integrations, or permissions), and it is scoped to a repo.

Sessions are generally prompted to use subagents as they see fit, rather than needing explicit per-launch instructions. See Subagents in the Auggie documentation for how they are configured and used.

Expert-to-Expert interactions

Experts do not always need a direct worker relationship to interact — they can communicate through the systems they already work in. Here, the integration itself becomes the shared coordination surface.

For example, PR Author creates a pull request. Deep Reviewer is triggered by the pull-request-created event, analyzes the change, and posts review comments. PR Author subscribes to events on that pull request, including newly posted comments, and responds to the review feedback. For a pull request created without PR Author, a human can start PR Fixer with the URL or comment cosmos fix. No Expert launches another; the pull request is the medium.

This pattern is often conceptually simpler than workers, and it keeps humans in the loop: because the coordination happens in an integration, people can inspect the interaction between agents — for example, by reading the pull request comments — and intervene whenever they want.

Choosing between them

For Cosmos, prefer Experts over subagents when delegation is needed — whether as workers or through Expert-to-Expert interactions. An Expert is more natively supported in Cosmos: each one is a real session you can open in the browser, inspect in depth, and reason about independently.

That said, delegate carefully. Worker orchestration can get complicated for the same reasons multi-threading is: coordination, complex interleavings, data races, deadlocks, and unclear ownership. Prefer a single Expert when the whole workflow fits in one context window. If delegation is necessary, prefer one or two workers with clean handoff boundaries — or an Expert-to-Expert interaction where the integration is the coordination surface.