Platform

The platform stack, built once.

An agentic application is a full-stack business application in which people and agents work over the same pages, data, knowledge, and outputs, under one identity, one authorization model, and one audit record. The platform is built once. An application is configuration on top of it.

Exec read 3 min Full read 9 min

the stack

seven layers, shared by every application

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

Under all of itidentityauthorizationauditone execution record per call

00The short version

Built once. Configured per application.
Ships asone App documentimmutable versionactive pointer
Every door, one gate.
DoorspagescopilotAPIMCPscheduleexternal event
Identity, authorization, audit, context: shared by every application.
Shared viaaccess layersone execution recordcortIQ Context Units

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

Statusone gate per invocationauthorization in layersaudit before execution

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

Surfaces, targets, one gate, versioned resources.

One App document compiled into an immutable version; activation moves one pointer, rollback moves it back
Declared surfaces hand exact page context to the agent; targets are reachable from every door through one gate
Client-owned extensions run as durable backend services in the same cluster, reachable only through the platform

LiveAgentic Apps

Pyrana Harness

Runtime, orchestration, fan-out, approval lanes.

Native tool calling, planning, subagents, checkpoints, and resume; a model assigned per agent
Durable workflows fan out to specialized agents per entity and group; every output publishes back to the App
Tool approval policies: thresholds and named lanes, frozen invocations, revalidation, dispatch once

LivePyrana Harness

cortIQ

Typed, classified, evidence-backed context.

Documents become Context Units: a claim, its evidence with source and location, a knowledge type, a classification, a content-hash identity
Three retrieval modes, knowledge, facts, and search, with standing sets preloaded before the first turn
Every unit is accounted for per run: retrieved, injected, cited

LivecortIQ

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 document. One immutable version.

A client authors one App document: surfaces, targets, agents, workflows, tool sources, resources, access, knowledge. Everything the document 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 definition

compile → version → activate

# Illustrative App document (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

05Roadmap

What is live, what is built, what is next.

Pyrana publishes this table and dates it. Live and built capabilities are described in the present tense. Items in development, designed, or vision are labeled as roadmap here and on every other page. Table as of 10 September 2026.

Live and built

App definition, compiler, immutable versions, push, activate, rollbackLive
Authorization in layers: tenant, App membership, access profiles, scope entitlements, OpenFGALive
One gate per invocation: eight steps, fail-closed, execution row and audit record before dispatchBuilt
Declared surfaces and page context handed to the agentLive
Versioned, attributed resources; stale publish refusedLive
Personal pages authored by the copilot, compiled and governed, read-onlyBuilt
Extensions: client-owned durable backend services in the same cluster, platform-handled auth, delegated tokens, typed effectsLive
App MCP and CLI: any agent works with the App as the userLive
Agents belong to Apps and inherit the App's rulesLive
Agent Studio: authoring agent configuration within platform guardrailsBuilt
Direct, agent, workflow, batch, and event lanesLive
Workflow fan-out to specialized agents per entity and group; outputs publish backLive
Tool approval policies: thresholds, frozen invocations, named approval lanes, revalidationBuilt
Durable execution on Temporal workers: checkpoint, suspend, resume; horizontal scalingLive
Code interpreter environment with deterministic scripts for data shapingLive
Model assigned per agent through provider adapters; no mid-run switchingLive
cortIQ: extraction, curation, knowledge graph, typed and classified Context Units, content-hash identityLive
Retrieval modes (knowledge, facts, search) with engine-side query and learning agentsLive
Retrieved / injected / cited accounting per runLive
Curation loop: propose, gate by classification, supersede under compare-and-set, score from useLive
SSO (Entra ID, OAuth), tenant isolation with row-level security, per-agent identityLive
SOC 2 aligned audit and telemetry; audit event written before executionLive
Two hosting options: SaaS on a dedicated private tenant, or deployment into the client's own infrastructureLive
Tool sources: REST, ODBC, MCP and MCP gateways, Databricks, Snowflake, Drive, OneDrive; scoped bindings per agentLive
Administrative API: push and pull configuration, start runs, read runs and tracesLive
Model agnostic; bring your own keys; data never trains external modelsLive
Page context tokens (frontend)Live

Roadmap

Small, medium, large model routing for platform jobsDesigned
Eval pipeline: deterministic run checks, then LLM-as-judge in Agent StudioRun traces, tokens, and tool errors are captured todayIn development
Feedback lanes from chat, frontend, and evals into curationIn development
Business knowledge plugins: entity-agnostic domain context (accounting standards, industry rules)Vision
User principal passed through to data platforms (Snowflake, Databricks row-level security)In development
Pre-run data quality check before an agent run startsIn development
Publication, provenance, and legal hold on resourcesIn development
Agent-compiled client frontendsVision
Personal history with opt-in sharingVision

Capability table as of 10 September 2026.

Sourcecapabilities.tsdated 10 September 2026

See it working

Agentic Apps on client processes.

Evaluate the platform

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

Build on it

The three product layers, mechanism by mechanism.

06Questions

Frequently asked

Is Pyrana a framework, a low-code builder, or an application platform?

An application platform. A framework 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 document 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 that runs before an agent run starts is in development.

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 is designed, not yet built.

How are runs evaluated?

Every run's traces, tokens, and tool errors are captured and available as JSON today. The eval pipeline in development 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 document, 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.

How does Pyrana describe what is live and what is not?

Pyrana publishes the capability table on this page, dates it, and keeps it current. Live and built capabilities are described in the present tense. Anything in development, designed, or vision is labeled as roadmap here and on every other page.

See an application admitted, run, and recorded.

One App document, every door, one execution record.

Book a demo How it works