Pyrana Harness
Runtime, orchestration, fan-out, approval lanes.
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.
Exec read 3 min Full read 9 min
- Admit01
identity resolved, idempotency claimed, audit written
- Plan02
explicit steps, written through tools, not hidden state
- Act03
tools, subagents, extensions with delegated tokens
- Observe04
checkpoint; suspend for a person or an external result
paused · awaiting approval - Validate05
declared finish conditions: required artifacts, packet schemas
- Publish06
receipts, effects, versioned resources, one causal trace
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.
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.
| Lane | When | Why |
|---|---|---|
| Direct | Deterministic work: no model, no harness, no workflow engine. | Lowest latency and cost. Smallest attack surface. |
| Agent | Adaptive 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. |
| Workflow | Durable graphs on Temporal, including graphs authored at runtime; fan-out per entity and per group. | Suspend, checkpoint, and resume after any interruption. |
| Batch | One target run across many entities at once. | Per-entity identity, status, and result under the same gate. |
| Event | Schedules, 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.
- HoldCo×1One holding-company summary reads the three group roll-ups.
- Groups×3Each group roll-up reads its operating companies' analyses and the prior month's roll-up.
- 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
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 minpolicy 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
- Arguments are typed at the operation boundary, so the policy reads a number, not a string inside a prompt.
- The policy is versioned with the App. v7 is what the audit record will name.
- Below threshold, the same invocation dispatches immediately and writes the same record shape.
- Mon 14:06run started · plan written · 3 tool calls
- Mon 14:07ledger.journal.post frozen · lane=controller-approval
- Mon 14:07checkpoint · run suspended
- Thu 09:12j.alvarez approved · revalidate ok
- Thu 09:12resumed from checkpoint · dispatch once · JE-88213
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, and an LLM-as-judge stage in Agent Studio is in development.
07Questions
Frequently asked
Which models does the Harness run?
How are runs evaluated?
How does the Harness scale?
When should something not be an agent?
What happens if a workflow waits three days for a signature?
Is human approval enabled everywhere?
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.