| 1 | <!-- English translation of adr/0087-microsoft-agent-framework-builtin-agent-orchestration.md. Canonical Russian: ../../adr/0087-microsoft-agent-framework-builtin-agent-orchestration.md --> |
| 2 | |
| 3 | # ADR 0087: Microsoft Agent Framework (MAF) - a guide to the **embedded** agent framework orchestration layer |
| 4 | |
| 5 | **Status:** Accepted · **Next step: PoC** |
| 6 | **Date:** 2026-04-22 |
| 7 | |
| 8 | ## Related ADRs |
| 9 | |
| 10 | | ADR | Role | |
| 11 | |-----|------| |
| 12 | | [0038](0038-agent-facade-ai-provider-and-tool-orchestration.md) | LLM façade, standalone JSON loop, `McpClientService` | |
| 13 | | [0083](0083-ai-mode-and-nested-settings-toml.md) | `ai.mode`, incl. `mcp_only` | |
| 14 | | [0008](0008-mcp-contracts-and-testable-infrastructure.md) | MCP contracts | |
| 15 | | [0048](0048-cursor-acp-chat-ide-parity-and-mcp-tool-surface.md) | ACP, MCP tools in session | |
| 16 | | [0082](0082-acp-ide-mcp-loopback-single-process.md) | MCP loopback in one process | |
| 17 | **Summary:** the **Agent-first** reference point in the product is transferred to the stack: **MAF** - the target layer for future orchestration of the built-in agent; **next step** - **PoC** (separate branch/project), without obligation to immediately merge into the main application. |
| 18 | |
| 19 | --- |
| 20 | |
| 21 | <a id="adr0087-context"></a> |
| 22 | |
| 23 | ### Implementation snapshot |
| 24 | |
| 25 | | Element | Meaning | |
| 26 | |---------|----------| |
| 27 | | — | integration into `main` and update [0038](0038-agent-facade-ai-provider-and-tool-orchestration.md) - based on the results of the PoC | |
| 28 | |
| 29 | ## Summary |
| 30 | |
| 31 | - **Microsoft Agent Framework** - Embedded agent orchestration guide. |
| 32 | - The next step is PoC; communication with [0104](0104-cognitive-decomposition-loop-for-maf-prompt-orchestration.md). |
| 33 | |
| 34 | --- |
| 35 | ## Context |
| 36 | |
| 37 | 1. **Built-in** “agent track” (full-fledged framework: stable tool-calling, tests, step policy) **essentially not deployed**: there is a backlog in the code (`AutonomousAgentService`, minimal contract `IAiChatProvider`, external MCPs as a client), but **no** mature verification of scripts in the product. |
| 38 | 2. [0038](0038-agent-facade-ai-provider-and-tool-orchestration.md) in the “Direction” section already mentions the idea of a **single orchestrator** instead of the fragile “JSON in free text”. |
| 39 | 3. [Microsoft Agent Framework](https://github.com/microsoft/agent-framework) (MAF) - **open** (MIT) multi-language stack with **first-class .NET support**; The repository contains samples for Azure OpenAI, OpenAI, Foundry, **Ollama**, etc. |
| 40 | |
| 41 | User question: **does it make sense to specifically consider MAF** when starting work on agent-based piping, and **does this affect MCP modes**. |
| 42 | |
| 43 | --- |
| 44 | |
| 45 | <a id="adr0087-pros-cons"></a> |
| 46 | |
| 47 | ## Pros / Cons (pre-decision analysis) |
| 48 | |
| 49 | <a id="adr0087-pros"></a> |
| 50 | |
| 51 | ### Pros (for relying on MAF for future inline loop) |
| 52 | |
| 53 | | Plus | Explanation | |
| 54 | |------|-----------| |
| 55 | | **Less reinventing the wheel** | Ready-made agent abstractions, providers, samples for .NET; less native code for “loop: model → tool → observation”. | |
| 56 | | **Evolution instead of JSON-hack** | Reduces the priority of [0038 “Direction” p.2](0038-agent-facade-ai-provider-and-tool-orchestration.md#adr0038-p2) (extract JSON from the text) - provided that the selected provider/client in MAF closes the necessary calls. | |
| 57 | | **Multi-provider** | One stack for Azure / OpenAI-compatible / Ollama, etc.; easier to align with **cloud/local** in [0083](0083-ai-mode-and-nested-settings-toml.md). | |
| 58 | | **Documentation and Ecosystem** | Microsoft Learn, samples, predictable direction for .NET. | |
| 59 | | **Coincidence with the “early” stage** | While there is **no** volume of your own orchestrator poured into prod, **the cost of changing the approach is lower** than after years of investment in a custom engine. | |
| 60 | |
| 61 | <a id="adr0087-cons"></a> |
| 62 | |
| 63 | ### Cons (risks and costs) |
| 64 | |
| 65 | | Minus | Explanation | |
| 66 | |------|-----------| |
| 67 | | **Integration volume** | MAF is not a plugin for the “Submit” button: you need adapters for chat, offline mode, limits, routes, L1–L3; regression **local/cloud/ollama**. | |
| 68 | | **Moving Target** | Relatively young stack; **breaking** updates are possible - you need version pinning and a migration plan. | |
| 69 | | **Doesn't address "IDE specifics"** | The binding to `IIdeMcpActions`, the `IdeCommands` directory, and UI policies remains **ours**; MAF is a **model ↔ generic tools** layer, not a cockpit replacement. | |
| 70 | | **Duplicate with SK (if available)** | If we later bring in the Semantic Kernel, we need a **clear boundary** (both in SK and in MAF), otherwise there are two “centers of gravity”. | |
| 71 | | **Microsoft stack dependency** | Legally, MIT and the repo are open; **product** - binding to priorities and MS abstractions. | |
| 72 | |
| 73 | ### Benefit Summary |
| 74 | - **It is beneficial to consider MAF** if the goal is to **focus** the team on CIDE specifics (IDE commands, routes, UX), and **not** write a stable multi-provider agent-loop from scratch. |
| 75 | - **Less beneficial** as an "emergency replacement" if the next release is **mcp_only** / ACP without a built-in agent: MAF integration **doesn't** unlock the user in these modes any more than they already are (see below). |
| 76 | |
| 77 | --- |
| 78 | |
| 79 | <a id="adr0087-decision"></a> |
| 80 | |
| 81 | ## Solution |
| 82 | |
| 83 | 1. **Accepted:** **MAF** - target stack for implementing the “single orchestration layer” item from [0038 “Direction” p.1](0038-agent-facade-ai-provider-and-tool-orchestration.md) for the **built-in** agent circuit; the "from scratch/Semantic Kernel only" alternative for this role is **not** prioritized until the PoC shows otherwise. |
| 84 | 2. **Currently in production:** **PoC** in a separate branch or separate `samples`/console project within the repo (minimum: one provider, such as Ollama or OpenAI-compatible; one stub tool; `RunAsync` call / equivalent) - **without** the obligation to immediately merge into the main `CascadeIDE` UI. |
| 85 | 3. **Criteria for transition to integration in `main`:** completed PoC + **list of adapters** to [0038](0038-agent-facade-ai-provider-and-tool-orchestration.md) (chat, autonomous, policy L1–L3) + **assessment** of lock-in risks; then **patch** [0038](0038-agent-facade-ai-provider-and-tool-orchestration.md) in the spirit of “Solution” with a link: what remains in `AiProviderManager`, what is in MAF; if necessary, a separate ADR for UI migration. |
| 86 | |
| 87 | <a id="adr0087-tfm-packages"></a> |
| 88 | |
| 89 | ### TF Compatibility: CIDE and MAF packages |
| 90 | |
| 91 | - **CIDE:** main TFM - **`net10.0`** (`CascadeIDE.csproj`, `CascadeIDE.Tests`, etc.); We **don’t do downgrades for the sake of MAF**. |
| 92 | - **NuGet (checked against package metadata):** [Microsoft.Agents.AI](https://www.nuget.org/packages/Microsoft.Agents.AI/) in the release line (e.g. **1.2.0**) explicitly includes target monikers **net10.0**, **net9.0**, **net8.0** (as well as .NET Standard 2.0 and .NET Framework 4.7.2 for other scenarios). Therefore, **`net10.0` CIDE is covered** by the core MAF library; no separate “cutting” at 8/9 is required. |
| 93 | - **MAF repository:** examples in `dotnet/samples` build and run scenes with `--framework net10.0`, sample prerequisites (eg Ollama) indicate **.NET 10 SDK or later** - in one vector with CIDE selection. |
| 94 | - **Transitive packages** (`Microsoft.Agents.AI.OpenAI`, Foundry, etc.): during PoC and major updates, check the **Frameworks / Dependencies** tab on NuGet **for the same version** that you pin: conflicts with `net10.0` are not expected in the kernel, but a separate provider could theoretically lag behind (rarely) - then **point** check `dotnet restore` / `dotnet build`. |
| 95 | |
| 96 | <a id="adr0087-legacy-autonomous-path"></a> |
| 97 | |
| 98 | ### Parallel "old" autonomous path (feature flag) |
| 99 | |
| 100 | **Solution:** separate flag / long dual-path for the current implementation of `AutonomousAgentService` (JSON from text) **do not** put in. **Why:** the built-in agent track **does not** have an external legacy set of users and **is not** brought to a mature contract; The “old” way is a design backlog, not a commitment to compatibility. When implementing MAF (or another orchestrator), it is enough to **replace the implementation** in a branch with regression based on scenarios and tests, without the required parallel option. |
| 101 | |
| 102 | **We do not do the following until the agreed upon result of the PoC:** migrating the product code in the main application, changing dependencies in the root `CascadeIDE.csproj` without separate approval, changing the public MCP API. |
| 103 | |
| 104 | --- |
| 105 | |
| 106 | <a id="adr0087-mcp-compatibility"></a> |
| 107 | |
| 108 | ## Impact on MCP (why `mcp_only` and "IDE as server" don't break) |
| 109 | | Topic | Meaning | |
| 110 | |-----------|--------| |
| 111 | | **MCP protocol, `ide_*` registry, external stdio servers** | Remains **infrastructure** IDE and contract for clients; MAF **does not** replace MCP and **does not** supersede [0008](0008-mcp-contracts-and-testable-infrastructure.md). | |
| 112 | | **`ai.mode = mcp_only`** ([0083](0083-ai-mode-and-nested-settings-toml.md)) | Built-in LLM **not called** for assistant text; the response comes from the **external** MCP circuit. It is **orthogonal** to MAF: MAF touches the **inner** “model in IDE process” loop. The `mcp_only` mode **doesn't** require MAF and **doesn't** get "worse" by not having MAF. | |
| 113 | | **ACP/Cursor-agent** | External agent by [0016](0016-agent-client-protocol-external-agent.md) **not** about MAF; mixing MCP into the ACP session - as in [0048](0048-cursor-acp-chat-ide-parity-and-mcp-tool-surface.md). | |
| 114 | | **Standalone + `McpClientService`** | Today: model (via facade) + JSON + calling tools. **Future** connection with MAF: the logic of “who and how calls `CallToolAsync` / IDE commands” can **move** to the MAF orchestrator, but the **protocol** for calling external MCPs **remains** the same infrastructure layer. | |
| 115 | |
| 116 | **In short:** switching **inline** script to MAF **doesn't** change the semantics of **MCP-only** and **doesn't** remove MCP from the IDE; the (hypothetically) implementation of the agent's **built-in** loop changes when it **comes** into development. |
| 117 | |
| 118 | --- |
| 119 | |
| 120 | <a id="adr0087-consequences"></a> |
| 121 | |
| 122 | ## Consequences (direction taken) |
| 123 | |
| 124 | - In the TECH documentation for the orchestration of the built-in agent, there is a **named** reference (**MAF**) instead of an undefined “custom orchestrator”. |
| 125 | - After PoC: dependencies `Microsoft.Agents.*` (and transitively - providers), update policy, CI for compatibility. |
| 126 | - [0038](0038-agent-facade-ai-provider-and-tool-orchestration.md) - **patch** based on the results of the PoC: the “Decision / Direction” section with a link that remains `AiProviderManager`, which goes to MAF. |
| 127 | |
| 128 | --- |
| 129 | |
| 130 | <a id="adr0087-open-questions"></a> |
| 131 | |
| 132 | ## Open questions (clarify before/during PoC) |
| 133 | |
| 134 | 1. One **PoC provider** (Ollama vs cloud) and “success” criterion for tool-calling. |
| 135 | 2. Contact [Semantic Kernel](https://github.com/microsoft/semantic-kernel) if scripts appear in the repo that overlap in area of responsibility (avoid duplication of orchestration). |
| 136 | |
| 137 | --- |
| 138 | |
| 139 | **Verified:** 2026-04-22 (status [0038](0038-agent-facade-ai-provider-and-tool-orchestration.md), [0083](0083-ai-mode-and-nested-settings-toml.md); MAF public repository, MIT license in repo root; **compatibility TF:** [Microsoft.Agents.AI 1.2.0 on NuGet](https://www.nuget.org/packages/Microsoft.Agents.AI/1.2.0#supportedframeworks-body-tab) - **net10.0** in the list of included TFMs). **History:** 2026-04-22 - direction **accepted**, fixed **next step: PoC**. |