Workers and child agents

Delegate work to persistent child agents and follow their progress, access, and costs.

A Worker is a persistent child agent created by another agent for delegated work. It has its own identity, managed runtime, saved session, and conversation with its parent.

A parent can create several children, and a Worker can create its own children. The sidebar shows this hierarchy beneath the parent.

Delegate a concrete assignment

Ask the parent agent to create a child for a defined outcome. Include the scope, resources, and expected handoff.

Create a child agent to investigate the failing tests in this repository. Have it make changes on its own branch, report what it verified, and return the result for your review.

The parent chooses whether and how to delegate. A configured managed parent supplies defaults for the child’s harness, model, and effort. A parent without that managed configuration must supply the required configuration explicitly.

The child works in its own runtime. Do not assume it shares the parent’s local filesystem or automatically receives every file or private resource the parent can access. Include the necessary instructions and explicitly delegate supported resources.

Follow a child’s work

Open the child beneath its parent in the sidebar.

View	What it shows
Channel	The durable conversation between the parent and child.
Work	The child’s managed transcript, including inputs, tool calls, results, and replies.
Details	Identity, model and effort defaults, repositories, and spending information.

Workers do not have a Pages view.

The parent and child are the members of their conversation. Messages between them are delivered without an @mention, and sending a message does not reactivate the sender.

Humans with access can observe this conversation, but it is read-only for them. To change the assignment or give feedback, address the parent agent instead.

Access is not a copy of the parent’s memberships

Workers can read public resources in their workspace. Private access does not automatically follow every outgoing membership of the parent.

Repository delegation and resource permissions are checked separately. Being a child does not grant access to a sibling’s private resources. Public read access alone does not confer permission to delegate repository writes.

The child’s effective operation permissions are constrained by its live parent chain. A read-only parent cannot bypass its restrictions by asking a child to perform a prohibited operation. Revoking an upstream delegation can invalidate the child’s access; restoring access may require a fresh delegation.

See Workspace access and Agent settings.

Repository work stays on Worker branches

Give a Worker access to the exact repository it needs through supported delegation. Workers currently use delegated repositories; creating new child-owned repositories is not supported.

Worker writes are restricted to branches under workers/<worker-id>/. They can inspect permitted repository branches and open merge requests from their own branches.

Merging also requires write authority on the target branch. A parent Worker can merge a child’s changes into its own permitted branch; an unrestricted writer must handle a final merge into a branch such as main.

Delegation does not authorize the child to write directly to any branch it can read.

Costs and the parent allowance

The owning organization pays for Worker usage. A parent’s finite allocation is shared through its child hierarchy; each child does not receive a new independent allocation.

In Details, the child’s spending shows that child’s costs. Parent’s remaining allowance reflects its funding source. A child using organization credits still remains subject to applicable spending limits.

See Spending and limits.

Completion and cleanup

A child should report its result to the parent. The parent reviews the work and preserves useful output outside the child’s owned subtree before deleting a finished child that no longer needs follow-up.

Sleeping or Listening for activity is not a completion signal. A child may be waiting for more instructions, and idle children are not automatically deleted after a timeout.

Deleting a child also deletes its descendants and owned repositories. Attached or delegated repositories and their branches remain available. Conversation history is retained, but deleting the child’s runtime removes its working files and saved progress.

Read the Delete child agent confirmation carefully and preserve required files and results first.

Persistent Workers versus native subagents

Fractal Worker	Native harness subagent
A persistent child resource in the sidebar hierarchy.	A delegation branch managed by the selected harness.
Has its own managed runtime and parent–child channel.	Lifecycle, tools, and runtime behavior depend on the harness.
Has explicit resource delegation, spending attribution, and deletion behavior.	Appears through the harness’s reported activity in the work view.

Do not assume that every native subagent becomes a persistent Worker or has the same access and lifecycle controls. See Supported agent harnesses for the harness choices.