# Building a Speaker Arena With Kilo, Jev, and Enkrypt > Source: > Published: 2026-10-27 21:14:23+00:00 Last week some of the Kilo and Anaconda team ran one of the largest online AI conferences: [All Day AI](https://alldayai.com/) had **12,313 registrants, 140 speakers, and an average viewing time of 500 minutes per user**. The October 22 event featured OpenRouter co-founder and COO **Chris Clark**, Remote president and co-founder **Marcelo Lebre**, Anaconda VP of Engineering **Emilie Schario**, and speakers from Mastercard, Microsoft, Qualcomm, and many more. I wanted to give people another way to discover [that amazing speaker lineup](https://alldayai.com/speakers) and explore the [four-track program](https://alldayai.com/schedule). Instead of only scrolling through speaker cards, what if you could walk around a virtual conference world and ask questions about the sessions? That became the [Speaker Arena](https://arena.alldayai.com/): a browser-based 3D park with portrait-based walking speaker characters, four conference pavilions, and an AI session guide. The event figures describe their background and conference talk. ## The Toolkit I used **[Kilo](https://kilo.ai/)** as my AI coding agent (in VS Code, but you can [use Kilo across tools](https://kilo.ai/install), including the new Kilo Desktop), with GPT models accessed through my [connected OpenAI subscription](https://blog.kilo.ai/p/sign-in-with-chatgpt). For the live application, **[Kilo Gateway](https://kilo.ai/gateway)** provided access to two models: **Jev**, a small decision model for classifying questions, and **Gemini 2.5 Flash**, which generated the session answers. **[Enkrypt AI](https://www.anaconda.com/products/enkrypt-ai-by-anaconda)** supplied the policy, guardrails, red teaming, and monitoring workflow. It let me define how the AI product should behave, test those boundaries, and inspect what happened when requests were flagged. In short: Kilo helped me build it; Kilo Gateway connected the runtime models; and Enkrypt AI helped me test and enforce the product’s guidelines. ## Building With OpenAI Subscription Inside Kilo During development, I connected my OpenAI subscription to [Kilo](https://kilo.ai/) and used GPT models through that connection to build and iterate on the application. Our post on [using your ChatGPT subscription inside Kilo](https://blog.kilo.ai/p/use-chatgpt-subscription-inside-kilo) explains that setup. Kilo handled code changes across the frontend and backend, added tests, and helped prepare branches and PRs. The first version I built was 2D. Once it worked, I asked for “*a more full screen environment, maybe even a 3d world*” and suggested using speaker photos for walking avatars. We evolved that into a Three.js conference park, keeping the existing chat backend while replacing the visual experience. The same loop worked for less visible changes: integrating guardrails, improving the speaker context, and simplifying the chat interface. **The important distinction: the models helping me write the app were not the same models answering visitors inside it.** My OpenAI subscription powered my development workflow in Kilo. The deployed app used server-side Kilo Gateway credentials for its own model calls. ## Different Models for Different Jobs I did not want every message to go straight to a general-purpose answer model. The app needed to check the input, decide whether it belonged in the experience, and only then generate an answer. Here is how I split the responsibilities: ### Jev Decides Whether to Generate Jev receives the visitor’s question, bounded conversation history, and information about the selected speaker. It then returns a structured choice: `talk_question` or `off_topic`. For more on the specialized-model approach, see Kilo’s [“Jev, Jevons, and the AI model that only answers yes or no”](https://blog.kilo.ai/p/jev-jevons-and-the-ai-model-that). For an off-topic request, the application returns a predefined redirect. It does not ask the answer model to write one. For a relevant question, the application continues to answer generation. Enkrypt guardrails can also handle these relevance and topic checks. I added Jev because I wanted hands-on experience with a small decision model alongside building with Enkrypt, not because the application required a separate product for that task. Both model calls go through [Kilo Gateway](https://kilo.ai/gateway): Jev uses the TypeSafe System One endpoint, and Gemini uses the OpenAI-compatible chat-completions endpoint. One server-side `KILO_API_KEY` covers both inference calls; Enkrypt has its own credential. Since [Kilo Gateway](https://kilo.ai/docs/gateway) supports 500+ models, it let me combine a specialized classification model with a generation model without managing separate provider credentials for each. Skipping generation for off-topic requests avoids that call, although total cost and latency still depend on the overhead of routing and checks. ### Enkrypt: From Policy to Guardrails & Testing For this experiment, I assigned the roles explicitly: **Jev handles relevance to the conference; Enkrypt handles the configured security checks.** My Enkrypt workflow started with the guidelines: #### **Create the policy** I created **“All Day AI - Code of Conduct”**, describing the public-facing guide, its capabilities, and its boundaries. This also included policy for compliance with regulatory frameworks such as the EU AI Act. #### **Select rules and configure input and output guardrails** Based on the policy I then created rules that I turned into enforceable guardrails. Example rules I used: *disclose that it is AI and do not impersonate speakers; do not fabricate speaker facts; do not facilitate violence; and do not exploit vulnerable groups.* In the input guardrails, I enabled **Policy Violation** and selected that policy alongside built-in detectors such as injection attacks, toxicity, and bias. #### **Test through red teaming** I tested the guardrails with adversarial inputs and outputs using Enkrypt’s built-in red-teaming feature. #### **Review the logs** I checked usage and individual detector results. The full request path became: ``` php Visitor's question -> Enkrypt input guardrails check -> Jev relevance decision through Kilo Gateway -> Off-topic: redirect, skip generation -> Relevant: Gemini answer through Kilo Gateway -> Enkrypt output guardrails check for generated answers -> Display the checked answer ``` The enforcement lives on the server. Enkrypt returns detector results; our backend interprets them and stops the request when needed. A flagged input never proceeds to Jev or Gemini, and a generated answer stays on the server until its output check passes. Required checks or routing failures stop the pipeline rather than silently bypassing it. Live testing also exposed an important detail: broad PII settings flagged benign speaker-related content. Public names and organizations are normal in this app. I adjusted the saved guardrail, disabling that overly broad detector for the prototype, then retested normal questions, off-topic requests, and injection attempts. ## Give the Answer Model Something Worth Using Gemini’s job was to explain sessions, not invent expertise from a speaker’s name. We supplemented the public roster with curated reference material, mostly abstracts, and passed bounded context for the selected speaker into the pipeline. The guide answers **about speakers, not as them**. Proposed material stayed tentative, and missing information should remain missing. A portrait is not permission to attribute generated statements to a real person. I also wanted the integrations to be visible without turning chat into a debug console. A compact UI element above the chat interface shows Enkrypt checks and Kilo Gateway activity as real server events as they happen. ## What Made the Combination Useful Kilo and Enkrypt now share a parent company, Anaconda, and this was the first time I used both on the same product. Kilo gets the application built and running, and Enkrypt secures what it does once strangers start using it. On the Kilo side, my OpenAI subscription powered the build, which let me try the latest models, including Astra and Sol, against my plan usage. Once the app was live, Kilo Gateway gave it a single server-side key for two model jobs: Jev decided whether a question belonged in the conversation, and Gemini wrote the answer. Enkrypt wrapped both calls. I wrote the policy, turned it into input and output guardrails, red-teamed them, and read flagged requests in the event log. The backend enforces the result, so a flagged question never reaches Jev or Gemini, and a generated answer stays on the server until it passes the output check. When the PII detector flagged public speaker names, I turned it off for the prototype and retested. A coding agent and a gateway don’t test whether your product holds up under injection attempts or off-policy requests; Enkrypt does. Enkrypt doesn’t write your app or route your models; Kilo does. Using them together meant I could build quickly and still ship something I had secured and tested first. I used capable frontier models to build it, then used cheaper models to classify and answer the question. That flexibility runs through Kilo’s [Model freedom](https://kilo.ai/model-freedom). Explore the [All Day AI speaker archive](https://www.alldayai.com/speakers), start building with [Kilo](https://kilo.ai/), and secure your AI with [Enkrypt](https://www.enkryptai.com/).