An implementation boundary, not a framework limitation
The native preview deliberately implements a governed single-squad vertical slice. Federation is missing runtime functionality, not something Microsoft Agent Framework makes impossible.
Not supported does not mean impossible. MAF can be used to build richer coordination. This library has not implemented the registry, meta-routing, state isolation, shared approval semantics, and evidence aggregation needed for actual HVE Squad federation. MCP is not a prerequisite for that work.
The project moved beyond an earlier artifact-inspection proof of concept to run real MAF agents against released HVE Squad contracts. The native implementation was scoped to make one interactive delivery cycle real and verifiable: release acquisition, roster validation, research, plan plus phase details, applicable intake/council gates, one producing owner, review, approvals, and persisted evidence.
That was a vertical-slice scope decision, not a claim of full Copilot-host parity. In particular, porting charter text does not implement its host-side coordination semantics. Documenting unimplemented behavior as a limitation is more honest than letting a coordinator improvise it and claim successful delivery.
| Implemented native boundary | Explicitly outside this preview |
|---|---|
| Interactive single-squad runs | Federation and multiple coordinated sub-squads |
| One producing-role owner per delivery turn | Multi-owner deliverable fan-out |
| Focused research, plan, and review | Autonomous/autopilot loops and Watch Mode |
| Real host questions and approval callbacks | Discovery-interview workflows and shipped remote approval transports |
| Declared native child-agent dispatch | Unbounded delegation or cross-squad routing |
| Registered, approved host functions | Bundled shell, search, deploy, test execution, or native skill scripts |
A specialist may invoke a declared child agent through a real MAF dispatch. The child is checked against the installed charter and delegation allowlist and remains bounded by the role's scope, permissions, depth, budgets, and evidence rules.
It does not get an independent squad roster, state root, approval domain, or cross-project coordination policy.
A federation needs a coordinator above multiple squads, each with a real identity, roster, root, local history, and accountable owner. It must route work between them and aggregate status without flattening partial outcomes into success.
Calling more children or creating several runtime instances does not supply those semantics.
| Missing building block | Why it matters |
|---|---|
| Federation coordinator and registry | Identify registered sub-squads, their capabilities, membership, release bindings, and valid lifecycle transitions. A list of agent names is not a squad registry. |
| Meta-routing | Route requests and dependencies to the correct squad without bypassing its local methodology, role ownership, or human gate. Define how scope is accepted, rejected, or returned. |
| Parameterized per-squad state roots | Current ProjectFiles.StateRoot is fixed to .copilot-tracking/squad. Runtime options do not expose a sub-squad root. Multiple same-project instances would collide rather than form isolated squads. |
| Two-level Scribe ownership and locks | Keep a federation-level record distinct from each squad's single-writer state. Define lock order, cancellation, consistency, restart recovery, and conflict handling across both levels. |
| Shared approval semantics | Correlate who approved which squad, plan, and exact effect. A parent approval must not silently authorize every child tool call or be replayed for a different resource. |
| Read-only cross-squad inputs | Transfer verified artifacts with provenance and explicit access boundaries, not mutable shared ownership. Define dependencies and reject changed input evidence. |
| Aggregate evidence, status, and cost | Preserve local run IDs, partial/blocked states, receipts, and output hashes. Aggregate measured consumption without double-counting; unknown prices must remain unknown. |
| Compatibility and recovery tests | Exercise conflicting writers, missing squad capabilities, denied approvals, interrupted work, changed inputs, and release mismatches before claiming federation behavior. |
These are runtime and host contracts, not a missing checkbox. Merely removing the Unsupported guard, passing a squadRoot string in a prompt, or placing a federation file in the state directory would not implement them safely.
Define registry identity, ownership boundaries, routing results, approval correlation, aggregate statuses, and release compatibility. Review them against the upstream federation methodology.
Parameterize roots, add federation-level persistence, and test lock order and recovery. Preserve current single-squad behavior and reject implicit state migration.
Add real meta-routing, read-only artifact exchange, and dependency handling. Propagate cancellation, denials, missing input, and partial evidence explicitly.
Test multiple squads under contention, restart, conflicting outputs, and incompatible releases. Document the actually supported subset and upgrade path.
No target date or release commitment is implied. Contributions should propose and test a concrete contract rather than rename child dispatch as federation.
Unsupported or blocked outcome to guide scope, rather than removing gates or substituting a generic developer.The absence of federation does not require deploying an MCP service for ordinary use. The native single-squad runtime runs inside your existing .NET host.