You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Developers can now define tools directly at the call site using `ToolDefinition.from(...)` with typed lambda handlers and `Param.of(...)` parameter metadata — no separate annotated class required. Async variants (`fromAsync`) and `ToolInvocation` context injection (`fromWithToolInvocation`) are also available. ([#1895](https://github.com/github/copilot-sdk/pull/1895))
13
+
14
+
```java
15
+
ToolDefinition greet =ToolDefinition.from(
16
+
"greet", "Greets a user by name",
17
+
Param.of(String.class, "name", "The user's name"),
18
+
name ->"Hello, "+ name +"!");
19
+
```
20
+
21
+
### Other changes
22
+
23
+
- bugfix: **[Java]** preserve explicit null map values in JSON-RPC params so user setting clears reach the CLI ([#1906](https://github.com/github/copilot-sdk/pull/1906))
24
+
- feature: **[Java]** add experimental `onGitHubTelemetry` callback on `CopilotClientOptions` for receiving forwarded GitHub telemetry events ([#1835](https://github.com/github/copilot-sdk/pull/1835))
Copy file name to clipboardExpand all lines: docs/features/fleet-mode.md
+29-29Lines changed: 29 additions & 29 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,18 +8,18 @@ Fleet mode is useful when the work can be decomposed before execution and each u
8
8
9
9
Good fits include:
10
10
11
-
- Multi-file refactors where each worker owns a file, package, or language SDK.
12
-
- Batch reviews where each worker checks a separate diff, module, or alert group.
13
-
- Parallel research across independent repositories, services, or feature areas.
14
-
- Documentation refreshes where each worker owns a page or topic.
15
-
- Migration tasks where each worker can validate its own slice and report back.
11
+
* Multi-file refactors where each worker owns a file, package, or language SDK.
12
+
* Batch reviews where each worker checks a separate diff, module, or alert group.
13
+
* Parallel research across independent repositories, services, or feature areas.
14
+
* Documentation refreshes where each worker owns a page or topic.
15
+
* Migration tasks where each worker can validate its own slice and report back.
16
16
17
17
Avoid fleet mode for:
18
18
19
-
- Sequential tasks where step 2 needs the concrete output from step 1.
20
-
- Tightly coupled edits where workers would contend for the same files.
21
-
- Small tasks that one synchronous sub-agent or the parent agent can finish quickly.
22
-
- Tasks that require continuous shared reasoning rather than clear ownership.
19
+
* Sequential tasks where step 2 needs the concrete output from step 1.
20
+
* Tightly coupled edits where workers would contend for the same files.
21
+
* Small tasks that one synchronous sub-agent or the parent agent can finish quickly.
22
+
* Tasks that require continuous shared reasoning rather than clear ownership.
23
23
24
24
Fleet mode works best when the parent session can create clear units of work, assign one owner per unit, and define what each worker must return.
25
25
@@ -321,29 +321,29 @@ Keep plugin-provided sub-agent types narrow and descriptive so the orchestrator
321
321
322
322
## Best practices
323
323
324
-
- Decompose the work into independent units before starting fleet mode.
325
-
- Minimize dependencies between todos; dependencies reduce parallelism.
326
-
- Give each todo a durable ID, a clear title, and a complete description.
327
-
- Make each sub-agent own exactly one todo at a time.
328
-
- Use background sub-agents for truly parallel work.
329
-
- Use synchronous sub-agent calls for serialized steps or validation gates.
330
-
- Provide each sub-agent with complete context; sub-agents are stateless across calls.
331
-
- Include file paths, commands, expected outputs, and constraints in each worker prompt.
332
-
- Do not dispatch a single background sub-agent; prefer a synchronous call or batch multiple workers in parallel.
333
-
- Avoid assigning overlapping files to different workers unless the parent agent will reconcile conflicts explicitly.
334
-
- Require every worker to report what it changed, how it validated the change, and what remains blocked.
335
-
- Have the parent agent verify the combined result after workers finish.
324
+
* Decompose the work into independent units before starting fleet mode.
325
+
* Minimize dependencies between todos; dependencies reduce parallelism.
326
+
* Give each todo a durable ID, a clear title, and a complete description.
327
+
* Make each sub-agent own exactly one todo at a time.
328
+
* Use background sub-agents for truly parallel work.
329
+
* Use synchronous sub-agent calls for serialized steps or validation gates.
330
+
* Provide each sub-agent with complete context; sub-agents are stateless across calls.
331
+
* Include file paths, commands, expected outputs, and constraints in each worker prompt.
332
+
* Do not dispatch a single background sub-agent; prefer a synchronous call or batch multiple workers in parallel.
333
+
* Avoid assigning overlapping files to different workers unless the parent agent will reconcile conflicts explicitly.
334
+
* Require every worker to report what it changed, how it validated the change, and what remains blocked.
335
+
* Have the parent agent verify the combined result after workers finish.
336
336
337
337
## Limitations and open questions
338
338
339
-
- Fleet mode is exposed through generated session RPC bindings and is marked experimental in several SDKs.
340
-
- The SQL todos pattern is the canonical coordination model in the runtime guidance, but whether it is a stable extensibility contract for SDK consumers is still an open question.
341
-
-`subagentStart` and `subagentStop` are runtime hook names; this branch exposes sub-agent lifecycle to SDK consumers through the generic session event stream, not dedicated hook callbacks.
342
-
- Plugin sub-agent registration is configured at the runtime layer through `--plugin-dir`; no SDK-level plugin registration helper was verified on this branch.
343
-
- Java native typed bindings for `session.fleet.start` were not found in the Java SDK source on this branch.
344
-
- Fleet mode does not remove the need for parent-agent review. Parallel workers can produce inconsistent assumptions that the orchestrator must reconcile.
339
+
* Fleet mode is exposed through generated session RPC bindings and is marked experimental in several SDKs.
340
+
* The SQL todos pattern is the canonical coordination model in the runtime guidance, but whether it is a stable extensibility contract for SDK consumers is still an open question.
341
+
*`subagentStart` and `subagentStop` are runtime hook names; this branch exposes sub-agent lifecycle to SDK consumers through the generic session event stream, not dedicated hook callbacks.
342
+
* Plugin sub-agent registration is configured at the runtime layer through `--plugin-dir`; no SDK-level plugin registration helper was verified on this branch.
343
+
* Java native typed bindings for `session.fleet.start` were not found in the Java SDK source on this branch.
344
+
* Fleet mode does not remove the need for parent-agent review. Parallel workers can produce inconsistent assumptions that the orchestrator must reconcile.
345
345
346
346
## See also
347
347
348
-
-[Custom agents and sub-agent orchestration](custom-agents.md)
349
-
-[Hooks](hooks.md)
348
+
*[Custom agents and sub-agent orchestration](custom-agents.md)
0 commit comments