3 ms·

AxonFlow – a control plane for production LLM and agent workflows

saurabhjain1592 9mo ago
Hi HN. When teams move AI agents from demos to production, the failures are rarely about model quality. They look a lot like classic distributed systems problems. - Long-running state across multiple steps. - Partial failures mid workflow. - Retries that accidentally repeat side effects. - Permissions that differ per step, not per agent. - No clean way to stop, inspect, or intervene once execution starts. Most agent frameworks are optimized for authoring workflows like prompts, tools, and plans. They are much less optimized for operating them once agents touch real systems, data, or users. That is why teams often end up adding ad hoc layers after the fact. Logging wrappers. Policy checks. Manual approvals. Retry guards. Kill switches. We built AxonFlow because these problems do not live at the API boundary. They happen inside execution paths. AxonFlow is a self hosted control plane that sits under your LLM or agent stack and governs execution step by step across LLM calls, tool calls, retries, and approvals, without replacing your existing orchestration framework. It supports execution aware policy enforcement, not just ingress checks. Human approval gates for high risk actions. Deterministic audit logs and replay and debug. Cost controls and routing primitives. Gateway mode alongside existing LangChain, CrewAI, or custom stacks. The community core is source available under BSL 1.1, runs locally, and is fully self hosted with no signup and no hosted dependency. Repo: https://github.com/getaxonflow/axonflow https://github.com/getaxonflow/axonflow Docs: https://docs.getaxonflow.com https://docs.getaxonflow.com Optional 2 minute demo showing gateway mode, policy enforcement, and a multi step workflow running locally: https://youtu.be/WwQXHKuZhxc https://youtu.be/WwQXHKuZhxc I would especially value pushback from folks who have dealt with retries, side effects, permission boundaries, or post incident auditability in real agent workflows.
- trao 9mo ago
  Demo looks sick! Good luck!
- rethinkNow 9mo ago
  I really liked the idea about the clean way to intervene with the agent flow and a better way to inspect the logging trail and I feel open source is the way to go
  - saurabhjain1592 9mo ago
    Thanks, appreciate that. The intervention point ended up being more important than we initially expected. Once workflows become multi-step and stateful, the ability to pause, inspect, or halt execution based on context (not just inputs) becomes the difference between “we noticed later” and “we prevented it.” We also found that logging alone wasn’t enough. Being able to see why a step was allowed to proceed, not just that it did, made post-incident analysis much less speculative. Curious if you’ve seen similar issues once agents start touching real systems.
devbas 9mo ago
I believe there is a big opportunity for LLM guardrails due to the non- deterministic nature of the Transformer architecture. However, the just announced Claude Cowork still warns humans to stay in control: https:// claude.com/blog/cowork-research-preview I assume this is because their non-human guardrails are not good enough yet to fully validate the output of an LLM. What non-human guardrails does Axonflow employ to enforce a policy rule with X% confidence on a prompt / LLM output?
- saurabhjain1592 9mo ago
  Thanks, this is a great question. We intentionally avoid framing guardrails as “X percent confidence” checks on prompts or model output. In practice, probabilistic confidence at the text level has been the weakest place to enforce safety, especially once workflows become multi step and stateful. AxonFlow’s non human guardrails are primarily deterministic and context grounded rather than model judgment based. Concretely, they focus on: - authorization checks on actions, tools, and write paths rather than output quality - permission evaluation per step using actual tool arguments and proposed side effects - invariant checks on state transitions, for example whether an action is allowed given what the system has observed so far - policy decisions that can halt execution entirely rather than degrade or retry We do use probabilistic components in narrow, explicit places such as PII detection or risk classification, but those always feed into a deterministic policy decision. The system never proceeds because a model “seems confident enough.” Human approval gates are not there because non human guardrails are insufficient in principle. They exist because some actions are intentionally irreversible or high blast radius, and no amount of model confidence should bypass explicit authorization. So the distinction we draw is less about validating LLM output and more about deciding whether the system is allowed to move forward at all, given the concrete context and constraints at that moment.
jphartley123 9mo ago
I think this is really what is necessary to take things to the next level at large enterprises that are working extensively with LLMs and agent-based workflows. So many teams are just making the first steps, which work quite easily in a localhost environment, but then when they try to move this to production they find that they have to build so much core infrastructure to create what is necessary to run agentic workflows as scale within a large enterprise. I am happy to see this solution looking so much more mature and feature rich than when I saw the first demo a few months ago.
kxbnb 9mo ago
The distinction between "X% confidence" checks on output vs deterministic authorization on actions/tools is spot on. We've seen the same pattern - probabilistic guardrails at the text level are the weakest enforcement point. Building in this space too (visibility layer at toran.sh, policy enforcement at keypost.ai). One thing we've found: before you can enforce policy on tool calls, you need to actually see what's happening. The "no clean way to stop, inspect, or intervene once execution starts" problem often starts with lack of visibility into what calls are being made in the first place. Curious how you handle the observability → enforcement gap. Do you assume teams already have visibility into their agent's API calls, or does AxonFlow provide that inspection layer as well?
- saurabhjain1592 9mo ago
  This is a very accurate framing. We see the same failure mode in practice. You are right that enforcement is hard if you cannot first see what is actually happening at runtime. How we think about the observability to enforcement gap: In practice, most teams start with visibility and only add enforcement once they trust the signal. AxonFlow is designed to collapse that loop by providing both in the same system. The same instrumentation that produces the audit trail can also gate execution. What AxonFlow provides today: - Full request-level capture for LLM calls and tool calls that flow through AxonFlow, including inputs, outputs, policy decisions, latencies, tokens, and cost. - A complete audit log with step boundaries, policy evaluation results, and decision context, so teams can answer what happened and why it was allowed or blocked. Critical violations such as blocks and policy triggers are logged synchronously, while successful calls are queued asynchronously for performance. - Operational controls like timeouts, approval gates, and the ability to block or require human review at a specific step. - Two integration modes: Proxy Mode, where AxonFlow sits inline in the request path, and Gateway Mode, where it acts as a policy check before and an audit capture layer after existing LLM calls. What we do not assume: - We do not assume teams already have clean visibility into all agent calls. - We do assume that for enforcement to be meaningful, the calls you want to govern must traverse AxonFlow. If some calls bypass it, you end up with fragmented audit trails and inconsistent policy enforcement. How teams adopt it: - Many teams start by routing a single workflow or a subset of tools through AxonFlow to get an end-to-end trace and audit. Once that is stable, they expand coverage and enable stricter enforcement policies. - Interesting that you are separating visibility (toran.sh) and policy (keypost.ai). We took a combined approach, but I can see the rationale for decoupling. If you have a concrete example of the invisible tool call problem you are seeing, such as custom HTTP tools, internal RPC, or database calls, I would be interested in how you are instrumenting it today. That boundary is where many systems break down.

Hi HN. When teams move AI agents from demos to production, the failures are rarely about model quality. They look a lot like classic distributed systems problems. - Long-running state across multiple steps. - Partial failures mid workflow. - Retries that accidentally repeat side effects. - Permissions that differ per step, not per agent. - No clean way to stop, inspect, or intervene once execution starts. Most agent frameworks are optimized for authoring workflows like prompts, tools, and plans. They are much less optimized for operating them once agents touch real systems, data, or users. That is why teams often end up adding ad hoc layers after the fact. Logging wrappers. Policy checks. Manual approvals. Retry guards. Kill switches. We built AxonFlow because these problems do not live at the API boundary. They happen inside execution paths. AxonFlow is a self hosted control plane that sits under your LLM or agent stack and governs execution step by step across LLM calls, tool calls, retries, and approvals, without replacing your existing orchestration framework. It supports execution aware policy enforcement, not just ingress checks. Human approval gates for high risk actions. Deterministic audit logs and replay and debug. Cost controls and routing primitives. Gateway mode alongside existing LangChain, CrewAI, or custom stacks. The community core is source available under BSL 1.1, runs locally, and is fully self hosted with no signup and no hosted dependency. Repo: https://github.com/getaxonflow/axonflow https://github.com/getaxonflow/axonflow Docs: https://docs.getaxonflow.com https://docs.getaxonflow.com Optional 2 minute demo showing gateway mode, policy enforcement, and a multi step workflow running locally: https://youtu.be/WwQXHKuZhxc https://youtu.be/WwQXHKuZhxc I would especially value pushback from folks who have dealt with retries, side effects, permission boundaries, or post incident auditability in real agent workflows.

trao 9mo ago
Demo looks sick! Good luck!
rethinkNow 9mo ago
I really liked the idea about the clean way to intervene with the agent flow and a better way to inspect the logging trail and I feel open source is the way to go
- saurabhjain1592 9mo ago
  Thanks, appreciate that. The intervention point ended up being more important than we initially expected. Once workflows become multi-step and stateful, the ability to pause, inspect, or halt execution based on context (not just inputs) becomes the difference between “we noticed later” and “we prevented it.” We also found that logging alone wasn’t enough. Being able to see why a step was allowed to proceed, not just that it did, made post-incident analysis much less speculative. Curious if you’ve seen similar issues once agents start touching real systems.

devbas 9mo ago

I believe there is a big opportunity for LLM guardrails due to the non- deterministic nature of the Transformer architecture. However, the just announced Claude Cowork still warns humans to stay in control: https:// claude.com/blog/cowork-research-preview I assume this is because their non-human guardrails are not good enough yet to fully validate the output of an LLM. What non-human guardrails does Axonflow employ to enforce a policy rule with X% confidence on a prompt / LLM output?

saurabhjain1592 9mo ago
Thanks, this is a great question. We intentionally avoid framing guardrails as “X percent confidence” checks on prompts or model output. In practice, probabilistic confidence at the text level has been the weakest place to enforce safety, especially once workflows become multi step and stateful. AxonFlow’s non human guardrails are primarily deterministic and context grounded rather than model judgment based. Concretely, they focus on: - authorization checks on actions, tools, and write paths rather than output quality - permission evaluation per step using actual tool arguments and proposed side effects - invariant checks on state transitions, for example whether an action is allowed given what the system has observed so far - policy decisions that can halt execution entirely rather than degrade or retry We do use probabilistic components in narrow, explicit places such as PII detection or risk classification, but those always feed into a deterministic policy decision. The system never proceeds because a model “seems confident enough.” Human approval gates are not there because non human guardrails are insufficient in principle. They exist because some actions are intentionally irreversible or high blast radius, and no amount of model confidence should bypass explicit authorization. So the distinction we draw is less about validating LLM output and more about deciding whether the system is allowed to move forward at all, given the concrete context and constraints at that moment.

jphartley123 9mo ago

I think this is really what is necessary to take things to the next level at large enterprises that are working extensively with LLMs and agent-based workflows. So many teams are just making the first steps, which work quite easily in a localhost environment, but then when they try to move this to production they find that they have to build so much core infrastructure to create what is necessary to run agentic workflows as scale within a large enterprise. I am happy to see this solution looking so much more mature and feature rich than when I saw the first demo a few months ago.

kxbnb 9mo ago

The distinction between "X% confidence" checks on output vs deterministic authorization on actions/tools is spot on. We've seen the same pattern - probabilistic guardrails at the text level are the weakest enforcement point. Building in this space too (visibility layer at toran.sh, policy enforcement at keypost.ai). One thing we've found: before you can enforce policy on tool calls, you need to actually see what's happening. The "no clean way to stop, inspect, or intervene once execution starts" problem often starts with lack of visibility into what calls are being made in the first place. Curious how you handle the observability → enforcement gap. Do you assume teams already have visibility into their agent's API calls, or does AxonFlow provide that inspection layer as well?

saurabhjain1592 9mo ago
This is a very accurate framing. We see the same failure mode in practice. You are right that enforcement is hard if you cannot first see what is actually happening at runtime. How we think about the observability to enforcement gap: In practice, most teams start with visibility and only add enforcement once they trust the signal. AxonFlow is designed to collapse that loop by providing both in the same system. The same instrumentation that produces the audit trail can also gate execution. What AxonFlow provides today: - Full request-level capture for LLM calls and tool calls that flow through AxonFlow, including inputs, outputs, policy decisions, latencies, tokens, and cost. - A complete audit log with step boundaries, policy evaluation results, and decision context, so teams can answer what happened and why it was allowed or blocked. Critical violations such as blocks and policy triggers are logged synchronously, while successful calls are queued asynchronously for performance. - Operational controls like timeouts, approval gates, and the ability to block or require human review at a specific step. - Two integration modes: Proxy Mode, where AxonFlow sits inline in the request path, and Gateway Mode, where it acts as a policy check before and an audit capture layer after existing LLM calls. What we do not assume: - We do not assume teams already have clean visibility into all agent calls. - We do assume that for enforcement to be meaningful, the calls you want to govern must traverse AxonFlow. If some calls bypass it, you end up with fragmented audit trails and inconsistent policy enforcement. How teams adopt it: - Many teams start by routing a single workflow or a subset of tools through AxonFlow to get an end-to-end trace and audit. Once that is stable, they expand coverage and enable stricter enforcement policies. - Interesting that you are separating visibility (toran.sh) and policy (keypost.ai). We took a combined approach, but I can see the rationale for decoupling. If you have a concrete example of the invisible tool call problem you are seeing, such as custom HTTP tools, internal RPC, or database calls, I would be interested in how you are instrumenting it today. That boundary is where many systems break down.