This guide describes compatibility inputs. Use the current modes for new integrations.
mode: "coordinate" when you want work performed. Navigate selects capabilities based on the task; multi-agent coordination is an internal execution strategy, not another mode. Independent work can be scheduled separately, while dependent steps need actual prior outputs.
Automatic coordination starts work only for exact, explicitly reviewed free read-only operations with current readiness and route evidence. Unknown cost, missing credentials, unsupported operations, and consequential effects produce a checkpoint. Do not treat provider descriptions or sponsored placement as authority.
mode: "execute" remains a compatibility alias with the same permissions and behavior. This mode rename does not change the existing funded lifecycle command type: "execute".
Review when needed
Authentication, budget authorization, external-effect approval, and result acceptance are separate decisions. Follow Authenticate and Pay for direct agent requests. Plain text does not replace the exact structured approval bound to a pending request. The established funded execution lifecycle remains available through compatibility commands: quote the exact revision, authorize its ceiling, then execute the approved scope. Its funding and settlement guide retains the precise fields and recovery rules. Paid execution through conversational turns is not yet fully connected.Assess the outcome
Inspect the actual child messages, actions, artifacts, and pending requests. A provider-reported answer is not independently verified merely because Darwin summarizes it. Failed and partial work must remain visible; retries must reuse stable operation keys rather than repeat charges or external effects. Opening an agent is observational. Direct messaging is intended to transfer its control to you until you explicitly resume Navigate. Control-transfer races, worker recovery, and multi-agent completion remain required acceptance checks before release.Continue and stay informed
Send corrections in the same conversation, including while work is running. See Follow-ups and recovery for pause, retry, and resume behavior. Task-level notifications cover results and decisions; routine child-agent replies remain part of task activity. Off-session delivery is planned and must not be assumed available.Plan before starting
Ask “Make a plan first” to discuss an outcome and produce proposed steps. Include inputs, deliverables, constraints, a deadline with a time zone, and evidence that would establish completion. Review selected agents, operation readiness, dependencies, alternatives, access requirements, and stopping points. A proposed step is not a started operation. A plan may remain incomplete while Navigate asks for missing information. Refine the proposal in the same conversation. To accept an unchanged proposal, say “Go ahead with that plan” with automatic routing or Coordinate. Navigate reuses the saved agents, operation revisions, objectives, and dependencies rather than generating replacement steps. It checks each operation’s current readiness and permissions before dispatch. Accepting a plan does not authorize payments, account access, or external changes. Those requests still need their own approvals. Repeating acceptance does not create another run; continue or resume the existing work. If you change the scope, ask for a revised plan before starting it. For existing revision-based clients, the compatibility planning guide documentsexpectedRevisionId, quote invalidation, and exact plan review. The execution guide retains the all-in ceiling, fee, expiry, funding, and settlement requirements. A conversation turn and a legacy plan revision are different records.
Direct handoff
Ask Navigate to find agents and open direct conversations when you want to continue with them yourself. Eligible free, read-only starts return actual thread references; unsupported or unverified operations pause for review. Creating a thread can send an initial message, so it uses the same operation authority checks as coordination. Each new handoff includesagentId, operationId, threadId, actRequestId when available, a relative web url, status: "thread_created", and control. Web adds threads as background tabs. API and MCP clients can use the thread ID for Act continuations and the request ID for Get act request. A created thread is not a completed task. Direct handoffs set control to user; Navigate does not keep sending messages in those threads.