The agentic application

Three kinds of product carry the label agentic AI. A framework, a vertical application, and a platform. They differ in what the enterprise receives and in what it still has to build and maintain.

A framework produces an agent. The model, the prompt, the tool loop, and a chat window arrive working. Security, authorization, and storage do not. Each team that adopts the framework builds those pieces to its own standard, and the enterprise maintains one copy per team as the number of agents grows.

A vertical application solves one job. It brings its own identity, its own permission model, and its own data store. It shares nothing with the application next to it. An enterprise that buys twelve of them runs twelve identity models, twelve permission models, and twelve audit trails, and reconciles them itself. CIOs do not want twelve of them.

A platform builds identity, authorization, storage, orchestration, approvals, and audit once. Every application composes on that layer, and people stay inside the loop for the decisions that need a person.

Agents are generic. The same runtime, the same tool loop, and the same approval mechanism serve finance, procurement, IT, and compliance. What differs between verticals is configuration: which operations exist, which systems they bind to, who may run them, and what knowledge they read. The platform gives an enterprise those raw pieces, configurable per application, with people in the loop. Pyrana is built for two buyers in one product: the one who has to satisfy security and the one who has to get value from the application.

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.

Seven layers make up the platform, and every application shares all seven. The harness is the agent runtime: native tool calling, planning, subagents, checkpoints, and resume. The orchestration layer runs durable workflows that fan out, wait, retry, and finish, on a schedule or on demand. Tools and tool sources connect to data and systems: REST APIs, ODBC, MCP servers and gateways, and client extensions; each call is authorized on its own. Tool approval policies queue consequential actions for the right people before they execute, with thresholds and named lanes rather than a single allow-or-ask switch. Durable storage holds versioned resources, artifacts, and the context engine's curated knowledge. The context engine, cortIQ, holds company knowledge as typed, classified, evidence-backed Context Units in a knowledge graph. The frontend surface layer is the App shell, the declared pages, the copilot, and the pages people generate for themselves.

Under all seven: identity, authorization, and audit. A tenant boundary that no call crosses, fine-grained access decided on the backend, and one execution record per call.

A client authors two things. The first is one App document: configuration that names the application's targets, surfaces, resources, agents, workflows, tool bindings, access profiles, and approval policies. The second is the frontend experience. Everything the document names already exists in the platform. The document binds those pieces into one application; it does not implement them. With clean data available, an application typically takes about a week to stand up, and the frontend experience is the main effort.

A surface is a declared page where a person works. Because the page is declared, the platform knows what the person is looking at: the entity, the period, the resource version on screen. When the person asks the copilot a question or starts an operation from that page, the page context travels with the call as exact context, not as a description the person has to type.

A target is an operation the App can perform. It is declared once in the App document, with its inputs, the resources it reads, and the resources it publishes. A target is reachable from many doors. A door is the way a call arrives: the App's own pages, the copilot, the API, MCP from any agent acting as the user, a schedule, or an external event. The target is the same operation regardless of the door.

Illustrative. Pyrana Capital is a synthetic portfolio: nine operating companies in three groups under one holding company. Its Monthly Analysis surface reads about sixteen resource types. Its monthly_analysis target publishes about nineteen. A controller opens the surface for one operating company and one month. The copilot receives that company and that month as page context. The monthly_analysis target, started from a schedule at month end or from the page on demand, runs the same code path either way.

Every door leads to the same gate.

Admission is the check every call passes before anything runs. It has eight steps, in order. First, identity and an idempotency key: who is calling and which request this is. Second, the active App version: the call binds to one immutable version. Third, the target exists in that version and the caller is allowed to reach it. Fourth, page and resource references resolve to exact versions. Fifth, one authorization check: App membership, access profile, and scope entitlement on the entity the call touches. Sixth, the idempotency key is claimed and the execution row and the audit record are written in one transaction. Seventh, dispatch to the native host. Eighth, the outcome is recorded against the same row.

The gate fails closed. A step that cannot be satisfied stops the call. Anything the caller is not authorized to see reads as absent, not as denied, so a refusal never discloses that a record exists.

One desk serves a page, a schedule, an agent, a workflow, and an external system. A person via SSO, a service via OAuth client credentials, an agent acting for a person via a delegated token, and a workflow as a service principal each keep their real identity through the gate. Identity is explicit: an agent with its own identity, an agent on behalf of a user, and a workflow as a service principal take the same authorization path and leave the same shape of record.

Tool approval policies handle consequential actions inside the gate. A policy over typed arguments decides which invocations need a person: an amount above a threshold, a vendor outside the approved set, an account that does not yet exist, or a combination. When an invocation trips the policy, the platform freezes it: the operation, the exact arguments, the scope, and the evidence the agent used, under a hash. The frozen invocation is queued to a named approval lane. Reviewer eligibility is checked at decision time rather than at request time. The frozen invocation is revalidated against current state before dispatch. Dispatch is idempotent, so a retry reuses the receipt. Illustrative. Pyrana Capital is a synthetic portfolio; the entry below is a reconciliation adjustment queued for the pmw-approvers lane.

A workflow is a durable process that dispatches many specialized agents, per entity and per group, in parallel, waits for them, and finishes. Each agent pulls only what its job needs through the tools it was given. Each reads what its siblings and prior runs published. Everything publishes back to the App as versioned resources.

Illustrative. Pyrana Capital is a synthetic portfolio. One June monthly run: the workflow starts at month end and fans out one analysis agent per operating company, one per group, and one for the holding company. Company agents fetch trial balances and operating metrics through tools bound to the source systems. Group agents read the company resources their siblings published. The holding agent reads the group resources. The run finishes with 45 agent executions and 36 published references, each with its own execution record. One reconciliation adjusting entry exceeded the approval threshold and was queued for the pmw-approvers lane; the rest of the run did not wait for it.

Agents do not write free-form queries. Tools are specific to the job: the tool holds the query, and the agent supplies the entity and the period. Every call is admitted and audited. Tool policies map a caller's scope entitlement to tool arguments before the call is made.

The workflow runs on Temporal workers, so a run that waits for an approval survives a restart or a deploy and resumes where it stopped. Separate worker pools handle data fetching, file extraction, and the code interpreter, which runs deterministic scripts for data shaping. A model is assigned per agent through provider adapters (Azure OpenAI, OpenAI, Anthropic, Fireworks, Google Gemini, and others) and does not change mid-run.

The context engine, cortIQ, holds company knowledge as Context Units. A Context Unit is a claim, its evidence passage with source and location, a knowledge type, a classification, an evidence grade, a quality score, and an identity that is a content hash of the claim and its evidence. Two units with the same claim and the same evidence are the same unit, wherever they are stored.

The knowledge type says what kind of claim it is. Axiomatic: true by definition. Empirical: observed and measured. Prescribed: a rule a person or body set. Procedural: how something is done.

The classification says how the unit may change. Absolute never changes automatically. Regulated needs a person. Contextual applies within a stated scope. Tribal is conflict-checked against other units before it is applied. Derived updates itself when what it is derived from changes.

Units link in a graph with three relations: refines, describes, same set. A set is a scoped collection of units, and standing sets for an application preload before an agent's first turn, so policy context is present before the agent reads anything else.

Illustrative. Pyrana Capital is a synthetic portfolio. Its delegation-of-authority policy yields the unit "Adjusting entries above 25,000 USD require controller approval": prescribed, regulated, with the policy section as evidence. The approval policy in section 04 and the agent that prepared the entry read the same unit.

The engine offers three retrieval modes. Knowledge is a set-anchored graph walk, fused and weighted by quality score. Facts is the same walk restricted to units flagged as facts. Search is semantic search over source passages. An agent's configuration says which modes it may use.

Standing sets preload before the first turn. Mid-run, an agent calls context search, pauses, retrieves, and resumes. The copilot's chat uses the same path, so a person and a workflow agent asking the same question of the same application receive the same units.

Agents work on the engine side as well. A query agent plans the graph walk and repairs its own queries when a walk returns nothing useful. A learning agent scores what was retrieved and what was used, and flags units that never help for human review. Nothing is deleted automatically.

Every unit is accounted for per run in three counts: retrieved, injected into the prompt, and cited in the output. The sets nest. A reviewer walks from a sentence in the output to the unit that supports it to the passage in the source, and sees whether a newer unit supersedes it. Because a unit's identity is a content hash, the exact business context used in any run is provable after the fact.

Company knowledge changes: a policy is revised, a close calendar moves, a threshold is raised. The engine handles change through a curation loop with four steps.

Propose. A change can come from a document, a connector, an agent, or a person. Gate. The unit's classification decides what happens next: absolute is refused, regulated waits for a person, tribal is conflict-checked, derived and contextual proceed. Apply. The change is applied under compare-and-set: the new unit supersedes the old one and carries the old one's hash. The old unit is not overwritten. A run that cited it still cites the exact unit it used. Observe. The learning agent scores the new unit from use, and that score feeds the next retrieval.

Feedback enters the loop from chat and from evals today; frontend feedback lanes that route a person's correction into curation are in development. Who owns which sets at scale is a process Pyrana is still defining with clients.

A resource is a versioned, immutable, attributed output. Version 1 of a monthly analysis is published by an agent run. Version 3 is revised by the copilot on behalf of a person, and the record says so. Publishing against a stale version is refused, never merged and never overwritten. A page reads a resource at an exact version, so two people looking at the same page see the same thing.

A personal page is a surface a person asks for. The person describes the page to the copilot. The copilot inspects the rendering contract and the resources and read capabilities the person may use, and authors the page. The backend compiles it with no network, no imports, no storage, and no authority of its own, saves it as an immutable revision linked to its parent, and the browser renders it with every read still authorized on the backend. Personal pages are read-only today. Publishing a personal page App-wide is a later, privileged path.

Access is decided in layers, all on the backend; the page only reflects the result. The tenant is a hard boundary. App membership says who may enter the application. An access profile says what a member may do: read, run, approve. A scope entitlement says on which entity, project, or review queue. Approval lanes route consequential actions to a named group. Reading a record and approving a change are two different permissions, and a person who holds one does not hold the other by default.

An application moves through three operations. Push compiles the App document into an immutable version with a content digest and registers the App identity; it does not activate anything. Activate moves the active pointer to one version; it is audited and requires an App owner. Rollback is an activation of a prior version. Deploy ships a frontend image; it registers and activates nothing. The version that ran on a given day is the version that was reviewed, and the digest proves it.

Extensions carry the client's own logic. An extension is a client-owned durable backend service deployed in the same cluster, built with the platform library that handles authentication and authorization before the client's code runs. It is not publicly accessible and is reachable only through the platform. One production example is a project portfolio tracker with its own business logic and durable storage. Another is a governed browser capability that logs into SaaS tools without an API and captures control evidence.

The platform is offered two ways: 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. Customer data stays in the client's cloud and is never used to train external models. A full administrative API pushes and pulls configuration, starts runs, and reads runs and traces; every run's traces, tokens, and tool errors are available as JSON.

Pyrana publishes what is live and what is not, so the client can plan against it.

Live: App definition, compiler, immutable versions, push, activate, and rollback. Authorization in layers with OpenFGA. Declared surfaces and page context. Versioned, attributed resources with stale-publish refusal. Extensions as durable backend services. App MCP and CLI. Direct, agent, workflow, batch, and event lanes with fan-out. Durable execution on Temporal. The code interpreter. A model per agent. cortIQ with typed and classified Context Units, the three retrieval modes, engine-side query and learning agents, per-run accounting, and the curation loop. SSO, tenant isolation, SOC 2 aligned audit, tool sources, and the administrative API.

Built, enabled per App or per installation: the eight-step gate. Tool approval policies with frozen invocations and named lanes. Personal pages in read-only mode. Agent Studio for authoring agent configuration within platform guardrails.

Roadmap, in development: user principal passed through to data platforms such as Snowflake and Databricks row-level security. A pre-run data quality check. The eval pipeline, deterministic checks first, then LLM-as-judge in Agent Studio. Feedback lanes from the frontend into curation. Publication, provenance, and legal hold on resources. Roadmap, designed: small, medium, and large model routing for platform jobs. App-wide publication of generated pages. Roadmap, vision: business knowledge plugins as entity-agnostic domain context. Agent-compiled client frontends. Personal history with opt-in sharing.

Everything on the roadmap depends on the identity, authorization, audit, and context that are already there. The platform is built once. Each application is configuration on top of it.