Agentic Apps
An Agentic App is a full-stack business application in which people and agents work over the same pages, data, knowledge, and outputs. It is one App configuration on the platform: the surfaces where people work, the targets the App performs, the tool sources it binds, the resources it publishes, the access it grants, and the knowledge it preloads. Every call, from every door, passes one gate under one identity, one authorization model, and one audit record.
00Inside an App
Pyrana runs whole business applications, not just agents: the pages people work in, who they are, what they may see and do, and the agents, data and results behind them. People and agents work over the same pages, data and results, through one gate.
Block 5 on the platform picture, opened up. Unpack it into its seven parts, follow one request from the door to the record, then fold it back into one configuration.
Pyrana runs whole business applications, not just agents: the pages people work in, who they are, what they may see and do, and the agents, data and results behind them. People and agents work over the same pages, data and results, through one gate.
5Inside the block
Pyrana runs whole business applications, not just agents: the pages people work in, who they are, what they may see and do, and the agents, data and results behind them. People and agents work over the same pages, data and results, through one gate.
01Surface, target, door
A surface is a declared page where a person works. The platform knows what the person is looking at and hands it to the agent as exact page context. A target is an operation the App can perform, declared once. A door is how a call arrives: the App's own pages first, then the API, MCP from any agent as the user, a schedule, an external event, and the copilot for auxiliary analysis.
In most stacks each door grows its own authorization check, its own audit shape, and its own bugs. In an App, every door leads to the same gate, the same authorization layers, and the same record. The native runtimes of agents, workflows, tools, and client code are preserved; the contract around them is shared.
Project Portfolio
What is in flight, and how healthy it is.
25 tracked projects
Total projects
25
Value captured
$4.5M
28% of planned
Budget
$5.5M
of $10M planned · $4.7M under
Backlog1
PRJ-0015
Retail media measurement
PM J. Amara
Charter1
PRJ-0012
Supplier risk scoring
PM N. Bakhtiari
Execution2
PRJ-0006
ERP integration hardening
PM M. Oyelaran
PRJ-0007
Field service scheduling
PM H. Baptiste
Value realization1
PRJ-0018
Contract lifecycle rollout
PM C. Vandermeer
The project portfolio App. A manager drags a card, the copilot moves one on request, and a nightly workflow promotes idle projects: the same target, the same gate, three identities in the record. Illustrative.
02One target, five doors
The same target is called five ways. Each caller passes the same gate, the same authorization layers, and the same approval policy, and lands in the same audit shape. Only the identity changes. A workflow that hits an approval threshold waits for a person, as a page or a copilot call would.
A project manager drags ATLAS from Staging to Production.
user:pm.sato SSO · profile:release.manager
03The App configuration
Everything the configuration names already exists in the platform. Agent configuration is plain language. Workflows are declarative.
Declared pages where people work. A surface reads resources at exact versions and hands the agent the page context: page, entity, period, resource versions.
Operations the App performs: agents, workflows, and direct operations. Declared once, reachable from every door, through one gate.
REST, ODBC, MCP and MCP gateways, Databricks, Snowflake, Drive, OneDrive. Bound per agent and scoped to the job. Each call authorized and audited.
The outputs the App publishes: versioned, immutable, attributed. A stale publish is refused. Pages read an exact version.
Access profiles (read, run, approve), scope entitlements on entities, projects, and review queues, and approval lanes for consequential actions.
Standing sets of Context Units that preload before the first turn, and context search the agent calls mid-run.
04Lifecycle
Push compiles the App configuration into an immutable version and registers the App identity; it does not activate. The compiler resolves every referenced agent, workflow, tool source, and extension to an exact identity or digest and checks that every surface maps to a declared target. Activate moves the active pointer, is audited, and requires an App owner. Rollback is an activation of a prior version. Deploy ships a frontend image and registers and activates nothing.
# 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 backVersions
Activation moves one pointer. Rollback moves it back. The version itself never changes.
# illustrative extension manifest (excerpt)
extension: it-pm
digest: sha256:b71d…4c02
protocol: 1
routes:
- { method: POST, path: /projects/{id}/stage, operation: project.stage.transition,
capabilities: [project.write], effects: [materialize, audit, tool_source.invoke] }
mcp_tools:
- { name: project_change_stage, operation: project.stage.transition }
outbound:
- { tool_source: clover, operation: projects.sync } # platform-held credential
migrations: { required: 7, applied: 7 }06Extensions
Configuration composes a great deal from shared primitives. It does not replace a client's domain model. An extension is a client-owned durable backend service deployed in the same cluster, built with the platform library that handles authentication and authorization up front. It is not publicly accessible and is reachable only through the platform. It publishes a content-digested manifest, receives a short-lived delegated token on every call, runs its own transaction, and returns typed effects. Outbound actions are performed by the platform with platform-held credentials.
Two examples in production: a project portfolio tracker with custom business logic and its own durable storage, and a governed browser capability that logs into SaaS tools without an API and captures control evidence.
Go deeperHow it works, step 01: the App configuration2 min07Personal pages
The copilot is auxiliary to the App's pages: it answers questions about what is on screen, and it is the pathway to personalization. A person asks it for a page. The copilot inspects the rendering contract and the resources and read capabilities the person may use, authors the page, and the backend compiles it: no network, no imports, no storage, no authority. The compiled page is saved as an immutable, parent-linked revision, and the browser renders it with every read still authorized.
Personal pages are read-only by default. App-wide publication of a generated page is a privileged path, reserved for App owners.
Materials cost, PMW vs MWM
Last six months, with the commentary underneath. Private to J. Okafor.
PMW · materials cost
USD thousands
MWM · materials cost
USD thousands
Commentary
read from monthly_pack at exact versions · PMW v4 · MWM v2
PMW's purchase price variance breached in March and April and has since eased. MWM tracks plan. Every read on this page passes the same authorization as the App's own pages; the page can show nothing its owner could not see elsewhere.
Illustrative. Pyrana Capital is a synthetic portfolio.
08Three scenarios
An analyst on the Monthly Analysis surface asks the copilot for the June narrative. The copilot cites the resource at its exact version, v1, published by the agent run. She asks for a revision and approves it; it publishes as v2, attributed to the copilot on her behalf. A workflow rerun that started earlier tries to publish against v1 and is refused. Nothing is overwritten.
An analyst entitled to one operating company asks the same copilot for the group roll-up. Listings show the entitled entity only. A direct request resolves as not found. Nothing in the response reveals that the roll-up exists.
The reconciliation workflow finds an intercompany mismatch between PMW and MWM and proposes an adjusting entry above threshold. The invocation freezes and queues in the intercompany lane. The PMW approver can act. The MWM approver sees the request but cannot act, because approving is a separate entitlement from reading. Until the PMW approver decides, the entry is queued, visibly different from a posted entry, and nothing is posted.
Illustrative. Pyrana Capital is a synthetic portfolio.
09Questions
With clean data available, the frontend experience is the main effort.