Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.phrony.com/llms.txt

Use this file to discover all available pages before exploring further.

A Phrony manifest is a YAML document (or stream of documents) that declares resources in your workspace: LLM providers, integrations and their operations, agents, agent versions, and triggers. Use it to back up setup, move work between environments, or review changes before you apply them. The product speaks the same model as the dashboard. Applying a manifest reconciles those declarations with what already exists—creating, updating, or aligning records so your workspace matches the file.

Where you use manifests in Phrony

ActionWhere
Export manifestOn an agent’s detail page, or from the agents list (per agent). Downloads a YAML file (for example phrony-manifest-<slug>.yaml).
Apply manifestImport manifest on the agents list, or Apply manifest on an agent detail page. Upload YAML; optionally run a dry run first to preview planned changes without writing.
When you apply from an agent detail page, reconciliation can be scoped to that agent’s subtree (multi-agent setups). From the agents list, apply is workspace-wide unless your flow uses an anchor (the dashboard sets this when you open the dialog from an agent). After a successful apply, built-in integrations that need an account may appear as pending connection—complete connection in the dashboard the same way as when you create an integration without credentials.

Document shape (version 1)

Every manifest document must include:
FieldValue
kindphrony.manifest (legacy exports may use phrony.workspace.manifest; both are accepted.)
version1
Optional top-level sections:
SectionPurpose
metadataExport hints: optional exportedAt, label, rootManifestKey.
llmProvidersNamed model backends referenced by agents.
servicesIntegrations (http or built_in) and their operations.
agentsAgent identity: manifestKey, name, executionMode, llmProviderName.
versionsPer-agent version snapshots (model, instructions, tools, limits, …).
triggersHow work enters agents (schedule, API, or event).

Optional metadata

FieldDescription
exportedAtISO timestamp from export (informational).
labelOptional human note.
rootManifestKeyOptional logical key of the “root” agent in a multi-agent export.

LLM providers (llmProviders)

Each item is a named provider your agents can use:
FieldDescription
nameUnique name; agents reference this in llmProviderName.
typeOne of: openai, openai_azure, anthropic, self_hosted.
baseUrlOverrideOptional override URL for the vendor API (often null or omitted).
Provider credentials are not embedded in the manifest. The workspace must already have compatible provider configuration; the manifest ties agent records to provider names you use in Phrony.

Services and operations (services)

Each item is an integration-shaped record:
FieldDescription
manifestKeyOptional stable key for reconciliation; if omitted, identity falls back to name.
nameDisplay name; referenced by operations and by allowedOperations on versions.
typehttp or built_in.
configConnection settings (base URL, auth shape, built-in toolkit slug, defaults, …). Sensitive pieces may be redacted on export (secretsRedacted may be set).
secretsRedactedWhen true, the export removed secrets; you must re-supply connection details or secrets where needed.
operationsOptional list of tools exposed from this integration (see below).
Operation object:
FieldDescription
manifestKeyOptional stable key for this operation.
nameOperation name; paired with serviceName in allowedOperations.
descriptionOptional text for operators or tooling.
configurationHTTP path/method/headers, or built-in tool slug and version—same concepts as the operation editor in the dashboard.
requireApprovalWhether this tool requires approval when your execution mode allows it.
argumentsSchemaOptional JSON Schema for tool arguments.
secretsRedactedMirrors service-level redaction for this operation if applicable.
Built-in rows may export without a live connection; after apply, connect the integration in the dashboard if prompted.

Agents (agents)

FieldDescription
manifestKeyRequired stable id used everywhere else in the file (agentManifestKey, allowedSubAgents, triggers, …).
nameHuman-readable name.
executionModerequest, hitl, or sub_agent (same semantics as Agent).
llmProviderNameMust match a llmProviders[].name.

Agent versions (versions)

Each item is one version snapshot for an agent identified by agentManifestKey:
FieldDescription
agentManifestKeyLinks to agents[].manifestKey.
statustesting or deployed.
versionLabelLabel for this line (for example v1).
llmModelModel id for the chosen provider.
instructionsOptional system-style instructions.
descriptionOptional short description (length limits apply in product).
inputSchema / outputSchemaOptional JSON Schema objects.
temperatureOptional sampling temperature.
maxIterations, maxTokensPerRun, maxToolCallsOptional run budgets.
anomalyControlOptional L1 anomaly behavior (see Guard overview and L1 rules).
canExecuteSubAgentsWhether this agent may delegate to sub-agents.
subAgentExecutionModelsequential or parallel when sub-agents are allowed.
maxSessionTokens, maxSessionDurationSec, topP, topKOptional session and sampling limits.
rulesOptional list (product-specific rule objects).
allowedOperationsOptional list of { serviceName, operationName } entries that become allowed tools.
allowedSubAgentsOptional list of sub-agent manifestKey values this version may call.
allowedOperations uses integration name and operation name as shown in the manifest’s services section, not arbitrary labels.

Triggers (triggers)

Each trigger targets one agent (agentManifestKey) and is one of: Scheduled
FieldDescription
nameTrigger name.
typescheduled
cronExpressionCron string.
timezoneIANA timezone name.
inputPayloadOptional JSON object passed into runs.
manifestKeyOptional stable key.
API
FieldDescription
nameTrigger name.
typeapi
rpmLimit, rpdLimit, maxConcurrentRuns, maxInputTokensOptional rate and concurrency limits.
ipWhitelistOptional list of allowed callers.
exposeStepTimelineToApiOptional visibility flag for step timeline in API responses.
manifestKeyOptional stable key.
Event
FieldDescription
nameTrigger name.
typeevent
serviceNameIntegration name the event is tied to.
eventSlugEvent identifier for that service.
eventConfigOptional JSON object.
manifestKeyOptional stable key.
For how triggers behave at runtime, see Trigger ingress and Agent — Triggers.

Multiple YAML documents and includes

You can put several YAML documents in one file, separated by --- (a multi-document stream). They are merged into a single logical manifest: later values override earlier ones for the same logical keys (for example same manifestKey on an agent or service). You can also add index documents that only pull in other paths or snippets:
kind: phrony.manifest.index
version: 1
includes:
  - ./shared-integrations.yaml
  - ./my-agents.yaml
Included content is loaded in order and merged the same way. (Very deep include chains are rejected to avoid cycles.)

Dry run and apply result

A dry run returns a plan: which resources would be created, updated, left unchanged, or deleted—without persisting changes. Use it to review diffs before applying. A real apply returns a result that includes the root agent id used for the operation, a list of changes, optional warnings, and—when integrations still need OAuth or API keys—a list of services needing connection so you can finish setup in the dashboard.

Agent

Execution modes, versions, and triggers in the product model.

Integration

HTTP and built-in services and how operations become tools.

LLM provider

Saved vendor connections agents use for model calls.