Engineered with purpose-built LLMs, Arch handles the critical but undifferentiated tasks related to the handling and processing of prompts, including detecting and rejecting jailbreak attempts, intelligently calling “backend” APIs to fulfill the user’s request represented in a prompt, routing to and offering disaster recovery between upstream LLMs, and managing the observability of prompts and LLM interactions in a centralized way - all outside business logic.
Here are some additional key details of the project,
* Built on top of Envoy and is written in rust. It runs alongside application servers, and uses Envoy's proven HTTP management and scalability features to handle traffic related to prompts and LLMs.
* Function calling for fast agentic and RAG apps. Engineered with purpose-built fast LLMs to handle fast, cost-effective, and accurate prompt-based tasks like function/API calling, and parameter extraction from prompts.
* Prompt guardrails to prevent jailbreak attempts and ensure safe user interactions without writing a single line of code.
* Manages LLM calls, offering smart retries, automatic cutover, and resilient upstream connections for continuous availability.
* Uses the W3C Trace Context standard to enable complete request tracing across applications, ensuring compatibility with observability tools, and provides metrics to monitor latency, token usage, and error rates, helping optimize AI application performance.
This is our first release, and would love to build alongside the community. We are just getting started on reinventing what we could do at the networking layer for prompts.
Do check it out on GitHub at https://github.com/katanemo/arch/.
Please leave a comment or feedback here and I will be happy to answer!
My key question is, who would be the ideal customer who would need a proxy or a gateway like this? Why couldn't it be an extension or plugin of existing LBs, proxies etc.
1/ Arch builds on Envoy so that we don't re:invent all the HTTP(s)/TCP level capabilities needed in a modern gateway for applications. So in that sense, we agree with you that it should "extend" something vs. rewriting the whole stack. There are several security and robustness guarantees that we borrow from Envoy as a result of this. To be more specific, a lot of Arch's core implementation today is an Envoy filter written in Rust.
1/ Arch's core design point is around the handling and processing of prompts, which we believe are nuanced and opaque user request that require secure handling, intelligent routing, robust observability, and integration with backend (API) systems for personalization – all outside business logic. This requires the use of models and LLMs that are fast, cheap and capable to help developers stay focused on application features. For example, Arch uses (fast) purpose-built LLMs for jailbreak detection, converts prompts into API semantics for personalization, and (eventually) automatically routing to the best outbound LLM based on the complexity of a prompt to improve the cost/speed of an app.
We believe #2 will continue to be different and evolve further away from traditional API/HTTP routing that it will require constant invention and work to make the lives of developers easy.
Hope this helps!