Pyrana vs Microsoft Agent Framework

Architecture

Microsoft Agent Framework is a set of libraries. A team imports it, writes agents and workflows in .NET or Python, and builds the application around them. Pyrana is a running platform. A team writes one App configuration and a frontend, and the platform supplies identity, authorization, orchestration, approvals, storage, context, and audit. The framework produces an agent. The platform hosts the application the agents work inside.

Agent Framework groups its features into four areas: agents that call models, tools, and MCP servers; a Harness Agent with planning, context compaction, file access, memory, and tool approval for long tasks; workflows that connect agents and functions through explicit graph paths; and integrations with model providers, agent services, memory, evaluation, and UI frameworks. First-party model connectors cover Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic, Amazon Bedrock, Google Gemini, and Ollama. Version 1.0 shipped on April 3, 2026 for .NET and Python; Go is in public preview.

Pyrana's seven layers (harness, Temporal orchestration, tool sources, tool approval policies, durable storage, the context engine, and the frontend surface layer) are built once and shared by every application. Each call passes an eight-step gate before it runs.

Is Microsoft Agent Framework a platform?

No. Microsoft describes it as an open-source SDK. Microsoft's platform for running agents is Microsoft Foundry and Foundry Agent Service (formerly Azure AI Foundry), which can host Agent Framework code as containerized hosted agents. Even with Foundry hosting, the business application (its records, pages, roles, and approval rules) is what the team builds.

Context and knowledge

Agent Framework supplies building blocks for context: sessions for state, context providers for memory, and integrations with vector stores and search. What to retrieve and how to govern it is the team's design. Pyrana's cortIQ engine stores knowledge as typed, classified Context Units with evidence passages and content-hash identities, and accounts for each unit retrieved, injected, and cited per run.

In cortIQ, classification governs change: absolute units never change on their own, regulated units wait for a person, tribal units are conflict-checked, and derived units update themselves. A query agent plans graph walks and repairs its own queries; a learning agent flags units that never help. A team on Agent Framework can build equivalent structures, and some will prefer to, but they start from a vector store and a context provider interface.

Agent capabilities

Agent Framework offers a rich agent model in code: function tools, MCP clients, middleware that intercepts agent actions, multi-agent orchestration patterns (sequential, concurrent, handoff, group chat, Magentic), and declarative YAML agent definitions. Pyrana offers agents configured in plain language, each bound to job-specific tools and assigned one model, dispatched by workflows that fan out per entity and publish back.

The real difference is degrees of freedom. Agent Framework lets engineers write any orchestration they can express in code, including custom executors and agent-as-workflow composition. Pyrana constrains agents on purpose: agents do not write free-form queries, tools hold the query, every call is admitted and audited, and a model is not switched mid-run. Teams that need unusual agent behavior often want the SDK. Teams that need repeatable, reviewable business processes often want the constraint.

Governed actions and approvals

Agent Framework supports human in the loop at the tool level: mark a tool as approval-required and the run returns an approval request instead of executing. The calling application collects the decision and passes it back. Pyrana treats approval as platform policy: a rule over typed arguments queues the frozen invocation to a named lane, checks reviewer eligibility, and revalidates before dispatch.

Agent Framework's design is careful. In Python, an approval response authorizes a tool call only if it matches a pending request recorded in the same session, which blocks replayed or fabricated approvals by default. The Harness Agent adds queued requests and standing "always approve" rules. What the framework does not decide is who may approve, how they are notified, what screen they see, or where the decision is recorded for auditors. Those are application concerns. In Pyrana they are configuration: thresholds and compound rules over arguments, named lanes, idempotent dispatch, and a queued request that reads differently from a posted entry.

Building the application

On Agent Framework, the team builds the application: API, database, user interface, authentication, role model, approval screens, and deployment. Microsoft provides DevUI for testing and AG-UI integration for front ends, both preview in 1.0. On Pyrana, the team writes an App configuration that names pages, operations, resources, agents, workflows, tool bindings, access profiles, and approval policies, then builds the frontend.

Pyrana's lifecycle is push (compile an immutable version), activate (an audited pointer move by an App owner), and deploy (ship the frontend). Rollback is activating a prior version. With clean data, an application typically stands up in about a week. On Agent Framework, timeline depends on how much of that surrounding application the team already has.

Migrating from Semantic Kernel or AutoGen

Microsoft calls Agent Framework the direct successor to both, built by the same teams. The AutoGen README states it is in maintenance mode and community managed; the Semantic Kernel README directs users to Agent Framework. Migration is mostly mechanical. The Kernel object goes away; tools register directly on the agent; AgentThread becomes AgentSession; service-specific agent classes consolidate into one chat client agent. In Python, existing KernelFunction instances convert with as_agent_framework_tool (Semantic Kernel 1.38 or later), and Semantic Kernel vector store search functions carry over.

A migration is also a natural moment to ask what the agents were for. If the Semantic Kernel code was the core of a business application with users, roles, and approvals, the choice is between rebuilding that application on Agent Framework or moving the business process to a platform and keeping only custom agent logic in code. Pyrana supports the second path: custom logic runs in an extension, and the platform supplies the rest.

Governance and security

Agent Framework leaves governance to the host. Microsoft's documentation says developers are responsible for their own responsible AI mitigations and for how data flows to third-party systems. When hosted on Foundry Agent Service, each agent gets a dedicated Entra agent identity and runs in a per-session sandbox. Pyrana enforces layered authorization per call: tenant, App membership, access profile, scope entitlement, approval lane.

Foundry hosting adds real controls for Agent Framework code: Entra identities, private networking, immutable agent versions, and Application Insights tracing. Those secure the agent. They do not define which person may approve which purchase request for which entity. Pyrana's gate does: one authorization check per call, fail-closed, with unauthorized things reading as absent, and the audit record written in the same transaction as the execution row. Pyrana is SOC 2 aligned, supports Entra ID SSO, and passes the user principal through to Snowflake and Databricks.

Operations

Agent Framework emits OpenTelemetry traces and integrates with evaluation services; operating the host is the team's job unless Foundry hosts it. Pyrana captures every run's traces, tokens, and tool errors as JSON through an administrative API, with deterministic checks followed by LLM-as-judge in Agent Studio.

Durability is opt-in on Agent Framework. Workflows checkpoint at the end of each superstep to storage the team chooses: in-memory, local file, or Azure Cosmos DB in Python, with custom stores possible. Durable agents can also run on the Durable Task Scheduler or Azure Functions. Microsoft notes that checkpoint storage is a trust boundary the team must secure. Pyrana's workflows run on Temporal workers by default, with separate worker pools for data fetching, file extraction, and the code interpreter.

Cost structure

Agent Framework is open source under the MIT license. Cost is model inference, hosting (Foundry hosted agents bill for CPU and memory during active sessions), storage, and the engineering to build and maintain the surrounding application. Pyrana is an enterprise platform subscription plus implementation, with model keys brought by the client.

The comparison is less license versus subscription than build versus configure. A single agent embedded in a product is often cheapest on the SDK. A portfolio of governed applications repeats the identity, authorization, approval, storage, and audit work for each one unless something shared provides it. A first Pyrana engagement, including SSO, access profiles, approval policy, and loading the policy library, runs about six weeks.

What it takes to ship the same application

Reference application: an approval-gated procurement request. A person or agent drafts a purchase request; amounts above a threshold need a finance approver; the request waits durably for the decision; everything is recorded.

This table is drawn from documentation; build effort has not been benchmarked.

Using them together

Pyrana runs on Azure, uses Azure OpenAI and Entra ID, and can call Foundry-hosted models and agents. Agent Framework is Microsoft's code path into the same estate, so the two meet in several places.

• Agent Framework inside a Pyrana extension. An extension is a client-owned durable backend service in the same cluster, built with a platform library that handles authentication and authorization. Custom Agent Framework logic can live there, reachable only through Pyrana's gate.
• Foundry-hosted Agent Framework agents as tools. A hosted agent exposes Responses, Invocations, and A2A endpoints. Pyrana can bind it as a tool, so its call is admitted, policy-checked, and audited.
• Agent Framework agents calling Pyrana over MCP. Agent Framework includes MCP clients. Every Pyrana App exposes an MCP server through which an agent works with the App as the user.
• Shared models. Both use Azure OpenAI and Foundry models, with the client's own keys.

When not to choose Pyrana

• You are embedding one agent into your own software product and want no external platform in the runtime path.
• Your engineers want to own every layer in .NET or Python and have capacity to build and run identity, authorization, storage, and audit.
• The use case needs orchestration patterns, such as group chat or Magentic, expressed directly in code.
• You need an open-source license for the whole stack.
• You are migrating existing Semantic Kernel or AutoGen code with no business application around it.