Building a Speaker Arena With Kilo, Jev, and Enkrypt

Kilo and Anaconda teams built the Speaker Arena, a browser-based 3D conference park with portrait-based walking speaker avatars and an AI session guide, for the All Day AI online conference held October 22, which drew 12,313 registrants, 140 speakers, and an average viewing time of 500 minutes per user. The build used Kilo as the AI coding agent in VS Code with GPT models via a connected OpenAI subscription, Kilo Gateway to run Jev (a small decision model classifying questions as talk_question or off_topic) and Gemini 2.5 Flash (generating session answers), and Enkrypt AI for policy, guardrails, red teaming, and monitoring. The author separated development models from runtime models, noting the deployed app used server-side Kilo Gateway credentials for its own model calls rather than the OpenAI subscription that powered the build.

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/ .