Pyrana vs Microsoft Foundry

Architecture

Foundry and Pyrana sit at different layers of the same stack. Foundry is agent infrastructure: it hosts agent code, assigns identities, connects tools, and measures quality. Pyrana is an application platform: it defines the pages people work on, the operations an application can perform, who may approve them, and the versioned outputs agents publish. Pyrana runs on Azure, so the two meet naturally in one tenant.

Foundry Agent Service offers three agent types. Prompt agents are configuration only: instructions, a model, and tools, run by Foundry. Voice-based prompt agents (preview) handle real-time speech. Hosted agents run your own code as a container, each session in a VM-isolated sandbox with a persistent file system, a dedicated Entra identity, and an endpoint that speaks the Responses, Invocations, Activity, or A2A protocol. Hosted agents became generally available in July 2026.

Pyrana's unit is the application, not the agent. One App configuration names the application's surfaces (pages), targets (operations), resources, agents, workflows, tool bindings, access profiles, and approval policies. Agents belong to an App and inherit its rules. Every call, from a page, the copilot, the API, MCP, a schedule, or an external event, passes the same eight-step gate before anything runs.

Foundry, Copilot Studio, Agent 365, and Agent Framework

Microsoft sells four products in this space, and each does a different job. Foundry is the developer platform for hosting and operating agents on Azure. Copilot Studio is the low-code studio for agents and workflows aimed at business makers. Agent 365 is the control plane IT uses to inventory and govern agents. Microsoft Agent Framework is the open-source SDK developers write agents with.

Microsoft Agent Framework is the direct successor to Semantic Kernel and AutoGen, built by the same teams, with agents, a harness agent for long tasks, and graph-based workflows in .NET, Python, and Go (preview). Code built with it deploys to Foundry as a hosted agent. Copilot Studio offers agents, workflows, and agent flows on a choice of harnesses and publishes to Teams, Microsoft 365 Copilot, and websites. Agent 365 provides a registry, access control, an agent map, and security through Entra, Defender, and Purview. It is licensed at $15 per user per month, or included in Microsoft 365 E7. Foundry autopilots, agents with their own Entra agent user account, act in Microsoft 365 as themselves.

Pyrana sits above all four. For the detailed pairings, see Pyrana vs Copilot Studio and Pyrana vs Microsoft Agent Framework.

Context and knowledge

Foundry grounds agents in documents and remembers users. Pyrana curates company knowledge as governed claims with evidence. Foundry IQ, built on Azure AI Search, grounds agents on organizational content, and Foundry Memory (preview) extracts user profile, chat summary, and procedural memories. Pyrana's context engine, cortIQ, stores knowledge as Context Units: a claim, its evidence passage, a type, a classification, and a content-hash identity.

The difference shows up in change control and proof. Foundry Memory consolidates and resolves conflicting facts with an LLM, and Microsoft advises guarding memory stores against prompt injection and memory corruption. In cortIQ, classification gates every change: absolute units never auto-change, regulated units wait for a person, tribal units are conflict-checked, and changes supersede rather than overwrite. Every run accounts for each unit as retrieved, injected, or cited, and citations are content-addressed, so the exact business context behind an output is provable.

Agent capabilities

Foundry offers more ways to build an agent. Pyrana offers more structure around what agents do inside an application. Foundry spans configuration-only agents, voice agents, and container-hosted code in any framework, with tools such as code interpreter, web search, browser automation, SharePoint, and Fabric IQ. Pyrana's Harness supports native tool calling, planning, subagents, checkpoints, and workflows that fan out to specialized agents per entity.

In a Pyrana workflow, one run dispatches many agents in parallel. Each pulls only what its job needs through tools scoped to it, reads what sibling agents and prior runs published, and publishes back to the App as versioned resources. Agents do not write free-form queries; tools hold the query and the agent passes parameters such as the entity and period. Foundry gives developers the primitives to build similar patterns in their own code.

Governed actions and approvals

Foundry can pause a tool call for approval. Pyrana decides which calls need approval, routes them to the right people, and records exactly what was approved. In Foundry, setting an MCP tool's require_approval returns an approval request that your application must answer. Long-running hosted agents can suspend for days and resume after a reply, in preview. Thresholds, approver routing, and the review screen are your code.

In Pyrana, a tool approval policy over typed arguments, such as an amount above a threshold or a requester outside a group, decides when an invocation needs a person. A tripped policy freezes the operation, its exact arguments, scope, and evidence under a hash and queues it to a named approval lane. Reviewer eligibility is checked at decision time, the frozen invocation is revalidated before dispatch, and dispatch is idempotent. A queued request is visibly different from a posted one.

Building the application

On Foundry, the application around the agent is a separate project. On Pyrana, it is configuration plus a frontend. A Foundry agent gives you an endpoint and, if published, a presence in Teams and Microsoft 365 Copilot. The pages, records, review queues, and business rules of an application are built by your team, typically on App Service, Functions, and Cosmos DB.

A Pyrana application declares its pages, and the platform hands an agent the exact page context a person is looking at. Outputs are resources: immutable, attributed versions that pages read at an exact version, with stale publishes refused. People can ask the copilot for personal pages, which are compiled without network access or authority and stay read-only. With clean data available, an application typically takes about a week to stand up, and the frontend experience is the main effort.

Governance and security

Both use Entra ID. Foundry governs agents as Azure resources; Pyrana governs every call as a business operation. Foundry gives each agent an Entra identity, supports On-Behalf-Of passthrough, Azure RBAC, private networking, and guardrails against prompt injection. Agent 365 adds organization-wide inventory, access policy, Defender, and Purview. Pyrana authorizes in layers: tenant, App membership, access profile, scope entitlement, and approval lane.

Pyrana's gate writes the execution row and audit record in one transaction before dispatch, and fails closed: unauthorized things read as absent. Reading a record and approving a change are separate permissions. The user's principal passes through to Databricks and Snowflake, so warehouse row-level security applies to the same person. Pyrana is SOC 2 aligned and supports customer programs under HIPAA, SOX, ISO 27001, and PCI DSS.

Operations

Foundry operates agents; Pyrana operates applications. Foundry versions agents immutably, routes each endpoint to one version, injects Application Insights into hosted agents, and offers cloud evaluations and an agent optimizer. Foundry Agent Service runs in 30 Azure regions and in Azure Government. Its standard setup keeps agent state in your own Cosmos DB, Storage, and AI Search.

Pyrana's lifecycle covers the whole application. Push compiles the App configuration into an immutable version; activate moves the active pointer, is audited, and requires an App owner; rollback is activating a prior version; deploy ships a frontend image. Workflows run on Temporal workers, so a run waiting for approval survives a restart or deploy. Every run's traces, tokens, and tool errors are available as JSON through the administrative API, and evaluation runs deterministic checks before an LLM-as-judge stage in Agent Studio.

Cost structure

Foundry is pure consumption; Pyrana is a platform subscription plus implementation. Foundry bills model tokens per call, tool usage, separately licensed connections such as Grounding with Bing and Foundry IQ, and hosted agent compute per vCPU-hour and GiB-hour across active sessions. Memory has its own meters. Agent 365 adds a per-user license if you adopt it.

Pyrana's cost is an enterprise platform subscription and implementation, and model usage runs on the client's own keys. Pyrana routes platform jobs such as summarization to small, medium, or large models to keep cost in proportion to the task. A first engagement, including SSO, access profiles, the approval policy, and loading the policy library into cortIQ, runs about six weeks.

What it takes to ship the same application

The reference application: 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.

Using them together

• Models. Pyrana supports Azure OpenAI through its adapter and runs on Azure, so Pyrana agents can use the same model deployments a Foundry project uses, with the client's own keys.
• Identity. Pyrana uses Entra ID for single sign-on, the same directory that issues Foundry agent identities.
• Foundry agents as tools. A Foundry hosted agent's Responses or Invocations endpoint can be a REST tool source in Pyrana, and a Foundry Toolbox's MCP endpoint can be an MCP tool source. Pyrana's gate and approval policies apply before the Foundry agent is called.
• Pyrana as a tool for Foundry agents. Each Pyrana App exposes an MCP server. A Foundry agent connected with OAuth identity passthrough works with the App as the user, inside that user's permissions.
• Data. Foundry agents reach Fabric data through the Fabric data agent and Fabric IQ tools. Pyrana's Databricks and Snowflake tool sources pass the user principal through to warehouse row-level security.

When not to choose Pyrana

• You need a host for agent code your developers own end to end, with no application layer around it. Foundry hosted agents fit that job directly.
• The experience lives entirely in Teams or Microsoft 365 Copilot and no separate application is wanted. Foundry publishing, or Copilot Studio, is the shorter path.
• You are building a real-time voice or telephony agent. Foundry's voice agents and Voice Live are built for that.
• The work is model experimentation, fine-tuning, or evaluation research rather than a business process with approvals.
• One team is building one agent with no shared users, approvals, or audit needs across applications.