Phrony
The open runtime for production AI agents
Start new thread
Max Bols

Phrony - Ship AI agents without the operational burden

by
Phrony
•
Phrony is where AI agents live, run, and stay under control. We handle the parts that get hard once agents hit production: multi-agent orchestration, human-in-the-loop escalation, full audit trails, anomaly detection, and the security layer companies actually need. All built in, not bolted on. One platform to build, deploy, and govern real AI agents.

Add a comment

Replies

Best
Max Bols
Maker
📌
Hey Product Hunt 👋 I'm Max, co-founder of Phrony. Right now most "AI agents" are really just workflows. n8n, Zapier, a Python script with some LLM calls glued together. Works fine until something breaks. Then you're staring at a half-finished run with no idea which step failed, why, or what to do about it. So we built Phrony. It's the runtime layer where real agents live and run, with the boring-but-essential stuff baked in: full audit trails, human-in-the-loop escalation, anomaly detection, RBAC, secrets vault, multi-agent orchestration. Built for teams shipping real agents, but useful for anyone who wants their agents to stay under control once they leave the laptop. Curious for anyone here running agents or workflows in production: what broke first?
Abhiranjan kumar

Love this! The fact that anomaly detection can auto-terminate a run is wild (in a good way). Most tools just log and pray. Upvoted 🚀

Francesco Bianchi

Congrats on the launch. Curious about the HITL escalation layer. What triggers a human approval today? Is it rule-based (e.g. tool calls above a cost threshold), confidence-based (the agent itself flags uncertainty), or configurable per-agent? Feels like the hardest UX problem in production agents.

Max Bols
Maker

@francesco2689 

Thanks! You've put your finger on the hardest part.

Today it's mostly policy and rule-driven, configurable per agent. Typical triggers:

  • Risk or anomaly scores crossing a threshold

  • Sensitive tool categories or anything with external side effects

  • Actions above a cost/value limit

  • Policy violations

  • Execution patterns that deviate from expected behavior

When one fires, the runtime pauses, preserves the full run state, and routes the task to a human to approve, reject, or redirect.

We intentionally don't rely on raw LLM confidence as the primary signal. It's too inconsistent across models and prompts. We use it as one input in the pipeline, not the trigger.

Escalation is configurable at four levels: organization, agent, tool/integration, and step/workflow checkpoints.


On your last point: the real tradeoff is autonomy vs operator trust vs interruption fatigue. Too many approvals kill the automation, too few kill the trust. That's why we lean on deterministic guardrails plus anomaly/behavioral signals instead of putting static gates everywhere.

Francesco Bianchi

@max_bols Thanks, that's a great answer. Four-level configurability (org / agent / tool / step) is more granular than I expected. Will be following along.

Suyash

Looks great congrats on the launch! Quick one: does the multi-agent orchestration support agents written in different frameworks talking to each other? Or do they all have to live inside Phrony's own SDK?

Max Bols
Maker
@suyash_kr Great question 🙏 It's not that we don't have it, it's that Phrony is designed not to. We built our own runtime with its own way of handling orchestration, and agents are defined through manifests rather than imported from external frameworks. That choice is what lets us guarantee the audit trail, HITL, and anomaly detection actually work end-to-end. If agents live in someone else's runtime, we can't really govern them, just observe them.
Nikolas Dimitroulakis

congrats! upvoted

Siddharth Singh

This is really interesting! Especially the part about keeping the LLM in place. Been building agents the past few months and the lack of visibility once they hit production is genuinely scary. Excited to try this out.