AI Agent MCP: Asking for Another Agent Is Not Starting One

What happens when one agent asks for another?

The request becomes an inbox item, not a running process.

A coding agent has finished its task. Tests still fail, and a second set of eyes would help. The agent has a tool for that. It calls request_agent_launch, then gets this exchange:

request_agent_launch(prompt="Inspect the failing tests", goalId="goal-42")
→ uid="...", status="pending"

No second terminal opens. The reply confirms that AuricIDE accepted a request. It does not confirm a launch. In the desktop app, a new inbox item shows the goal and prompt beside a Start button. That pause is the important part.

An agent that can call a tool to start another agent has not been given power. It has been given a way to ask.

The difference is easy to miss with one agent. It becomes harder to ignore when several tasks depend on each other and one bad assumption can create another process. A successful tool call may mean only that the request is valid. Something else still decides whether work begins.

The broader pattern is described in AI agent orchestration frameworks, but the useful detail is simpler: the tool call records intent, and the inbox presents that intent for a decision.

What does AuricIDE do with the request?

AuricIDE checks the request, puts it in the inbox, and waits for the launch rule that applies to its goal.

Two things are required: a prompt that tells the new agent what to do, and the goal it works on. The caller may also pick an agent CLI and a model. It cannot name any folder.

The workspace rule is narrow by design. By default the new agent starts in the requester’s own working directory. If the caller asks for a worktree, AuricIDE creates a fresh one from that directory’s repository. Those are the only choices. The calling agent controls the assignment, but AuricIDE controls where the process may start.

Next comes the inbox decision. A person can click Start. AuricIDE can start the request without that click only when automatic starts were already granted for the goal’s mission root. A grant does not turn every future request into an automatic launch.

The first agent now holds the uid. It hands it to get_agent_run, which answers with one of seven states: pending, running, interrupted, completed, failed, killed or declined. Each one changes the next step. Pending means wait. Running means the process began. Interrupted means the IDE was closed mid-run and the session can continue after a resume. Completed and failed report an ending. Killed records a stop, and declined records a decision. The tool text tells callers to poll at a human pace because the next change may depend on a person.

Suppose the first agent needs the review before choosing a fix. It sends one request and keeps the uid. While the inbox item waits, the agent can reproduce the failure or inspect related logs. If a person starts the request, a later check reports running. When the run ends, the answer can include which agent and model ran and a short summary of its output. A declined request gives the caller a final answer too. The original task can then change course without guessing whether another process exists.

Repeated requests have their own rule. If the same goal already has an open request, another call returns that request instead of adding a second inbox item. This keeps one unanswered need from becoming a row of duplicate buttons. Before the request starts, the caller can replace it: same uid, new prompt. Once it has started, replacement is refused.

The background agents workflow depends on the same separation between a requested task and the workspace assigned by the IDE.

This gives both agents a clear contract. The caller asks once. AuricIDE exposes the pending decision. A person or an existing grant resolves it. The caller checks the same uid. No launch must be inferred from a successful request.

What does that control cost?

The cost is waiting, along with more outcomes that the calling agent must handle.

That can be annoying. A small test review may sit pending while no person is at the desk. Work will not begin while nobody is there unless automatic starts cover that goal’s mission root. Even after approval, the caller must distinguish a running agent from one that failed, was killed, or was declined.

The extra states also make skills harder to write. A skill cannot request help and then assume help arrived. It needs a branch for pending. It needs another for declined. It should decide whether useful work can continue while the request waits. If nothing else can proceed, it should report the dependency and stop. Sending the same request again does not create progress.

That friction buys a visible boundary. A mistaken prompt stays inspectable before another process starts. A decline stays different from a crash. A kill stays different from a failed task. Those distinctions give the calling agent facts instead of one vague error.

Automation still exists, but it is scoped. The person grants it for a mission, and AuricIDE applies that grant only to requests under that mission root. Unrestricted agent spawning is ruled out, and so is a caller picking its own folder.

For a tiny job, this ceremony may cost more than it saves. Starting one agent directly can be simpler. The model helps when a second process must stay visible, tied to a goal, and governed before it starts by clear rules.

What still applies in another tool?

The durable rule is to separate permission to ask from authority to act.

A launch API needs more than a success response. Its contract should say whether success means requested, approved, started, or finished. Those states are not synonyms. A caller also needs a stable identifier, a way to observe later changes, and a defined response when a person says no.

Workspace choice deserves the same care. Letting an agent supply any path makes the request broader than its stated task. Restricting a new process to the caller’s directory or a worktree narrows that authority. Another product may choose different folders, but the allowed set should be explicit and visible.

Retries are the third case. If a second call creates a second job, every timeout turns into more work. Returning the open request keeps retries harmless.

The same separation is useful when building an AI code agent workflow.

A good test is simple. After any tool call, ask what fact the response proves. pending proves that a request exists. running proves that execution began. declined proves that the request will not run. completed proves that the process reached its completed state. The names should match the evidence.

That lesson survives any protocol or interface. A request can return at once, while the application keeps approval, workspace choice, and process control elsewhere. More agents make this boundary more important, not less.

AuricIDE is the open-source desktop app where this inbox lives.