Goose, the open-source agent in aaif-goose/goose, is removing a way of delegating work, not the ability to do several jobs at once. A change merged on October 7 deletes its background subagent interface: the parent could start a helper, receive a task handle, and ask for its answer later. The replacement keeps helpers in the parent session's execution flow, including when several run concurrently.
For a recipe author, those are different promises. Asking three helpers to investigate separate files and then using their findings still fits. Asking a helper to work in the background while the parent moves on, then checking its task ID in a later turn, depends on the interface being removed.
The change is in Goose's development branch. It is not a claim that every installed copy has changed behavior. Its value now is as a migration signal: check whether a workflow needs concurrent work or independently managed unfinished work before upgrading to a version that contains it.
The replacement came first
The replacement landed first. Late on October 5 UTC—October 6 in Paris—an earlier change added foreground subagents to Goose's state machine, the machinery that advances an agent session through its work. That implementation creates child sessions, runs pending children together and brings their outcomes back into the parent's conversation.
The execution code puts pending children into a concurrent task set before waiting for a completion. It also records delivered and cancelled children, so the next step can distinguish remaining work from an outcome already handled. Removing the detached interface therefore does not remove all tracking or make child sessions disappear. It changes where their lifecycle is managed.
There are still two execution paths to describe accurately. In the older loop, delegation waits and returns the helper's completed result directly. In the state-machine path, the delegation tool initially returns a child-session marker; a separate foreground operation runs that child and delivers its outcome. In both paths, recipes no longer manage a detached task through a later collection tool.
The public pull request gives a narrower rationale than a verdict against background agents: the work is part of retiring Goose's older agent classes and execution loop. It also removes a hidden, disabled-by-default orchestrator extension that depended on that machinery. The sources do not establish that users rejected background work or that this design is faster or more reliable.
A review caught the wrong lesson
The distinction between parallel and detached work was easy to lose even inside the change. During review, a rewritten self-test incorrectly expected synchronous delegates to run serially. That expectation was corrected. The final test recipe asks for three delegates in a single message, each doing a short wait and writing a timestamp, and expects them to finish concurrently.
That is the useful picture: three workers can start together while the parent session waits for their findings. Parallelism describes overlap between workers. Background delegation additionally lets the parent carry on and manage their results later. Goose retains the first capability while withdrawing that second interface.
We inspected the source and upstream test definitions, including cases for delivering results, cancellation and refusing another session's children. We did not execute Goose or run the model-driven self-test. The code establishes an implementation and intended behavior, not measured speed or successful operation in a production workload.
Old instructions can outlive the interface
The concrete upgrade concern is a recipe that says to call delegate with async: true, remember the returned task ID, and later call load(source: task_id) to collect the answer, or pass peek: true or cancel: true to inspect or stop it. The merged Summon implementation removes that background contract. load remains, but for discovering and reading sources such as recipes and agent instructions.
The same implementation no longer declares an async argument and does not reject unknown fields during deserialization. Old arguments can therefore parse without preserving the behavior they requested. A successful call alone is an inadequate migration check: the author needs to inspect what comes back and how the next step obtains the result.
Goose's own examples and review instructions were updated in the patch. Recipes outside the repository may need the same attention. For work that only needs simultaneous helpers, the revised batch example is a starting point. A workflow that truly needs the parent to move on while a task remains independently addressable needs a different design; removing its polling instructions would change the job, not merely tidy the recipe.
The next useful evidence is a containing release and a task trace showing that distinction through completion and interruption. Until then, Goose offers a concrete correction to a loose promise often attached to multi-agent software: several agents working at once does not, by itself, promise work that can be left behind and collected later.