Skip to content

feat(workflow-copilot): add copilot sdk task#2402

Open
DLehenbauer wants to merge 10 commits into
microsoft:mainfrom
DLehenbauer:workfloweng
Open

feat(workflow-copilot): add copilot sdk task#2402
DLehenbauer wants to merge 10 commits into
microsoft:mainfrom
DLehenbauer:workfloweng

Conversation

@DLehenbauer
Copy link
Copy Markdown

Adds copilot.invoke(..) as a new workflow engine task that invokes the Copilot agent via the Copilot SDK.

…low engine

Introduces a new `copilot.invoke` builtin task that drives schema-guided Copilot agent turns via a new `CopilotClientHost` abstraction backed by `@github/copilot-sdk` 0.3.0.

TaskContext is extended with an `outputSchema` field so tasks can use structured output contracts to shape their computation.
Comment thread ts/docs/design/workflowSystem/ir/decisions/0011-task-context-schema-awareness.md Outdated
Comment thread ts/examples/workflow/cli/src/cli.ts
Comment thread ts/examples/workflow/engine/src/builtinTasks.ts
Comment thread ts/examples/workflow/engine/src/builtinTasks.ts
* Authoritative for this call: equal to or a narrowing of the
* registered task's inputSchema (decision 0003 Option 1').
*/
inputSchema: JSONSchema;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see that being added in the code. Also, you already got the input, do you actually need the inputSchema?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right -- I added it, didn't use it, and the removal was incomplete. Should be fixed now.

Update decision 0011 to reflect that only outputSchema was added to TaskContext; inputSchema was removed because no consumer needed it. Addresses PR microsoft#2402 review feedback.
Declare concrete builtin tasks with ConcreteTaskDefinition<...> and generic builtin tasks with GenericTaskDefinition<...> instead of the looser TaskDefinition<...> union. Annotations now match what each task actually is (concrete or generic), per the schemas in builtinTaskSchemas.ts. Removes the need for downstream consumers (e.g. tests) to type-assert when reading .inputSchema/.outputSchema.
…concrete

Add per-task one-line comments in builtinTasks.ts and builtinTaskSchemas.ts explaining why these are NOT generic over N like their arithmetic siblings (divide: int/int can yield non-int; floor/round/ceil: output is always integer regardless of input).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Revert 88e231e. The TaskDefinition<...> union (concrete | generic) is
sufficient for builtin task declarations. Only one downstream consumer
(copilotInvoke.spec.ts) needed to read .inputSchema directly, so add a
narrow ConcreteTaskDefinition cast there instead of widening the public
declaration types of every builtin.

Keeps the explanatory comments added in cacd4bc about which builtins
are intentionally concrete despite their arithmetic siblings being
generic (math.divide, math.floor/round/ceil).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Restore the pre-existing 3-line explanation above math.divide in
builtinTaskSchemas.ts that was inadvertently truncated in cacd4bc.
The newly added per-task comments on math.floor/round/ceil and on
mathDivide in builtinTasks.ts are kept as-is.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants