Phrony
The open runtime for production AI agents
Start new thread

Phrony - Declare an agent in a manifest, run it, and trace every call

by•
Phrony is where AI agents live, run, and stay under control. An agent starts as a few lines of code. In production, with real tools, budgets, and humans in the loop, it's not a function anymore. It's an entity, and code is the wrong place to keep it. Phrony lets you declare an agent in one YAML manifest, run it on an open runtime, and trace every run. Open spec, open-source, portable.

Add a comment

Replies

Best
Maker
📌
Hey Product Hunt 👋 I'm Max, co-founder of Phrony. An agent starts as a few lines of code. Works great. Then it gets real tools, a budget, a human who has to approve the risky calls, and six months of small tweaks. One day it breaks in prod and you're staring at a half-finished run with no idea which step failed, why, or when the behavior changed. That's the moment it stopped being code. It became an entity, and code is the wrong place to keep an entity. So we built Phrony. You declare an agent in one YAML manifest, run it on the runtime, and trace every single run. The runtime owns the loop, the tool calls, the rules, and the full record of what happened. Swap models without rewriting anything. Provider-agnostic, like Terraform. Spec is open, runtime is open-source. Read every line, run it yourself, no lock-in. docker compose up and your first agent is going in a few minutes. What are you building agents for right now? Genuinely want to know.

The manifest + runtime framing makes sense. Once an agent has tools, budgets, approvals, and real users depending on it, it stops feeling like “just code” and starts behaving more like an operational entity.

The part I’d be most interested in is state and handoff. Tracing every run is useful, but when a human needs to step in, they usually need more than logs: what the agent believed, what it tried, what it was unsure about, and what decision it needs from the reviewer.

How do you separate persistent agent state from per-run trace data? And does escalation preserve enough context for a human to re-enter without reconstructing the whole workflow from scratch?

Maker

Hi!
We split it by what the agent needs to resume vs what you need to audit.

Persistent state lives in the session + append-only event log (messages, tool calls/results, approvals). Conversation history is rebuilt from that log on read — not stored separately.

Trace data is mostly the same events, plus derived ledgers (tool invocations, approvals) and live streaming output that only gets persisted once a turn commits.

Escalation (human-in-the-loop): for tool approvals and dispatch failures, yes — enough context is preserved. A human can attach or approve/reject out of band, and the agent resumes the same turn from folded history. You don’t need to replay the whole workflow.

The approval card shows the pending decision (tool, args, reason); use session inspect for full context. Limit-based escalations are lighter; they unblock the session, but the operator usually sends a new message to continue.


For more detailed information please visit our documentation portal: