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.