|
Nice work, Saurabh. It think you have tackled a deeper problem with llm and agents governance. The small to midsize companies are racing ahead with agentic integrations where security generally comes as after though, your product gives a no-fluff approach to bolt the security early on and not as an after thought. I'd like take a critical view and curious to hear your and others thoughts about the same. 1) Axonflow offers dual mode architecture - as a gateway or a full blown governance via proxy mode. In my experience, projects(in enterprise) start small but quickly find themselves amidst requiring deeper fine grained control than just as a gateway check. What migration paths do you give for users for a seamless transition ? The last thing a project wants at a certain stage is to rewrite all the llm invocations to go through axonflow.execute_query(). This migration cliff exists and good have an early insight in your architecture. 2) The static (sub-10 ms, in-memory) + dynamic (sub-30 ms, cached) split is good for performance, but the documentation shows policies as a central construct loaded into Postgres/Redis.
There is little visibility into how complex/custom/conditional policies (e.g., business-rule-dependent, ML-based anomaly scoring, or external IdP-attribute checks) are authored, versioned, tested, or rolled out safely. AxonFlow risks becoming a bottleneck if policy logic grows beyond simple PII/SQLi/rate-limit rules — especially since dynamic policies still incur DB/cache round-trips. Something that you find in enterprise environments. 3) With complex rules come the performance expectations. As a suggestion, you could try and publish more standard performance benchmarks with sufficiently complex rules both in structure and count. Real world production scenarios, think of - overlapping policies, cold cache, expensive dynamic lookups could significantly push up the tail latencies. 4) Finally, the multi agent planning seems to break the guiding principle of "control plane, not orchestration" boundary. I have no knowledge of the internals and perhaps its documentation that is giving me this perspective but the proxy mode seems to inch towards direct competition with langchain/crewAI. Much of my observations are what I got from the documentation. Please excuse any errors in my understanding and correct them, where required. Wishing you the best. |
1) Migration path gateway to proxy You are right that many enterprise projects start with perimeter checks and then want deeper execution control. We designed gateway mode specifically as the lowest friction on ramp, not as the end state. The migration path is not "rewrite everything into axonflow.execute_query". The core idea is to keep your orchestration code and incrementally move enforcement points under AxonFlow. Practically, teams start with gateway mode around one workflow for pre check plus audit. Then they adopt step level enforcement by passing step metadata and calling AxonFlow per step. Finally, for workflows where they want deterministic replay, approvals, and full execution trace, they can run those paths in proxy mode while leaving other paths in gateway mode. So it can be mixed. You do not have to flip the whole system at once.
2) Authoring, versioning, testing, rollout of complex policies Agree that if policy logic grows beyond simple checks, the system has to support safe change management. Today policies are treated as a first class config artifact with explicit versioning and audit trail, and we expect teams to test them like code. We are also investing in better tooling here, including policy simulation against recorded traces, staged rollout, and guardrails for regression. On "dynamic implies DB/cache round trips", the hot path is designed to stay cached, and dynamic policy evaluation is bounded and observable. If a policy needs external calls, that is explicit and should be treated as a production dependency with its own SLO, not something hidden inside the control plane.
3) Benchmarks Agree. The numbers in the docs are indicative for simple checks, not a substitute for real benchmarks. We should publish benchmarks that include overlapping policies, cold cache, and more expensive dynamic lookups, and show tail latency percentiles. This is on the near term roadmap because for an inline control plane, p95 and p99 matter more than averages.
4) Multi agent planning versus control plane boundary This is a fair callout. Our primary goal is governance, not planning. Proxy mode needs some orchestration primitives to enforce execution safely, for example retries with side effect control, approval gates, and step level auditability. We are not trying to compete with LangChain or CrewAI on planning sophistication. In most deployments, we expect users to keep their orchestrator and use AxonFlow as a governance layer. The multi agent planning capability exists mainly so teams can start with a governed runtime for simple cases, not as a replacement for full featured agent frameworks.
If you are open to it, I would love to dig into one concrete example from your experience, like what "migration cliff" looked like and which policy types became the bottleneck. Happy to correct any gaps in my understanding too.