feat(agentkit): define generic workflow and multi-agent parity path

[sozercan]

This was generated by AI during triage.

Agent Brief

Category: enhancement
Summary: Add a generic workflow/multi-agent parity path for AgentKit-built images.

Current behavior:
AgentKit's public config loader supports only kind: Agent. The current Foundry parity work proves single-agent AgentKit images can run standalone and as Foundry hosted agents, but it does not provide an AgentKit equivalent for native Microsoft Agent Framework workflow samples. The current Foundry sample gallery includes a responses/05-workflows sample that uses WorkflowBuilder, AgentExecutor, and multiple specialized MAF agents chained into a final response. The current microsoft/agent-framework sample tree also includes responses/05_workflows.

Desired behavior:
AgentKit should have a provider-neutral position for workflow/multi-agent support. Either:

1. explicitly document that AgentKit v0 is single-agent and mark workflow samples unsupported with clear validation status, or
2. introduce a separate generic workflow design/prototype (for example a future kind: Workflow) that can map to MAF WorkflowBuilder without changing the single-agent ABI.

If a prototype is implemented, it must work both as a standalone AgentKit-built image and as a Foundry hosted agent using the existing protocol adapter pattern.

Key interfaces:

• AgentKit config discriminator — currently accepts only kind: Agent; any workflow support should be a separate kind or separate product area, not extra Foundry-specific fields on kind: Agent.
• Runtime capability catalog — should declare workflow support only for runtimes that implement it.
• Runtime adapter contract — should continue returning provider-neutral run results through the shared runtime session seam.
• Foundry protocol adapter — should remain a transport wrapper, not a workflow-specific implementation.

Investigation notes:

• Current public sample gallery commit investigated: microsoft-foundry/foundry-samples@5d9dc1eb93e134b19939c3f517ce3786c1648186.
• Current old MAF sample tree investigated: microsoft/agent-framework@daac8c15f3505502370cb429630fae4d34947132.
• The Foundry workflow sample requires a capable model and currently documents gpt-5.4 as tested.
• This should not be solved by adding foundry.workflow or similar provider-specific config to AgentKit core.

Acceptance criteria:

• The repository documents whether AgentKit v0 supports workflows or explicitly does not.
• If unsupported, validation output for native workflow samples reports unsupported or blocked by product scope, not a generic failure.
• If supported/prototyped, the workflow config is provider-neutral and does not add Foundry-specific top-level keys.
• Runtime capabilities include a workflow capability only for runtime adapters that implement it.
• A deterministic workflow scenario runs standalone as an AgentKit-built image.
• The same AgentKit-built workflow image runs as a Foundry hosted agent through /responses.
• Tests cover config validation, ABI/rendering, and runtime behavior for the chosen workflow stance.

Out of scope:

• Adding Foundry-specific workflow config to AgentKit core.
• Replacing the existing single-agent ABI.
• Supporting arbitrary DAG/workflow semantics beyond the minimal scenario needed to establish the design.