Process framework vs Agents framework?

[hansmbakker]

I see the two orchestration frameworks in Semantic Kernels

• Agent
• Process

For me, it's unclear when to apply what framework when.

I found #12012 (comment) and it emphasizes using the Process framework when predictability is needed, but it is not clear to me when to use the Agent framework then.

I do see What problems do AI agents solve? and When to use an AI agent? but some of the points there also apply to the Process framework. For example, Process orchestration is mentioned in "What problems do AI agents solve?" even though it is also a feature of the Process framework.

A kind of table with a features comparison or some usecase examples would help.

[runceel]

Here is a new challenger!!
Semantic Kernel: Multi-agent Orchestration

[moonbox3]

What do you mean by "new challenger"? With the introduction of new multi-agent orchestration patterns, our goal is to provide more out-of-the-box options for interacting with agents. This includes sequential, concurrent, group chat (with human-in-the-loop), magentic, and other orchestration methods. While these patterns do not cover every possible scenario, they offer foundational building blocks that developers can extend to address more complex requirements.

[runceel]

Thanks for the clarification — and apologies if my “new challenger!!” comment came off the wrong way. It was just a playful reference to fighting game intros, meant to celebrate the arrival of the new multi-agent orchestration patterns.

I was especially excited because with the introduction of Multi-agent Orchestration(I like it!), which seems to share similar goals with the Process Framework, and existing features like AgentGroupChat and the ability to plug Agent into Plugin, it felt like a new character had entered the arena. That was the spirit behind my comment.

That said, I did get the impression that AgentGroupChat might be fully replaced by this new orchestration approach. Since AgentGroupChat is still in Preview, I understand that changes like this are expected. But when introducing new features that overlap with existing ones, it would be really helpful to include a clear note about how those existing features are expected to evolve — whether they’ll be deprecated, merged, or continue to coexist.

Also, one piece of feedback on the Process Framework: since it relies heavily on string-based APIs — for example, specifying event names or the next step’s function name as strings — I think it would be even more developer-friendly if workflows could be constructed with stronger typing support. That might help reduce runtime errors and improve the overall developer experience.

Thanks again for the thoughtful explanation and for all the work going into making these orchestration patterns more powerful and flexible!

[runceel]

And by the way — the explanation you shared in #12012 really helped clarify the distinction between when to use the Agent vs. Process framework. Thank you for that!

[moonbox3]

@hansmbakker, I provided further context on using one versus the other in #12012. That answer doesn't help?

[jovanSAPFIONEER]

@hansmbakker This is a real pain point — the overlap between Process framework (deterministic workflows) and Agent framework (autonomous orchestration) makes it hard to know which to reach for.

From what I've seen building multi-agent systems, the practical distinction comes down to:

	Process Framework	Agent Framework
Control flow	You define it (steps, events, transitions)	Agents negotiate it (orchestration patterns)
Predictability	High — deterministic paths	Variable — LLM-driven decisions
State	Managed by process steps	Spread across conversation history
Best for	Approval workflows, pipelines, ETL	Research, analysis, open-ended tasks

The gap I kept hitting — which @runceel also touched on — is what happens when you need both: structured coordination with agent autonomy. Agents that can make independent decisions but share state deterministically without it fragmenting across message history.

That's what I ended up building with network-ai — it has a Semantic Kernel adapter so it works alongside your existing SK setup. The core idea:

• Agents operate autonomously (like the Agent framework)
• Shared state is deterministic (like the Process framework) — via an atomic propose → validate → commit blackboard
• Conflicts are resolved explicitly — priority-based preemption, not last-write-wins

import { SwarmOrchestrator } from 'network-ai';
import { SemanticKernelAdapter } from 'network-ai/adapters';

const adapter = new SemanticKernelAdapter();

// Register your existing SK agent
adapter.registerAgent(orchestrator, {
  agentId: 'planner',
  kernel: yourSemanticKernel,
  capabilities: ['planning', 'decomposition']
});

// Agent reads/writes shared state atomically
// No string-based event names — fully typed
const changeId = board.propose('planner', 'task:status', { phase: 'executing' }, 300);


This also addresses @runceel's feedback about string-based APIs — network-ai uses typed interfaces throughout, so you get compile-time safety on state operations instead of runtime string matching.

12 framework adapters (including SK), 315 tests, zero dependencies, TypeScript-native: [https://github.com/jovanSAPFIONEER/Network-AI](vscode-file://vscode-app/c:/Users/Racunar/AppData/Local/Programs/Microsoft%20VS%20Code/c3a26841a8/resources/app/out/vs/code/electron-browser/workbench/workbench.html)

Happy to compare patterns if you have a specific use case in mind — the "when do I use which" decision usually becomes clear once you map out whether your agents need deterministic handoffs or autonomous coordination (or both).

[moonbox3]

We politely urge anyone looking at SK's process framework to please instead look at Microsoft Agent Framework Workflows: https://learn.microsoft.com/en-us/agent-framework/workflows/. In MAF, Orchestration patterns (group chat, magentic, handoff, etc.) are built on top of workflows APIs. This should help ease friction around choosing how to orchestrate agents and/or build a deterministic graph based on a business workflow/process.

We are not moving forward with the development of SK's Process Framework.