Agent framework vs runtime vs application platform

An agent framework is a code library for building an agent. An agent runtime is managed infrastructure that hosts and scales agents. An agentic application platform is the layer above both that turns agents into a business application: pages and users, one authorization model, governed actions and approvals, business context, versioned outputs, and a release lifecycle.

Is there a standard vocabulary for these layers?

Not yet. The clearest attempt comes from LangChain, which in October 2025 sorted its own packages into frameworks, runtimes, and harnesses. That vocabulary is useful, but vendors use "runtime" and "harness" for different things, so it pays to check what a product actually provides.

In "Agent Frameworks, Runtimes, and Harnesses, oh my!" (October 25, 2025), Harrison Chase described three categories. A framework's main value is its abstractions. A runtime provides infrastructure concerns such as durable execution, streaming, human-in-the-loop support, and persistence. A harness is higher level and comes with batteries included: default prompts, tool handling, planning tools, and file system access. He placed LangChain as a framework, LangGraph as a runtime (and, he wrote, probably both a runtime and a framework), and Deep Agents as a harness, and he acknowledged the lines are blurry. LangChain's documentation uses the same three categories and lists Temporal and Inngest alongside LangGraph as runtimes, and the Claude Agent SDK alongside Deep Agents as harnesses.

Two clarifications help when reading vendor material. First, "runtime" covers both a library that makes execution durable (LangGraph, Temporal) and a managed service that hosts agents (LangSmith Deployment, AgentCore Runtime). This page calls the managed services runtimes and treats durable execution as a capability any layer may supply. Second, "harness" now appears at every layer: AWS offers AgentCore Harness, Microsoft Agent Framework includes a Harness Agent, and Pyrana's runtime and orchestration layer is the Pyrana Harness. None of these vocabularies has a layer for the application itself, which is the gap the third layer fills.

What does an agent framework provide?

A framework gives developers abstractions for the agent's loop: model calls, tools, state, memory, and how agents hand work to each other. It runs inside your code, wherever you deploy it. Everything around the agent (hosting, identity, permissions, approvals, audit, user interface) is yours to build or buy.

The main frameworks, described from their own documentation:

• LangGraph models agents as graphs and lists persistence, human-in-the-loop, short and long-term memory, and a mix of deterministic and agentic steps among its core benefits.
• CrewAI organizes work into agents, crews, and flows; flows manage state, persist execution, and resume long-running work.
• OpenAI Agents SDK provides agents, handoffs and agents as tools, guardrails, sessions, human-in-the-loop, sandbox agents, and tracing.
• Microsoft Agent Framework is the direct successor to Semantic Kernel and AutoGen, built by the same teams. It offers agents, a Harness Agent, functional and graph-based workflows with state management for long-running and human-in-the-loop scenarios, in .NET, Python, and Go (Go in public preview).
• Google Agent Development Kit (ADK) is an open-source toolkit in Python, TypeScript, Go, Java, and Kotlin, deployable to your own infrastructure or to Google Cloud through Agent Runtime, Cloud Run, or GKE.
• Strands Agents is an open-source SDK that AWS introduced in May 2025, taking a model-driven approach to building agents in Python and TypeScript.

A framework is the right layer when the team wants full control of agent behavior and already has, or intends to build, the rest of the stack. The comparison pages in this library go deeper, starting with Pyrana vs LangGraph and Pyrana vs OpenAI Agents SDK.

What does an agent runtime provide?

A runtime hosts agents so a team does not run its own servers for them: endpoints, scaling, session isolation, long-running execution, and usually a set of managed services for identity, tools, memory, and observability. Most runtimes accept agents built with several frameworks. The application around the agent remains the team's work.

• LangSmith Deployment (formerly LangGraph Platform) describes itself as a workflow orchestration runtime purpose-built for agent workloads, with durable execution, real-time streaming, and horizontal scaling. It runs LangGraph and LangChain applications and, through adapters, agents from other frameworks, with cloud, self-hosted, and standalone options.
• Amazon Bedrock AgentCore Runtime is a serverless runtime with session isolation, extended execution for asynchronous agents, and built-in identity. It works with CrewAI, LangGraph, LlamaIndex, Google ADK, OpenAI Agents SDK, Strands Agents, and custom frameworks. AgentCore adds separately usable services: Harness (a managed agent loop), Gateway, Identity, Memory, Policy (which intercepts tool calls at the Gateway), Observability, Evaluations, Optimization, Registry, Browser, Code Interpreter, and Payments.
• Foundry Agent Service in Microsoft Foundry runs prompt agents defined by configuration and hosted agents built with Microsoft Agent Framework, LangGraph, the OpenAI Agents SDK, the Anthropic Agent SDK, the GitHub Copilot SDK, or custom code. Hosted agents get a managed endpoint, autoscaling, a dedicated Microsoft Entra identity, session state, and observability, and can be published to Microsoft Teams and Microsoft Copilot.
• Agent Runtime on Gemini Enterprise Agent Platform (the platform formerly Vertex AI; Agent Runtime formerly Agent Engine, renamed April 22, 2026) sits in the platform's Scale pillar with Sessions, Memory Bank, and Code Execution. The Govern pillar adds Agent Registry, Agent Identity, and Agent Gateway.

A runtime is the right layer when the deliverable is an agent behind an endpoint, consumed by other software or a chat channel, and the team will build the application layer it needs. The hyperscaler offerings are compared side by side in Microsoft Foundry vs AWS Bedrock AgentCore vs Google Gemini Enterprise.

What does an agentic application platform add?

An application platform supplies the parts every business application needs and no agent layer defines: the pages people work on, the operations that can run, who may run them on which records, which invocations need approval, the business knowledge agents rely on, the outputs people trust, and how the application is released. It treats agents as participants, not as the product.

Concretely, the platform layer adds:

• Pages and users. Declared pages where people review and decide, with the agent receiving exact page context, and application membership for each person.
• One authorization model. People and agents pass the same check on the same business records. An agent acts as itself or on behalf of a person, never with more authority than the caller.
• Typed operations reachable from many doors. A page button, a copilot request, an API call, a schedule, an event, or another agent over MCP all reach the same operation through the same check.
• Governed actions and approvals. Policy over the actual arguments decides which invocations wait for a named group, and the decision is recorded.
• Context. Company knowledge with provenance and permissions, shared across applications.
• Versioned outputs. Attributed results that pages read at an exact version.
• Release lifecycle. Application configuration compiled into fixed versions, activated deliberately, rolled back the same way.
• One record. Every call, from every door, writes the same shape of audit record.

Runtimes increasingly offer pieces of this list: agent identity, tool call policy, registries, memory. The difference is scope. A runtime governs an agent's access to tools and resources. An application platform governs a business process in which several agents and many people share data, decisions, and outputs.

Where do agent control planes fit?

Control planes and registries sit beside the stack. They inventory agents built on many platforms, assign identities, and apply organization-wide policy and monitoring. They answer "which agents do we have and what may they reach," not "how does this process run." Enterprises with many agents tend to need both.

Each hyperscaler now has registry and governance services: AgentCore Registry catalogs agents, MCP servers, tools, and skills across environments; Foundry agents can be shared through the Microsoft Entra Agent Registry; Gemini Enterprise Agent Platform includes Agent Registry in its Govern pillar. These are valuable for inventory and policy. They do not give agents shared pages, a permission model on business records, approval lanes, or shared context. The distinction gets its own treatment in agent control planes vs application platforms.

How do you choose the layer?

Start from the deliverable, not the tooling. If the deliverable is an agent, choose a framework and a runtime. If it is a business process people and agents share, decide who builds the application layer: your team on top of a runtime, or a platform.

• Choose a framework alone for research, prototypes, or an agent embedded in a product your team already hosts and governs.
• Add a runtime when the agent must run in production behind an endpoint and you want managed scaling, identity, and observability rather than running them yourself.
• Add an application platform when people must review, approve, and correct agent work on shared pages; when consequential actions need policy-based approval and a record; when several applications should share identity, permissions, and knowledge; or when the second and tenth applications should cost less than the first.

The build side of that last decision is costed out in build vs buy for agentic applications.

Where Pyrana sits

Pyrana is an agentic application platform. It includes its own runtime and orchestration layer, the Pyrana Harness, which provides native tool calling, planning, subagents, checkpoints, and resume, and runs durable workflows on Temporal workers so a run waiting for an approval survives a restart or deploy. Above it, Agentic Apps supplies the application layer: declared surfaces, typed targets, one eight-step admission gate for every door, tool approval policies with named lanes, versioned resources, and a push, activate, and rollback lifecycle. cortIQ supplies governed context as evidence-backed Context Units.

Pyrana works with the other layers rather than replacing them. Any agent, including one built on a framework and hosted on a runtime, can work with a Pyrana App through the App's MCP server as the user, under the same admission and audit. Client code can run as an extension, a client-owned durable backend service reachable only through the platform. Models are assigned per agent through adapters for Azure OpenAI, OpenAI, Anthropic, Google Gemini, and others. Pyrana runs on Azure and supports Entra ID SSO, Databricks, and Snowflake.