AxonFlow – a control plane for production LLM and agent workflows

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.

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.