Skip to content
Pyrana

Pyrana Harness

Specialists in one governed loop, on a durable runtime.

The Pyrana Harness is the agent runtime and the orchestration layer: native tool calling, planning, subagents, checkpoints, and resume, on durable workflows that fan out, wait, retry, and finish, scheduled or on demand. Every child call re-enters the gate. Every lane produces one execution record.

one governed loop
admit → plan → act → observe → validate → publish
  1. Admit01

    identity resolved, idempotency claimed, audit written

  2. Plan02

    explicit steps, written through tools, not hidden state

  3. Act03

    tools, subagents, extensions with delegated tokens

  4. Observe04

    checkpoint; suspend for a person or an external result

    paused · awaiting approval
  5. Validate05

    declared finish conditions: required artifacts, packet schemas

  6. Publish06

    receipts, effects, versioned resources, one causal trace

Lanesdirectagentworkflowbatchevent

00Inside an agent

Agents: specialists that work inside the Pyrana Harness.

Every agent runs the same governed loop. Configuration decides what it knows, what it may use and when it is done.

Block 3 on the platform picture, opened up. Unpack it into what an agent is given, what it may use and what it leaves; walk the six steps of the loop; then fold it back into one configuration.

3Inside the block

Agents: specialists that work inside the Pyrana Harness.

Every agent runs the same governed loop. Configuration decides what it knows, what it may use and when it is done.

What it is given

Instructions
its job, in plain language
Playbooks and examples
read when needed, not stuffed in the prompt
Skills
reusable know-how shared across agents, loaded on demand
Required outputs
shapes its results must follow

Guardrails

Budgets and limits
a capped number of steps
Approval by a person
policy decides which calls wait for a human
Right model per agent
one per agent, from approved providers; not switched mid-run
Checked as it writes
an output in the wrong shape goes straight back to the agent to fix
Acts within its access
acts as the person or the App that started it, within their access

One governed loop

  1. Admit01
    identity, no duplicate runs, audit
  2. Plan02
    explicit steps it keeps up to date
  3. Act03
    tools, helpers, several calls at once
  4. Observe04
    checkpoint, pause, resume
  5. Validate05
    its finish rules are checked before it may finish
  6. Publish06
    versioned results and its record

What it can use

cortIQ knowledge
company knowledge, every statement with its sourcecortIQ →
Data sources
company systems and approved outside APIs; numbers come from the source
Approved addresses only
only approved addresses; no plain HTTP, private networks or redirects by default
Tool servers
MCP servers the company approves
Earlier results
what was published before, within its access
Code
named data calls and scripts; its own Python only in a sandboxnumbers by code →

Everything is a file

One way in
data, knowledge, earlier results and colleagues' results all reach the agent as files; large data stays out of the prompt

Works with others

Helpers
hands part of the work to named sub-agents
Colleagues' results
results of the agents it waited for, for the same entity or the ones below itinside a workflow →

What it leaves

Versioned results
what pages, people and other agents read
The record
every step, tool call and token, traceable
9 / 16
Go deeperBack to the platform picture2 min

01Why a runtime

One runtime, fit for purpose.

Each agent in an App is configured for one job: a system prompt scoped to the use case, the tools for its data, and a library of files it discovers progressively. A model is assigned per agent through provider adapters and is not switched mid-run. For data shaping, the runtime provides a code interpreter environment that runs deterministic scripts the agent calls, so the same input yields the same output. The Harness owns the loop discipline: explicit plans, tools with declared effects, checkpoints that survive a restart, and finish conditions the model cannot bypass.

AdaptersAzure OpenAIOpenAIAnthropicFireworksGoogle Geminiothers

02Execution lanes

Five lanes, one gate.

The gate is common. Execution semantics are not forced to be. The App routes each target to the lane that fits; deterministic work never touches a model.

LaneWhenWhy
DirectDeterministic work: no model, no harness, no workflow engine.Lowest latency and cost. Smallest attack surface.
AgentAdaptive work with native tool calling, subagents, suspension for human input, checkpoint and resume.Every child tool call re-enters the gate. No ambient tool access.
WorkflowDurable graphs on Temporal, including graphs authored at runtime; fan-out per entity and per group.Suspend, checkpoint, and resume after any interruption.
BatchOne target run across many entities at once.Per-entity identity, status, and result under the same gate.
EventSchedules, webhooks, and system events trigger direct or agentic work.Continuation is explicit: NEW, JOIN, or NONE. An invalid join fails closed.

03Fan-out

One workflow, per entity and per group, in parallel.

One workflow dispatches specialized agents per entity and per group. Pyrana Capital, a synthetic portfolio, has nine operating companies in three groups under one holding company. For each operating company the monthly workflow runs three agents, revenue, materials, and labor, each scoped to its entity, its period, and the tools for its data: the agent passes the entity and the period, the tool holds the query. No agent writes a free-form query.

Outputs publish back to the App as versioned resources and roll up: operating company to group, group to holding company. Each agent reads what siblings and prior runs published, so the June analysis can reference May's. Every child execution passes the gate and leaves its own record under the parent.

monthly_analysis · 2026-06
9 opcos · 3 groups · 1 holdco
  1. HoldCo×1One holding-company summary reads the three group roll-ups.
  2. Groups×3Each group roll-up reads its operating companies' analyses and the prior month's roll-up.
  3. OpCos×9Three specialized agents per operating company: revenue, materials, labor. Each scoped to its entity, its period, and the tools for its data.
revenue-analyst
billing and receivables views · entity + period · reads prior run
materials-analyst
purchasing and inventory views · entity + period · reads prior run · revenue output
labor-analyst
payroll and scheduling views · entity + period · reads prior run · revenue output

one June run · 45 agent executions · 36 published references

NoteIllustrative. Pyrana Capital is a synthetic portfolio.

03bInside a workflow

Workflows: durable runs that fan out to agents.

A workflow decides who works, in what order, what waits for what, and when a person checks. The Pyrana Harness keeps the run going until it finishes.

inside · workflows
block 4 on the platform picture

How it starts

On request
a person starts it from a page, for the entities they choose
On a schedule
daily, weekly, any calendar
From another system
another system calls it through the API

One run

  1. Start01
    a person, a schedule or another system
  2. Check inputs02
    rejected here if wrong
  3. Plan the work03
    one task per agent and entity
  4. Fan out04
    agents run side by side
  5. Wait and roll up05
    levels follow levels
  6. Finish06
    every task done, results published

Levels follow levels; a person can review between them; one failed entity is rerun on its own.

What it accepts

Checked inputs
a missing or malformed input is rejected before any work starts
Which entities
an entity is whatever the work is for: a company, a store, a project

How the work is shaped

Side by side
independent agents work at the same time, for every entity
One after another
an agent starts when the ones it needs are done
Up the hierarchy
entities roll up level by level (for example store, region, the whole business)
A lead and its specialists
one agent hands focused questions to named specialistsinside an agent →

How it waits

For the whole level
the next level starts when every entity below is done
Each parent for its own
a parent starts as soon as its own entities are done
A person reviews between levels
the run pauses until someone approves the next level

Durable runs

Waiting is normal
a run can wait for data, a helper or a person, then continue
Automatic retries
a temporary failure in the run is tried again
Rerun one entity
fix one failed entity without starting over
Who may start it
only people with access to the workflow

What it produces

Versioned results at every level
every entity at every level publishes its own
The run's record
every entity and agent run, with retries in its history
workflow.yaml
one configuration

Any workflow is one configuration

Starts
on request, on a schedule, or from another system
Accepts
the inputs it checks and the entities it runs for
Agents
which agents work at each level
Order
side by side, one after another, up the hierarchy
Waits
for a whole level, or each parent for its own entities
Reviews
where a person checks before the next level
Recovery
retries, waiting, rerunning one entity
Produces
versioned results at every level
Example from the demo, trimmed: workflows/demo_financial_analysis.yaml →
workflow_key: demo.financial_analysis
mode: deterministic
orchestration:
  type_order: [opco, group, holdco]
  agents_by_type:
    opco:  [action_demo_sales_analyzer, action_demo_labor_analyzer,
            action_demo_materials_analyzer, action_demo_pl_analyzer]
    group: [action_demo_group_sales, action_demo_group_labor,
            action_demo_group_materials, action_demo_group_pl]
    holdco: [action_demo_holdco_pl]
  wait_mode: per_parent          # each group starts when its own companies are done
  hierarchy_nodes:
    - {id: PMW, type: opco, parent: IND}
    # ... 8 more companies
    - {id: IND, type: group, parent: PYRANA}
    # ... 2 more groups
    - {id: PYRANA, type: holdco}
agent_dependencies:
  action_demo_pl_analyzer:
    - action_demo_sales_analyzer
    - action_demo_labor_analyzer
    - action_demo_materials_analyzer
input_contract:
  enforcement_mode: strict
  json_schema: {required: [period]}

One workflow = one configuration.

Same shape, any process

Month-end close

Starts
on a schedule
Shape
up the hierarchy: entity, region, group
Review
a controller approves between levels

Weekly store review

Starts
every Monday
Shape
side by side, one task per store
Produces
a page per store for its manager

Contract intake

Starts
when another system sends a contract
Shape
one after another: read, check, summarise
Review
legal approves before it finishes
Go deeperBack to the platform picture2 min

03cNumbers by code

Code: numbers by code, words by agents.

The figures people rely on are computed by tested code the agents call: named data calls and scripts. The agents write the words.

inside · code
block 8 on the platform picture

Written ahead, tested

Named data calls
a query or an API call, written and tested ahead; the agent only fills in the parameters
Scripts
when a query is not enough, or the data comes from an API; deterministic, the same input gives the same output
Prepared before the agent starts
fixed fetches and transformations run first, so the agent begins with the data
Extensions
the business's own services that hold an App's state and rulesextensions →

From source to sentence

  1. Fetch01
    a named data call
  2. Prepare02
    scripts and fixed steps
  3. Compute03
    formulas in code, not in the model
  4. Hand over04
    results as files
  5. Write05
    the agent writes the words
  6. Keep06
    query results published next to the analysis, unchanged

Formulas run in code, not in the model. The agent reads the result and writes the words, citing the figures it used.

Controlled

Reads and writes declared
each data call says whether it only reads or changes something
Approval by a person
writes wait for approval when the policy says so; free-form SQL always does, if offered
Approved addresses only
calls go only where the connection allows; credentials stay with the platform
Limits per call
a limit on rows on every call; on warehouses, a limit on the data a query may read
Rules checked at run time
a revoked connection or changed policy stops the call

Written by the agent

Python in a sandbox
the agent may write its own code to explore; it runs in a separate service on copies of the files, and only output files come back
Guided by its instructions
an agent can be told to use only the tested data calls

Where it runs

Separate workers
data fetching, file extraction and code each run apart from the agents
Automatic retries
a temporary failure in the code sandbox is tried again before the agent sees an error

Results as files

Files, not rows
the data stays out of the prompt; large sets are fine

What you can trace

Every figure to its source
the query results are kept with the analysis, unchanged
tool-source.yaml
one configuration

Any calculation is one configuration

Data call
a name, its parameters, read-only
Controls
approved addresses, a row cap per call; writes wait for approval when the policy says so
Scripts
versioned with the agent's playbooks
Prepared
fixed steps that run before the agent
Agent's own code
guided by its instructions; always sandboxed
Output
files the agent reads and the result keeps
Example from the demo, trimmed: connectors/pyrana-demo-data-api.yaml →
source_name: pyrana-demo-data-api
tools:
  - name: entity-monthly
    description: "Monthly P&L for a single OpCo. Returns revenue, costs,
      margins with MoM/YoY deltas and trailing averages."
    input_schema: *entity_period_schema      # entity_id, start_period, end_period
    page_execution:
      read_only_attested: true
    http_config:
      payload:
        json:
          sql: |
            SELECT *
            FROM public.vw_demo_entity_monthly
            WHERE entity_id = '{{input.entity_id}}'
              AND period_id BETWEEN '{{input.start_period}}' AND '{{input.end_period}}'
            ORDER BY period_id
    output:
      artifact_path: "entity_monthly_pnl.json"   # the agent reads it as a file
      max_rows: 1000
  # ... 42 more named data calls

One calculation = one configuration. Figures come from tested code.

Go deeperBack to the platform picture2 min
For engineers and architects4 min

04Approval as policy

Policy over typed arguments, bound to a frozen proposal.

A tool approval policy inspects amounts, membership, existence, and compound rules. Above threshold, the invocation, its arguments, scope, and evidence freeze into a durable proposal the waiting agent cannot alter. Each named approval lane receives an independent obligation. Reviewer eligibility is checked at decision time. The frozen invocation is revalidated before it dispatches exactly once, and an ambiguous provider outcome goes to reconciliation rather than a blind retry.

Policies compose restrictively: a platform floor cannot be loosened by an App or an agent setting. A queued request is visibly different from a posted entry.

Go deeperApproval is a policy, not a boolean7 min
approval as policy · exec_01J9Q4M7Z3

policy over typed argumentsbuilt

tool
ledger.journal.post
args
amount=41,800.00 USD · cost_center=4410 · invoice_ref=INV-2026-07731
policy
{ approval.journal.amount }@v7 · amount >= 25,000 USD
evaluates
true → approval required
  1. Arguments are typed at the operation boundary, so the policy reads a number, not a string inside a prompt.
  2. The policy is versioned with the App. v7 is what the audit record will name.
  3. Below threshold, the same invocation dispatches immediately and writes the same record shape.
Statusconditional tool approvalfrozen invocationsapproval lanesidempotent effects
durable execution
Temporal workers
  1. Mon 14:06run started · plan written · 3 tool calls
  2. Mon 14:07ledger.journal.post frozen · lane=controller-approval
  3. Mon 14:07checkpoint · run suspended
  4. Thu 09:12j.alvarez approved · revalidate ok
  5. Thu 09:12resumed from checkpoint · dispatch once · JE-88213
Worker poolsagent runsdata fetchingfile extractioncode interpreter

05Durable execution

A process that waits three days for a signature does not start over.

Workflows are directed graphs of tasks with declared dependencies, retries, timeouts, and budgets, hosted on Temporal workers. The scheduler is deterministic and durable: it tracks node and item state, preserves partial results, and resumes after a worker or process interruption. The idempotency key claimed at the gate means a verified replay rejoins the prior result instead of starting duplicate work.

The platform is hosted as SaaS on a dedicated private tenant, or deployed into the client's own infrastructure for large enterprises. Workers scale horizontally, and separate worker pools handle data fetching, file extraction, and the code interpreter, so a large extraction does not compete with an interactive run.

06One causal trace

Every call, every lane, one record.

Gate decision, model calls, tool calls, subagents, approvals, effects, context use, and outputs are correlated under one execution identity. Traces, tokens, and tool errors are available as JSON for every run. The same evidence supports evaluation of an execution, an agent, a workflow, or an App version; deterministic checks (token growth, tool error rates) come first, then an LLM-as-judge stage in Agent Studio.

Recorded asexecution recordaudit eventeffect receiptsretrieved ⊇ injected ⊇ cited

07Questions

Frequently asked

Which models does the Harness run?
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 does the Harness scale?
The platform 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, so a large extraction does not compete with an interactive run.
When should something not be an agent?
Whenever the work is deterministic. The direct lane runs bounded operations with no model, lower latency, and a smaller attack surface. The agent lane is for adaptive work, the workflow lane for long-running work, batch for many entities, event for triggers.
What happens if a workflow waits three days for a signature?
It suspends, checkpointed, and resumes from where it stopped when the approval arrives. Nothing starts over. The idempotency key claimed at the gate means a retry reuses the receipt.
Is human approval enabled everywhere?
Tool approval policies are built and enabled per App. A platform-level floor cannot be loosened by an App or an agent setting; an App can only tighten it.

See a workflow fan out, wait for a person, and finish.

Admit, plan, act, observe, validate, publish. On the client's systems, under the client's rules.

Book a demoHow it works