Powered byLightning AI
Back to blogArchitecture comparison

GraphN vs Microsoft Agent Framework: decide where the platform begins

Published
August 9, 2026
Reading time
12 min

Decision summary

Choose Microsoft Agent Framework with Foundry when

the application is Azure-native, Entra identities and Azure resources should define the security boundary, and the team wants C# or Python orchestration code.

Choose GraphN when

workflows should be shared visual and YAML resources, workspace-scoped models and isolated Python functions should be built in, or Azure should not be the organizing boundary for agent operations.

Microsoft Agent Framework is the current successor to AutoGen and Semantic Kernel. Microsoft Foundry Agent Service can host that code with Azure identity, tools, sessions, and telemetry. GraphN starts from an integrated workspace where workflows, agents, models, functions, knowledge, files, and secrets share one lifecycle.
The first question is naming. In its current documentation, Microsoft calls Agent Framework the direct successor to both AutoGen and Semantic Kernel. It combines AutoGen-style agent abstractions with Semantic Kernel features such as session state, type safety, middleware, telemetry, and broad model support, then adds graph-based workflows.
That means a new 2026 architecture review should not treat “AutoGen vs GraphN” as two current greenfield choices. AutoGen remains relevant to installed systems and search intent, but Microsoft's own AutoGen migration guide points new development toward Agent Framework.
The comparison also needs two Microsoft layers:
  • Microsoft Agent Framework is an open-source C#/.NET and Python SDK, documented as public preview at the time of review.
  • Microsoft Foundry Agent Service is the managed Azure runtime. The hosted service is generally available, while the Python Agent Framework hosting integration is documented as prerelease.
GraphN combines more of those layers into one product boundary.

Product boundary

Scroll horizontally to compare
LayerMicrosoft stackGraphN
AuthoringAgent Framework SDK in C# or PythonCanvas and versioned YAML DSL
OrchestrationAgents plus explicit workflows in application codePublished workflow graph with supported step types
HostingFoundry prompt agents or containerized hosted agentsManaged published workflow endpoints
IdentityEntra and dedicated hosted-agent identityWorkspace membership and workspace API keys
ToolsFoundry Toolbox, MCP, OpenAPI, code interpreter, search, custom codeMCP servers, workspace functions, connectors, knowledge
ModelsFoundry model catalog and SDK model clientsBuilt-in open-weight models, imported endpoints, custom weights
TelemetryOpenTelemetry and Application Insights/Foundry tracesExecution traces, spans, timing, usage, logs
Deployment ownershipAzure managed service or your external hostingManaged GraphN platform
Agent Framework alone is not equivalent to GraphN. Foundry alone is also not the same authoring model. The closer comparison is Agent Framework + Foundry services versus GraphN.

Orchestration: application workflow versus platform workflow

Agent Framework supports single agents, multi-agent patterns, and explicit workflows. Its value is that orchestration remains normal program code: typed messages, middleware, executors, routing, and provider clients can live beside the rest of the application. C# teams get .NET type systems and dependency injection patterns; Python teams can use the corresponding SDK.
GraphN's workflow DSL defines an executable graph with agent, function, MCP tool, connector, conditional, bounded loop, parallel analysis, handoff, and judge-loop steps. The same definition appears in the visual editor and can be validated, dry-run, updated, and published from the CLI.
The decision is partly organizational:
  • Agent Framework lets an application team create any abstraction the language permits.
  • GraphN constrains workflows to a platform vocabulary so a workflow can move between visual editing, source-controlled YAML, and platform APIs.
If a team's critical orchestration logic depends on custom executors and domain types, an SDK is the natural home. If product operators, solutions engineers, and developers need to inspect the same graph, a platform-level definition reduces translation.

State and long-running work

Microsoft Agent Framework advertises session-based state and workflow support for long-running and human-in-the-loop scenarios. Hosted agents add managed conversation and session lifecycle. The Foundry hosting integration says the platform handles scaling, session-state persistence, security, and lifecycle management, including persistence of $HOME and uploaded files across turns and idle periods.
These are several distinct state stores:
  • Agent Framework workflow state belongs to the SDK execution.
  • Foundry conversation/session state belongs to the hosted protocol.
  • Files persisted under a hosted session are not the same as a governed knowledge index.
  • Application databases still own business records and idempotency.
GraphN exposes sync and async workflow executions, versioned published snapshots, statuses, outputs, errors, and per-run traces. Its knowledge bases and object storage are separate workspace resources. That separation is useful, but it is not evidence of arbitrary checkpoint rewind or a general long-term memory service.
For either product, test the exact failure boundary. Kill a worker after a side-effecting tool succeeds but before the next step records completion. Observe whether the platform retries, duplicates, resumes, or fails. “Long-running” does not answer idempotency.

Tools, code, and isolation

Foundry hosted agents run custom agent code as containerized applications on Microsoft-managed infrastructure. They can use a Toolbox MCP endpoint for managed tools including Code Interpreter, web search, Azure AI Search, OpenAPI, A2A, and skills. The toolbox centralizes authentication modes such as OAuth identity passthrough, agent identity, and keys.
That is a strong fit when tools are Azure resources or SaaS systems already governed through Entra. A dedicated agent identity gives the deployment a recognizable principal for downstream authorization.
GraphN treats code and integrations as different resources:
  • MCP servers expose structured tools.
  • Workspace Python functions provide managed isolation for deterministic code.
  • Secrets bind credentials without putting values into prompts.
  • Knowledge bases and storage provide retrieval and file operations through the function SDK.
The isolation units are not identical. A Foundry hosted agent is a containerized application with allocated CPU and memory. A GraphN function is a bounded function invocation inside a managed workflow. If the whole agent application needs arbitrary packages, background behavior, custom protocols, or writable session files, Foundry's hosted-container boundary can be more natural. If short workflow-authored functions are the untrusted code boundary, GraphN's documented function boundary is more opinionated.

Deployment and API behavior

Foundry hosted agents can expose the OpenAI-compatible Responses protocol or a more general Invocations protocol for custom payloads and webhooks. The managed service handles container deployment and scaling. Azure subscriptions, projects, resource providers, quotas, networking, and supported regions remain part of the deployment plan.
GraphN publishes workflows behind workspace-scoped HTTP endpoints. API keys and workspace IDs scope automation calls. The same workflow can be run from the web app or CLI, and asynchronous executions return an ID for polling or watching.
Both offer an OpenAI-related compatibility surface, but for different objects:
  • Foundry's Responses protocol is an interface to the hosted agent.
  • GraphN uses OpenAI-compatible APIs primarily at the model/inference boundary while published workflows have GraphN's workflow-run contract.
Do not plan a migration based on the word “OpenAI-compatible” without comparing request, streaming, tool, session, error, and cancellation semantics.

Observability

Agent Framework emits OpenTelemetry spans. Foundry hosting correlates telemetry with project, agent name, version, and ID, and exports to Azure Monitor/Application Insights. The Foundry tracing guide distinguishes automatic hosted-agent setup from agents hosted elsewhere, where teams configure the Microsoft OpenTelemetry distribution and exporters.
GraphN execution traces can include spans, timing, token usage, resource references, and per-node results. Because workflows, models, tools, and functions are workspace resources, trace entries can connect directly to platform-owned definitions.
For an Azure operations team, Application Insights integration may be the deciding advantage. It connects agent telemetry to existing dashboards, retention, alerting, and incident response. For a team that wants agent operations contained inside one workflow product, GraphN's integrated execution view reduces context switching.
In either case, verify:
  • prompt and completion redaction;
  • end-user identity propagation;
  • sampling and retention;
  • trace export;
  • cost attribution per model and tool;
  • evaluation workflows, not only request traces.

Models and inference

Agent Framework uses model clients rather than requiring Azure-only models. Microsoft's documentation warns that third-party systems and non-Azure-direct models remain the customer's responsibility. Foundry provides a broad model catalog and Azure-managed endpoints.
GraphN also supports provider flexibility, but its differentiator is operating model infrastructure inside the platform. The GraphN models reference covers built-in chat and vision models, OpenAI-compatible endpoints such as vLLM, Ollama, OpenAI, Gemini compatibility, and OpenRouter, plus custom weight imports from Hugging Face or S3.
This leads to a clean selection test:
  • If model access is already standardized through Azure AI Foundry, use that existing governance and quota plane.
  • If open-weight inference, custom weights, LoRA deployments, and agent workflows should share one managed platform, evaluate GraphN's integrated path.
  • If a company model gateway must stay authoritative, prove both products can use it without bypassing policy or duplicating credentials.

Knowledge, files, and data boundaries

Foundry offers Azure AI Search, file/search tools, Code Interpreter files, and Azure data services. Those are composable Azure resources with their own indexes, identities, billing, regions, and lifecycle.
GraphN provides workspace knowledge bases and storage as native resources. A workflow can upload or read files, ingest documents, retrieve ranked chunks, rerank them, and pass results to agents or functions. Multimodal knowledge bases can index text and images.
Azure's composability is valuable when the enterprise already has search indexes, data lakes, private endpoints, and governance. GraphN's integrated abstraction is valuable when the team wants to create the retrieval and file path with the workflow instead of first designing an Azure resource graph.

Authentication and secrets

Microsoft's strongest differentiation is identity depth. A hosted agent can receive a dedicated Entra identity and use managed authentication to Azure or third-party tools. End-user OAuth passthrough supports delegated actions when configured correctly.
GraphN's strongest default is workspace scoping. Resources and API keys belong to a workspace; secret values stay out of normal resource responses and prompts. This is simpler than designing a new cloud identity topology, but it does not replace per-user authorization at downstream systems.
Ask which principal appears in each audit log:
  1. the human user;
  2. the workspace or project;
  3. the deployed agent;
  4. the tool;
  5. the platform service.
A secure design often needs more than one.

What AutoGen teams should do

Microsoft's migration guide maps AutoGen concepts to Agent Framework and includes side-by-side code. That is the lowest-risk starting point for an AutoGen estate because it preserves the SDK programming model and moves toward the vendor's current foundation.
Evaluate GraphN instead when the migration goal is broader than API modernization—for example:
  • exposing workflows to visual builders;
  • replacing application-managed tool code with isolated functions and MCP resources;
  • consolidating model serving and knowledge resources;
  • publishing versioned workflows as managed endpoints.
An AutoGen group chat does not map one-to-one to GraphN's handoff_router, and a GraphN handoff workflow does not map one-to-one to Agent Framework orchestration. Preserve test conversations and tool-call traces, then compare behavior.

Migration boundaries

Agent Framework to GraphN

  1. Classify each agent, workflow executor, tool, model client, and state store.
  2. Represent supported control flow in GraphN YAML.
  3. Move bounded deterministic Python into workspace functions; keep long-lived services external.
  4. Register external tools through MCP and bind credentials as GraphN secrets.
  5. Import or register models and rebuild data retrieval as knowledge/storage resources where appropriate.
  6. Re-run a fixed corpus and compare structured outputs, tool side effects, and trace completeness.

GraphN to Agent Framework and Foundry

  1. Export workflow and linked resource definitions.
  2. Recreate steps as typed agents, executors, and workflow edges.
  3. Choose Foundry tools or implement MCP/OpenAPI clients.
  4. Select session persistence, search, file, and business-data stores.
  5. Containerize the agent, assign an Entra identity, and define Azure networking.
  6. Instrument OpenTelemetry and connect operational alerts and evaluations.

Choose Microsoft Agent Framework and Foundry when

  • C#/.NET or Python application code should remain the source of orchestration truth.
  • AutoGen or Semantic Kernel migration continuity is important.
  • Entra identity, Azure AI Search, Application Insights, and Azure networking are strategic standards.
  • You need a whole custom agent container, custom protocols, or Azure-managed session files.
  • Your platform team is comfortable managing Azure projects, policies, quotas, and resource topology.

Choose GraphN when

  • Visual and code-based builders must share one workflow definition.
  • Workspace agents, MCP servers, functions, secrets, knowledge, storage, and models should publish together.
  • Isolated short-lived Python functions should be a built-in execution primitive.
  • Open-weight and custom model hosting should sit beside agent orchestration.
  • You want the application platform boundary without making Azure the control plane.

A proof-of-concept that exposes the difference

Implement an approval-sensitive document workflow:
  1. ingest a private file;
  2. retrieve supporting passages;
  3. ask two model-backed specialists;
  4. pause for a human decision;
  5. call a side-effecting external API;
  6. return structured JSON and an audit trail.
Test Entra/workspace identity propagation, worker restart, duplicated approval messages, secret rotation, model substitution, and trace redaction. Measure custom infrastructure and policy code, not only lines in the agent definition.
Review how GraphN scopes the workflow platform, its core concepts, API, and blueprints alongside a Foundry prototype before deciding where your platform should begin.

Primary sources

  • Microsoft Agent Framework overview

    Defines Agent Framework's SDK scope, supported languages, workflow model, and relationship to AutoGen and Semantic Kernel.

  • AutoGen to Microsoft Agent Framework migration guide

    Supports the article's treatment of Agent Framework as Microsoft's current migration target for AutoGen applications.

  • Microsoft Foundry hosted-agent integration

    Documents how Agent Framework code integrates with the managed Foundry hosted-agent runtime.

  • Microsoft Foundry hosted agents

    Describes hosted-agent lifecycle, service boundaries, identity, and managed execution in Foundry.

  • Microsoft Foundry agent tracing

    Documents the Application Insights and tracing path evaluated in the observability comparison.

  • GraphN workflow DSL

    Documents GraphN's versioned YAML workflow model and orchestration primitives.

  • GraphN models reference

    Defines the built-in, imported, and custom model boundary discussed in the platform comparison.