AxonFlow – a control plane for production LLM and agent workflows(github.com)
github.com
AxonFlow – a control plane for production LLM and agent workflows
https://github.com/getaxonflow/axonflow
11 comments
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?
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?
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.
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.
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
Docs: https://docs.getaxonflow.com
Optional 2 minute demo showing gateway mode, policy enforcement, and a multi step workflow running locally: 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.
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
Docs: https://docs.getaxonflow.com
Optional 2 minute demo showing gateway mode, policy enforcement, and a multi step workflow running locally: 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.
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
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.
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.
Demo looks sick! Good luck!
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?
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?
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.
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.
Good question. The boundary problem shows up most clearly with third-party API integrations - Stripe, Twilio, Shopify, etc.
The pattern we see: an agent makes an API call, gets a 400 or unexpected response, and the developer has no visibility into what was actually sent. The agent's logs show "called Stripe API" but not the actual payload that triggered the error. Vendor support says "the request was malformed" but the agent's internal state looks fine.
With https://toran.sh, we create a read-only inspection endpoint bound to a single upstream API. The agent points at our URL instead of the vendor's, and we proxy everything through while capturing the raw request/response. No SDK, no code changes to the agent - just swap the base URL.
The instrumentation approach is intentionally minimal: we don't try to understand the semantics of the calls, just show exactly what bytes hit the wire. Teams can then add policy enforcement (via https://keypost.ai or similar) once they actually understand what their agents are doing.
Curious about AxonFlow's approach to custom HTTP integrations - do you intercept at the network layer or require explicit tool registration?
The pattern we see: an agent makes an API call, gets a 400 or unexpected response, and the developer has no visibility into what was actually sent. The agent's logs show "called Stripe API" but not the actual payload that triggered the error. Vendor support says "the request was malformed" but the agent's internal state looks fine.
With https://toran.sh, we create a read-only inspection endpoint bound to a single upstream API. The agent points at our URL instead of the vendor's, and we proxy everything through while capturing the raw request/response. No SDK, no code changes to the agent - just swap the base URL.
The instrumentation approach is intentionally minimal: we don't try to understand the semantics of the calls, just show exactly what bytes hit the wire. Teams can then add policy enforcement (via https://keypost.ai or similar) once they actually understand what their agents are doing.
Curious about AxonFlow's approach to custom HTTP integrations - do you intercept at the network layer or require explicit tool registration?
We intentionally require explicit tool and connector registration rather than doing blind network layer interception.
The reason is deliberate: we want semantic understanding of what a call represents, not just raw HTTP payloads. When a connector is registered, AxonFlow knows the operation type (database, external API, internal service), can parse the intent, and apply phase aware policies such as blocking dangerous operations before execution, redacting sensitive fields from responses, or enforcing connector specific rate limits.
For arbitrary HTTP integrations, we provide a generic HTTP connector (platform/connectors/http/) that can be configured against any REST endpoint. You register the base URL, auth mechanism (bearer, basic, API key, OAuth2), and headers. From that point on, all requests flow through the same policy engine used for database and first class connectors.
Trade offs versus a pure proxy approach: - Our approach requires explicit setup. In return, governance is richer: semantic policy enforcement, field level redaction, connector scoped rate limits, and clearer audit trails.
- A proxy based approach has near zero setup and full payload visibility, but enforcement has to reason over raw HTTP without understanding what the call actually does.
On the Stripe or Twilio “what was actually sent?” debugging problem you mentioned: with our model, the connector captures request, response, status, latency, and policy decisions in the audit log. You can see exactly what payload caused a failure, as long as the call was routed through AxonFlow.
The boundary issue you raised is real. Calls that bypass the connector layer (direct SDK usage, internal RPCs) are invisible to us. We are explicit with teams about this: if you want governance and auditability, the call needs to traverse the control plane. Anything outside that path is outside enforcement.
If helpful for additional context, this is discussed in more detail in our recent Show HN thread: https://news.ycombinator.com/item?id=46692499
Curious whether you are seeing teams combine both patterns in practice: raw visibility layers for debugging, plus a semantic enforcement layer for policy. They seem to solve adjacent but distinct problems.
The reason is deliberate: we want semantic understanding of what a call represents, not just raw HTTP payloads. When a connector is registered, AxonFlow knows the operation type (database, external API, internal service), can parse the intent, and apply phase aware policies such as blocking dangerous operations before execution, redacting sensitive fields from responses, or enforcing connector specific rate limits.
For arbitrary HTTP integrations, we provide a generic HTTP connector (platform/connectors/http/) that can be configured against any REST endpoint. You register the base URL, auth mechanism (bearer, basic, API key, OAuth2), and headers. From that point on, all requests flow through the same policy engine used for database and first class connectors.
Trade offs versus a pure proxy approach: - Our approach requires explicit setup. In return, governance is richer: semantic policy enforcement, field level redaction, connector scoped rate limits, and clearer audit trails.
- A proxy based approach has near zero setup and full payload visibility, but enforcement has to reason over raw HTTP without understanding what the call actually does.
On the Stripe or Twilio “what was actually sent?” debugging problem you mentioned: with our model, the connector captures request, response, status, latency, and policy decisions in the audit log. You can see exactly what payload caused a failure, as long as the call was routed through AxonFlow.
The boundary issue you raised is real. Calls that bypass the connector layer (direct SDK usage, internal RPCs) are invisible to us. We are explicit with teams about this: if you want governance and auditability, the call needs to traverse the control plane. Anything outside that path is outside enforcement.
If helpful for additional context, this is discussed in more detail in our recent Show HN thread: https://news.ycombinator.com/item?id=46692499
Curious whether you are seeing teams combine both patterns in practice: raw visibility layers for debugging, plus a semantic enforcement layer for policy. They seem to solve adjacent but distinct problems.
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.