Skip to content
Pyrana

Platform

The agent loop is the easy part. The foundation is the hard part.

A framework gets an agent working in an afternoon. Production needs identity, permissions to the row, approval on the exact action, a record before every action, runs that survive failure and knowledge that stays true, and most teams rebuild that foundation for every project. In Pyrana it is already built. The Agentic App is the unit we deliver; everything else is inside it.

1cortIQ context engineSourcedConnectedVersionedGovernedcortIQ. The company's knowledge in one place, as small statements a person can check.cortIQ
2ConnectionsAPIsDatabasesTool serversFilesIdentityWrite-backConnections. Pyrana works on top of the systems the company already runs, and replaces none of them.
3AgentsSpecialistsFinish checksAgents. Specialists, each with one job, its own tools and a clear test for when it is done.Inside an agent4WorkflowsHierarchiesDurable runsWorkflows. How many agents work together, in order, across a whole company tree.Inside a workflow5ApplicationsPages and copilotRoles and scopesApplications. The unit a business owns and uses: its pages, copilot, agents, data and roles in one place.Inside an App6Application statePlans and decisionsExtensionsApplication state. A home for what no existing system holds: plans, decisions, reviews and exceptions.Extensions7Enterprise foundation: security and governance around every blockCompany sign-inFine-grained accessApproval by a personAudit trailTenant isolationSecurity and governance. Every block runs inside the same controls, set by the company.Security and trust8CodeTested codeNumbers by codeCode. A sandbox where numbers are computed, not written by a model.Numbers by code
9Models and hostingRight model per agentRetries and failoverBudgets and limitsYour environmentPer-client deploymentSecure model access and hosting. The models, and the platform itself, run where the company decides.
10ObservabilityEvery run and tool callCost and lineageObservability. Every run can be followed, step by step.One causal trace
11BuildBy conversationIn codeVersioned configurationBuild by conversation. A copilot that builds with the builder.
12Push, activate, deployVersioned releasesRelease. Changes reach each client in a controlled way.Push, activate, deploy

Interactive: click any block. Blocks marked Open lead to an inside view.

The hard part is already built.

00The short version

  • The hard part is already built.

    Ships asone description of the applicationa published versionone-click switch and rollback
  • Every way in, the same checks.

    Ways ina pagethe copilotan API callanother agenta schedulean event
  • Identity, authorization, audit, context: shared by every application.

    Shared viapermissions in layersone recordcortIQ knowledge

The decision frame

Build or buy now has a third answer. Build on a platform.

Agentic applications on Pyrana

  • Financial close
  • Collections
  • Procurement
  • Compliance
  • Reporting
  • Customer service
  • Supply chain
  • People operations

Data layer · bought

  • Fabric
  • Databricks
  • Snowflake

Read live, as the user. No copy required.

Systems of record · bought

  • ERP
  • HR
  • CRM

A few, with AI built in.

Software is not dead. Buying a separate application for every workflow is.

A few vertical tools

Only where a vendor owns knowledge you cannot reproduce.

Go deeperBuild, buy, or build on a platform9 min

And, not or

Keep what you have. Pyrana adds the application layer.

Copilots stay with every knowledge worker. In-app agents keep taking steps out of existing processes. The data platform stays the data layer and the control plane keeps the inventory. Pyrana turns what you already have into governed work, for the workflows that need an application.

  • Copilots and in-app agents

    A copilot for every knowledge worker, whichever you chose: Microsoft 365 Copilot, Claude Cowork, ChatGPT Enterprise or Gemini. In-app agents for steps inside existing processes. Keep them; Pyrana is the top tier.

    Pyrana and Copilot Studio
  • Data platforms

    Fabric, Databricks and Snowflake are the data layer. Pyrana reads them live, as the user.

    Pyrana and Microsoft Fabric
  • Agent control planes

    Agent 365, AI Control Tower and Agent Fabric keep the inventory. Registering agents governs the roster. Checking each operation governs the actions.

    Control planes and platforms
  • Models and labs

    Any major model, on your own keys, chosen per agent. The labs need a way into the enterprise; Pyrana is that way.

    Pyrana Harness
  • Temporal and MCP

    Durable execution runs on Temporal underneath the Harness. Every application is an MCP server and uses MCP tools.

    Pyrana and Temporal

00The stack

Seven layers, shared by every application.

the stack
seven layers, shared by every application
  1. Pyrana Harnessagent runtime: native tool calling · planning · subagents · checkpoints · resume
  2. Orchestrationdurable workflows that fan out, wait, retry, and finish · scheduled or on demand
  3. Tools and tool sourcesREST · ODBC · MCP and gateways · Databricks · Snowflake · Drive · OneDrive · client extensions. Each call authorized.
  4. Tool approval policiesconsequential actions queue for the right people before they execute · thresholds and named lanes
  5. Durable storageversioned resources · artifacts · the context engine's curated knowledge
  6. cortIQcompany knowledge as typed, classified, evidence-backed Context Units in a knowledge graph
  7. Surfacesthe App shell · declared pages · the copilot · pages people generate for themselves
Under all of itidentityauthorizationauditone execution record per call

01The gate

Every door. One gate. Eight steps.

A call arrives from the App's own pages, the copilot, the API, MCP, a schedule, or an external event. Before anything runs, the gate performs eight steps: identity and idempotency key; active App version; target exists and the caller is allowed; page and resource references resolved to exact versions; one authorization check (membership, profile, entitlement on the entity); idempotency claimed and the execution row and audit record written in one transaction; dispatch to the native host; outcome recorded.

The gate fails closed. Unauthorized things read as absent, not denied. One desk serves the page, the schedule, the agent, the workflow, and the external system.

the gate
fail closed
gate decision
exec_01J9Q4M7Z3
execution
exec_01J9Q4M7Z3 · idempotency key idem_7f2c…41aa
caller
maya.chen · sso:entra-id → agent:close-reviewer on her behalf
app version
finance-close@v14 · sha256:3f9a71c2…e08b · active pointer
target
ledger.journal.post · exists · door=copilot · caller allowed
page / resource refs
surface close/entries · journal-batch@v3 · policy jrnl-threshold@v3 · resolved to exact versions
authorization
App member · profile=controller · entitlement entity:US-01 · lane=controllers above 25,000 USD
idempotency
claimed · execution row written · one transaction
audit
record written before dispatch · outcome recorded on return
Go deeperHow it works, step 04: the gate2 min

02Three product layers

Agentic Apps hold the configuration. The Harness runs it. cortIQ carries the knowledge.

Agentic Apps

The unit Pyrana delivers: your process, built as an application.

  • Describe the application once, publish a version, and switch or roll back versions with one click
  • The pages people work in tell the agent exactly what the person is looking at; every way in reaches the same actions and the same checks
  • Your own code, in your own repository, running under the same rules

Pyrana Harness

The runtime your agents and workflows run inside.

  • Tool calling, planning, helper agents, checkpoints and resume, with a model chosen per agent
  • Workflows hand work to specialized agents for each entity, in parallel, and every result publishes back to the application
  • Approval policies: the approved action is the exact one that runs, approved by the person your policy names, and it runs once

cortIQ

Traceable company knowledge that adapts with your business.

  • Documents and know-how become single claims, each with its evidence, its scope and its date
  • Rules, Procedures, Findings and Definitions, loaded before the agent starts and searched while it works
  • Every run records what it found, what it was given and what it used

03Foundation

Identity, authorization, audit, under every layer.

The foundation is not a final check. App compilation, the gate, execution, tool calls, and resource reads all use the same identity, the same authorization layers, and the same audit record.

foundation
SSO · tenant boundary · access layers · audit
  • Identity

    SSO through Entra ID or OAuth. A person, a service, a workflow, and an agent each carry their own identity: an agent with its own identity, an agent on behalf of a user, a workflow as a service principal. All take the same authorization path, and nothing is flattened into a shared account.

  • Authorization in layers

    Tenant boundary, App membership, access profile (read, run, approve), scope entitlement on an entity, a project, or a queue, and approval lanes for consequential actions. Every layer is decided on the backend; the page only reflects it. Unauthorized items are absent from results, not denied.

  • Deployment and scale

    Hosted as SaaS on a dedicated private tenant, or deployed into the client's own infrastructure for large enterprises. Temporal workers provide durability and horizontal scaling. Separate worker pools handle data fetching, file extraction, and the code interpreter.

  • Tool sources

    REST, ODBC, MCP and MCP gateways, Databricks, Snowflake, Google Drive, OneDrive. Agents query live through tools scoped to the job, so the platform does not need to store source data. Each call is authorized and audited.

  • Model per agent

    A model is assigned per agent through provider adapters (Azure OpenAI, OpenAI, Anthropic, Fireworks, Google Gemini, and others) and is not switched mid-run. The client brings its own keys. Client data never trains external models.

  • Audit before execution

    Every admitted call writes its execution row and audit record in one transaction before dispatch: caller, App version, target, resource versions, authorization outcome, approvals, effects with receipts, and the context cited.

Go deeperSecurity and trust6 min
For engineers and architects4 min

04Configuration

One App configuration. One immutable version.

A client authors one App configuration: surfaces, targets, agents, workflows, tool sources, resources, access, knowledge. Everything the configuration names already exists in the platform. Push compiles it into an immutable version and registers the App identity. Activate moves the active pointer, is audited, and requires an App owner. Rollback is an activation of a prior version.

finance-close · App configuration
compile → version → activate
# Illustrative App configuration (excerpt). Pyrana Capital is a synthetic portfolio.
app_key: finance-close
version: v14                 # compiled, content-digested: sha256:3f9a71c2…e08b
surfaces:
  monthly-analysis: { path: /close/monthly, reads: [close.summary, variance.report] }
targets:
  monthly_analysis: { publishes: [close.summary, variance.report], doors: [page, copilot, api, mcp, schedule] }
  ledger.journal.post: { doors: [page, copilot, mcp], approval: approval.journal.amount }
agents:
  close-reviewer: { model: provider/model, tools: [ledger.accruals.list, ledger.journal.post] }
workflows:
  monthly-close: { schedule: "0 2 * * 1-5", fan_out: { agent: close-reviewer, per: entity } }
tool_sources:
  ledger: { kind: odbc, binding: erp-finance }
resources:
  close.summary: { versioned: true, stale_publish: refuse }
access:
  profiles: { controller: [read, run, approve] }
  entitlements: { controller: [entity:US-01] }
  approval:
    approval.journal.amount: { when: "amount >= 25000 USD", lane: controller-approval }
knowledge:
  standing_sets: [close-policy, entity-calendars]   # cortIQ, preloaded before the first turn
activation: v14              # one pointer; rollback moves it back

Versions

Activation moves one pointer. Rollback moves it back. The version itself never changes.

Go deeperAgentic Apps6 min
See it working

See it working

Agentic Apps on client processes.

Evaluate the platform

Evaluate the platform

The gate, tool approval policies, and the execution record, and how the platform compares.

Build on it

Build on it

The three product layers, mechanism by mechanism.

05Questions

Frequently asked

Who builds the first application?
Pyrana, third party service providers, or your own team. All three are open today. The first engagement, including single sign-on, access by role, the approval policy and loading your policies into cortIQ, runs about six weeks. With clean data, configuring an application takes about a week; the pages people work in are the main effort.
Who changes a threshold or an approver after go-live?
Your team, by configuration, without a developer. An approval threshold, a named approver, who may see what and which knowledge an agent loads are all part of the application's description. A change is published as a new version, and any version can be switched back in one step.
What support and service levels come with the platform?
Pyrana operates the platform and targets 99.5% uptime under its service level agreement, with support for the platform itself and for the applications Pyrana builds. The full terms are in the service level agreement at pyrana.ai/sla.
How is the platform itself versioned?
Platform releases are deployed to your private tenant or your infrastructure by Pyrana. Each application stays on its own published version, so a platform release does not change an application's description, and each application can be switched or rolled back on its own.
Is Pyrana a framework, a low-code builder, or an application platform?
An agentic application platform, the fourth of the four choices a buyer has (vertical AI tools, extending the suite or copilot, building from frameworks and hyperscaler kits with an internal team or a consultancy, a platform). A framework or kit produces an agent and leaves identity, authorization, and storage for the client to build and maintain. A flow builder produces a flow. Pyrana is a runtime and a system of record: identity, authorization, and audit on every call; durable storage and versioned resources; tool approval policies with named lanes; extensions for client-owned durable backends. An application is one App configuration plus the frontend experience.
Where is the platform deployed, and how does it scale?
Two hosting options: SaaS on a dedicated private tenant, or deployment into the client's own infrastructure for large enterprises. In both, Temporal workers provide durability and horizontal scaling. Separate worker pools handle data fetching, file extraction, and the code interpreter, so a heavy extraction job does not compete with an interactive run.
Does Pyrana need a copy of the client's data?
No. Agents query live through tool sources: ODBC, REST, MCP, Databricks, Snowflake, Google Drive, OneDrive. Tools are specific to the job: the agent passes the entity and the period, the tool holds the query. For cleansing, a code interpreter environment runs deterministic scripts inside the run, or an ETL layer upstream (for example serverless Databricks) exposes a catalog of clean views. A data quality check runs before an agent run starts.
Which models does the platform use?
A model is assigned per agent through provider adapters: Azure OpenAI, OpenAI, Anthropic, Fireworks, Google Gemini, and others. Models are not switched mid-run. The client brings its own keys, and client data never trains external models. Small, medium, and large routing for platform jobs such as summarization keeps cost in proportion to the task.
How are runs evaluated?
Every run's traces, tokens, and tool errors are captured and available as JSON. The eval pipeline runs deterministic checks first (token growth, tool error rates), then an LLM-as-judge stage in Agent Studio.
How long does an application take to stand up?
With clean data available, about a week. The App configuration, the agent configurations, and the tool bindings are configuration on primitives that already exist. The frontend experience is the main effort.
Is there an API?
A full administrative API: push and pull App configuration, start runs, read runs and traces. The same operations are reachable from the CLI, and any agent can work with an App over its MCP server as the user.