Enterprise agentic application platform

Agentic applications, not agents.

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.

Harness
Orchestration
Tool sources
Approval policies
Durable storage
Context engine
Surfaces

Book a demo How it works

Pyrana Capital Finance / Monthly analysis / PMW · June 2026

Entities

PMW

MWM

GLH

TSS

APL

PMW · June 2026

Monthly pack · published v2 by the copilot on behalf of J. Okafor

Published v2Add to chat

Revenue

$12.4M

-$2.5M year over year

Materials

-$188K

PPV breach, Mar and Apr

Labor

31.2%

of revenue · plan 30.0%

Findings

1 needs approval

Executive summary

Revenue · Materials · Labor agents, rolled up

Revenue is down 2.47M year over year, led by Greenfield Agriculture, which fell 37.5K month over month. Materials carry a 188K unfavorable purchase price variance concentrated in March and April. Labor at 31.2% of revenue sits above plan. The top five accounts are 45% of revenue this year, below the 60% concentration threshold, so no qualifying window applies. cxu 1220…f843

Revenue by month

USD millions, 2026

JanFebMarAprMayJun

The monthly run published the pack. The controller asks the copilot about one account and revises the summary in place.

Illustrative. Pyrana Capital is a synthetic portfolio.

Runs ina dedicated private tenant (SaaS)or the client's own infrastructurethe client's model keysthe client's identity provider

01One monthly run

Tuesday, 7:40 a.m. The close App has already run.

At 2:00 a.m. a schedule admitted the finance close App at version 14. The monthly-close workflow fanned out to specialized agents, one per entity. Each reconciled intercompany balances, flagged variances, and drafted commentary through the tools it was given. The App posted 212 entries inside its authority. One adjustment exceeded the approval threshold, so the call was frozen and queued to the controller-approval lane.

The controller works in the App's own pages: the review queue shows what the policy routed to her, with the evidence attached. She approves two items and returns one with a note. The copilot sits beside the page for auxiliary analysis, a question about one account, and for personal pages; it is not the primary interface. The audit record holds who asked, what ran, which policy fired, which Context Units were cited, and who approved, for every call.

DoorsscheduleApp pagecopilot

Approvals1 person0 bypasses

Go deeperFinancial close and review2 min

Reconciliation / Approval queue

Review

Approve, return, or edit what the policy routed to you.

Role: Reviewer

Journal entry · PMW intercompany adjustment

38,400 USD · proposed by the reconciliation workflow

6 of 6 policy checks passlane pmw-approvers

ApproveReturn

Accrual reversal · MWM materials

12,900 USD · proposed by the close workflow

6 of 6 policy checks passlane mwm-approvers

Approved · posted once

Journal entry · GLH freight reclass

4,150 USD · proposed by the close workflow

5 of 6 checks pass · missing supportlane glh-approvers

Returned with a note

A queued request is visibly different from a posted entry. Nothing here has run.

Illustrative. Pyrana Capital is a synthetic portfolio.

02The problem

Pilots are easy. Production is the problem.

Enterprises can buy three things today. A framework: an agent, with security, authorization, and storage still to build and to maintain as agents multiply. Vertical applications: each solves one job and brings its own identity, permissions, and data, with nothing between them. A platform: identity, authorization, storage, orchestration, approvals, and audit built once, with every application composed on it and people inside the loop.

The first two are what is usually demoed. The demo is the part above the waterline.

0%+

of agentic AI projects will be canceled by the end of 2027, citing cost, unclear value, and inadequate risk controls

SourceGartner, June 2025

of enterprise AI agents operate in isolation: no shared data, no coordination, no handoffs

SourceSalesforce, 2026

of organizations have a mature governance model for agentic AI

SourceDeloitte, April 2026

the agent, as demoed

what is below the line

a model
a prompt
a few tools
a chat window

identity, authorization, and audit shared by people and agents
tenant boundary with fine-grained access
durable workflows that fan out, wait, retry, and finish
tool approval policies with named lanes
idempotency on every external effect
audit record written before dispatch
versioned resources; stale publish refused
immutable App versions with activation and rollback

Security-critical, expensive, and in a framework build, still the enterprise's to build and maintain.

03The platform

Built once. Configured per application.

Seven layers on one foundation of identity, authorization, and audit: the harness, the orchestration layer, tool sources, tool approval policies, durable storage, the context engine, and the surface layer. Every application shares them. An App is one configuration, the App configuration, that names what already exists: its surfaces, targets, agents, workflows, tool sources, resources, access, and knowledge.

Every call, from any door, passes one gate: eight steps, fail closed, the execution row and audit record written before dispatch. Unauthorized things read as absent, not denied.

the gate

eight steps · fail closed · audited before dispatch

Agentic Apps

Surfaces, targets, one gate, versioned resources.

One App configuration 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

Agentic 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

Pyrana Harness

cortIQ

Typed, classified, evidence-backed context.

Documents and tacit knowledge 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

cortIQ

Go deeperPlatform overview3 min

04What changes

Faster. Safer. Compounding.

Faster

An application is one App configuration on a platform that already exists. With clean data available, a first application typically stands up in about a week, and the frontend experience is the main effort. The foundational engineering is already done and lives in the platform, so the team's effort goes to the solution and time to value is measured in weeks, not quarters.

Ships asApp configurationcompiled versionone activation pointer

Safer

Identity, authorization, and audit are built once and applied to every call, whether a person or an agent makes it, through every door. Consequential actions queue for the right people before they execute.

Enforced byaccess profilesscope entitlementsapproval lanesaudit before dispatch

Compounding

Knowledge, rules, and published resources are shared across applications. Each new App starts with the context engine, the authorization model, and the extensions the previous ones already use.

Shared viacortIQ Context Unitsversioned resourcesextensions

0 to 25%

EBITA gains from scaling agentic and single-task AI

SourceBain, 2025

0 to 50%

acceleration in business processes

SourceBCG, 2025

0 to 80%

lower cost per transaction in labor-heavy processes

SourceMcKinsey, 2025

05Speed to value

The basics are already built. Value arrives sooner.

The enterprise-ready engineering every application needs is done and lives in the platform: identity, authorization, audit, durable storage, orchestration, approval policies, and the context engine. None of it is rebuilt per application, so a team's work goes to the process, the pages, and the knowledge, and the time from decision to a governed application in production is measured in weeks.

About a week: to stand up the App configuration, with clean data available
About six weeks: from decision to a first App in production with real identities and approvals; confirmed per engagement
Less each time: for every App after: the basics are inherited, never redone

Already in the platform

Identity: SSO, per-agent identity, actor chains
Authorization in layers: tenant, App membership, access profiles, scope entitlements
The gate: eight steps, fail closed, audit before dispatch
Tool approval policies with named lanes
Durable execution and orchestration: lanes, fan-out, checkpoint and resume
Tool sources: REST, ODBC, MCP, warehouses, drives
Versioned resources and durable storage
The context engine: typed, classified, cited knowledge
Extensions for client-owned durable backends
Hosting, scaling, audit and telemetry

What a team builds

01The App configuration: surfaces, targets, agents, workflows, tool sources, access, knowledge
02The approval policy for this process: thresholds, lanes, who decides
03The knowledge to load: policies, procedures, the walkthrough of how work is really done
04The frontend experience: the pages people work in

The frontend experience is the main effort. Everything below it already exists.

Same platform, any application

Month-end close

Pages: month overview, reconciliation, approvals
Agents: an analyst per entity, a reconciliation agent
Access: each controller sees their own entity

Risk register

Pages: register, review queue, board pack
Agents: status outlook, proposals, pack assembly
Access: risk owners edit their own risks

Store operations

Pages: portfolio, store board, daily brief
Agents: a store analyst, a brief writer
Access: a manager sees their own store

One App, the full stack: everything behind the pages comes from the platform.

Go deeperThe platform picture3 min

06Three ways to buy

What enterprises can buy today is not what they want.

	A framework LangChain, CrewAI, agent builders	Vertical applications One product per function	Pyrana A platform Pyrana
First application	An agent in days. Security, authorization, storage, and audit are still to be built before production.	Fastest. The vendor delivers a finished product for one job.	One App configuration on identity, authorization, and audit that already exist. About a week with clean data available.
Every application after the first	The same plumbing rebuilt or maintained per agent, as agents multiply.	Another product, another identity model, another data store. Nothing between them.	Another App configuration on the same identity, authorization, audit, storage, and context. The basics are never redone.
Security, authorization, storage	The enterprise's to build and to keep secure. Security reviews custom code.	Each vendor's own, on the vendor's terms. Reconciled after the fact.	Built once. One gate on every call, approvals as policy, versioned storage.
Knowledge and context	Per-agent memory. Knowledge shared across agents is another build.	Held inside each product. Re-onboarded for every vendor.	The context engine, shared and cited across every application, scored from use.
Who is in the loop	Whatever the team wires in, per agent.	The vendor's workflow, inside the vendor's screens.	People and agents on the same pages and resources. Consequential actions route to named lanes before they execute.

First application

PyranaA platform: One App configuration on identity, authorization, and audit that already exist. About a week with clean data available.
A framework: An agent in days. Security, authorization, storage, and audit are still to be built before production.
Vertical applications: Fastest. The vendor delivers a finished product for one job.

Every application after the first

PyranaA platform: Another App configuration on the same identity, authorization, audit, storage, and context. The basics are never redone.
A framework: The same plumbing rebuilt or maintained per agent, as agents multiply.
Vertical applications: Another product, another identity model, another data store. Nothing between them.

Security, authorization, storage

PyranaA platform: Built once. One gate on every call, approvals as policy, versioned storage.
A framework: The enterprise's to build and to keep secure. Security reviews custom code.
Vertical applications: Each vendor's own, on the vendor's terms. Reconciled after the fact.

Knowledge and context

PyranaA platform: The context engine, shared and cited across every application, scored from use.
A framework: Per-agent memory. Knowledge shared across agents is another build.
Vertical applications: Held inside each product. Re-onboarded for every vendor.

Who is in the loop

PyranaA platform: People and agents on the same pages and resources. Consequential actions route to named lanes before they execute.
A framework: Whatever the team wires in, per agent.
Vertical applications: The vendor's workflow, inside the vendor's screens.

Go deeperWhy Pyrana4 min

For engineers and architects7 min

07Under the hood

How one call moves through an App.

A person acts on a page. The call passes one gate. The lane the policy names decides, the entry posts once, and one execution record holds the whole story. The same three moves apply to a call from the copilot, the API, another agent over MCP, or a schedule.

A person acts in the App

Reconciliation · PMW · June 2026page

Proposed adjusting entry

Intercompany PMW / MWM · 38,400 USD

Duplicate posting found by the reconciliation workflow

Submit for postingEvidence

On the App's own page. The same target is reachable from the copilot, the API, MCP, or a schedule, and takes the same path.

The gate checks the call

Gate · journal.post_adjusting_entryexec_01J9…

Identityj.okafor · SSO
App versionfinance@v14 · active
Authorizedcontroller · entity PMW
Recordwritten before dispatch
Approvalabove 25,000 USD → lane pmw-approvers

Eight steps, fail closed: who is calling, which App version, is it allowed, does policy require a person. The record is written before anything runs.

Approved, then recorded

Execution recordposted once

Approved byK. Osei · pmw-approvers · 09:14
Policyapproval.journal.amount @v7
EffectJE-88213 · receipt kept
Publishedrecon_summary v2 · 2 units cited

The lane the policy names decides. The entry posts once. One execution record holds who asked, what ran, which policy fired, and who approved.

Illustrative. Pyrana Capital is a synthetic portfolio.

One App configuration. One immutable version.

An App is one configuration compiled into an immutable, content-digested version. Push compiles and registers the App identity. Activate moves one pointer, is audited, and requires an App owner. Rollback is an activation of a prior version. Which version ran is always exact.

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 deeperHow it works, all nine steps15 min

08Where to go next

Where to go next.

Business functions

Applications in use

Examples: finance close, procurement, IT project management. Any process with rules runs the same way.

AI, data, and IT

The platform

What is enforced where, how authorization, approval, and audit work, and how the platform compares with a framework or a vertical application.

Engineering

The mechanisms

The gate, lanes, approval policies, extensions, versioned resources, and cortIQ provenance, one mechanism at a time.

Pathssolutionsplatformsecurityhow it worksharnesscortIQ

09Questions

Frequently asked

What is an agentic application?

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. On Pyrana the platform is built once; an application is one App configuration (configuration) plus its frontend experience. Agents are a mechanism inside the application, dispatched by its workflows and bound to its tools, not a separate product.

How portable is an application, and what is the lock-in?

An application is one YAML document plus the agents, workflows, and tool sources it binds. Agent configuration is plain language. Workflows are declarative. Context Units are the client's data and can be exported. Tools built for the platform can in many cases be called from outside it. There is no industry-standard interchange format, so there is no export button; translating an App to another runtime is a reading exercise, not a rebuild. The platform runs in the client's own cloud subscription.

How is Pyrana different from a low-code builder such as n8n, Flowise, or Copilot Studio?

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; and extensions for custom durable backends, such as a project portfolio tracker with its own business logic or a governed browser capability for SaaS compliance checks. Outputs can be delivered to any deployment target the client accepts: Drive, OneDrive, or a system of record.

What does the gate do before a call runs?

Every call into an App, from its own pages, the copilot, the API, another agent over MCP, a schedule, or an external event, passes the same eight steps: identity and idempotency key; active App version; target exists and caller allowed; page and resource references resolved to exact versions; one authorization check on membership, profile, and entitlement; 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.

Does Pyrana replace existing systems?

No. Pyrana does not need to store source data. Agents query live through tool sources: ODBC, REST, MCP, Databricks, Snowflake, Google Drive, OneDrive. Each call is authorized. Custom business logic runs as an extension, a client-owned durable backend service in the same cluster, built with the platform library and reachable only through the platform.

Which models can an application use?

A model is assigned per agent through provider adapters for Azure OpenAI, OpenAI, Anthropic, Fireworks, Google Gemini, and others, with the client's own keys. Models are not switched mid-run. Company knowledge lives in the context engine rather than in model weights, so an application can change models without changing its document. Small, medium, and large routing for platform jobs such as summarization keeps cost in proportion to the task.

How is it deployed, and how does it scale?

Pyrana is 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.

Who can see the data?

The platform runs on a dedicated private tenant, or in the client's own infrastructure. Client data is never used to train external models. The tenant is a hard boundary enforced with row-level security. All authorization is decided on the backend; nothing unauthorized reaches the frontend, and anything a caller may not see is absent from results rather than shown as denied.

How is Pyrana different from LangChain, CrewAI, or an agent builder?

A framework produces an agent. Security, authorization, storage, approvals, and audit are still the enterprise's to build, and to maintain as agents multiply. Pyrana builds that layer once. Every application composes on it as configuration, with people inside the loop. Teams build the solution, not the basics, and value arrives sooner.

The platform is built once. The application is configuration.

Identity, authorization, audit, and context exist before the first application and are shared by every one after it. Value arrives in weeks, not quarters.

Book a demo How it works