Atlarix: The Ultimate Platform for Building Elasticsearch Agents
💡 Inspiration
The idea for Atlarix was born from a simple observation: building intelligent, production‑ready AI agents is still too hard. Developers face a dizzying array of choices—which model to use, how to orchestrate tools, how to handle permissions, how to maintain context. Meanwhile, Elasticsearch, despite being a powerful search and analytics engine, remains underutilized because its query DSL and optimization techniques have a steep learning curve.
We asked ourselves: What if we could combine the best of both worlds? What if we could build a platform that makes creating Elasticsearch agents as easy as dragging and dropping blocks—while still giving developers full control over the AI models, tools, and workflows?
That's how Atlarix was born. Named after Atlas (the titan who held up the sky) and Axis (the central line around which things revolve), Atlarix is designed to be the backbone of intelligent agent development. For this hackathon, we're showcasing how Atlarix can be specialized to build powerful, safe, and context‑aware Elasticsearch agents in minutes instead of months.
🔨 How We Built It
Building Atlarix has been a journey of iteration and refinement. Here's how we approached the Elasticsearch agent capabilities:
1. Agent Architecture Evolution
We started with a simple chatbot but quickly realized that real‑world agents need structure. We implemented two complementary modes:
- Guided Mode: A flat delegation system with specialist agents (Architect for design, Builder for implementation, Reviewer for quality). For Elasticsearch, we added an "Elasticsearch Expert" agent with dedicated tools.
- Autonomous Mode: Agents can spawn sub‑agents, enabling complex multi‑step workflows like "analyze the codebase, suggest indices, generate queries, and create a Kibana dashboard."
2. Multi‑Provider AI Routing
We didn't want to lock users into a single model provider. Atlarix now supports 10+ providers, including AWS Bedrock (added just in time for this hackathon!). The magic is in our intelligent routing layer:
- Simple queries (e.g., "list all indices") go to fast, cost‑effective models.
- Complex reasoning (e.g., "optimize this aggregation for performance") is routed to deep‑thinking models like Claude 3.5 Sonnet via Bedrock.
- If a provider fails, we automatically fall back to the next available model—ensuring reliability.
3. Visual Blueprint Editor
We built a React Flow‑based canvas where users can design agent workflows visually. Each container represents a logical module (e.g., "Query Parser"), each beacon is a tool (e.g., "Elasticsearch Executor"), and edges define the flow. This visual approach makes agent design accessible to non‑coders while still being powerful enough for experts.
4. Extensible Tool System
At the core of Atlarix is a tool registry with 70+ built‑in tools. For this hackathon, we extended it with a suite of Elasticsearch tools:
elastic_list_indices– List all indices with metadata.elastic_get_mapping– Retrieve mapping for a specific index.elastic_search_query– Execute a search query (read‑only).elastic_analyze_query– Suggest optimizations for a given query.elastic_suggest_mapping– Generate mapping from a natural language description.elastic_generate_dashboard– Create Kibana dashboard configuration.
Each tool is wrapped with Zod validation and integrated into our permission system. When an agent invokes a tool, the user sees a clear approval modal showing exactly what will happen. Read‑only tools can be auto‑approved; write operations (like creating an index) always require explicit consent.
5. Round‑Trip Engineering (RTE) for Context
Agents are only as good as their context. Atlarix includes language‑specific parsers (TypeScript, Python) that analyze your codebase to extract:
- Data models (e.g., Mongoose schemas, TypeScript interfaces)
- API endpoints and their parameters
- Database interactions
This extracted knowledge is stored in a Blueprint cache and used to augment the agent's prompts. When you ask "design an index for my user model," the agent already knows what fields exist and their types—no manual description needed.
6. Retrieval‑Augmented Generation (RAG)
We built a RAG layer that indexes:
- Your Elasticsearch documentation (customizable)
- Past queries and their results
- The extracted Blueprint information
When the agent needs to answer a question, it first queries this knowledge base, retrieves the most relevant chunks, and injects them into the prompt. This dramatically reduces hallucinations and ensures answers are grounded in your specific context.
7. Safe Execution with Permission UI
One of Atlarix's standout features is its explicit permission system. Every tool invocation that could modify state (including Elasticsearch write operations) triggers a permission request. The user sees:
- The exact command or API call
- A diff preview (for file changes) or parameter summary (for API calls)
- Approve/Reject buttons with optional "remember my choice"
This gives developers confidence that the agent can't accidentally break things—critical for production environments.
🧗 Challenges We Faced
1. Balancing Autonomy with Safety
Early versions of Atlarix were either too restrictive (agents could barely do anything) or too permissive (users feared accidental damage). The breakthrough came when we designed the permission queue—a separate UI layer that intercepts all tool calls and presents them for approval. This gave users fine‑grained control without breaking the agent's flow.
2. Making RAG Actually Useful
Retrieval is easy; retrieval that improves answers is hard. We went through three iterations of our RAG pipeline:
- v1: Simple keyword search → too many irrelevant results.
- v2: Embedding‑based similarity → better, but still missed context.
- v3: Hybrid search (BM25 + embeddings) with reranking → finally hit the sweet spot.
We also learned to chunk documents intelligently—by code blocks for source files, by sections for documentation—so that retrieved pieces are coherent.
3. Supporting Diverse AI Providers
Each provider has its own API quirks, tool‑calling formats, and rate limits. Building a unified abstraction layer that still lets us leverage provider‑specific features (like Claude's XML tool tags or OpenAI's function calling) was a significant engineering challenge. Our solution: a provider adapter interface with common methods (chat, stream, tools) and provider‑specific implementations. New providers can be added in days, not weeks.
4. Visual Workflow Design for Non‑Linear Agents
Agents aren't always linear—they might loop, branch, or spawn sub‑agents. Representing this visually without overwhelming the user was tricky. We settled on a nested container approach: a container can contain its own sub‑graph of beacons, allowing for hierarchical workflows. Users can zoom in to see details or zoom out for the big picture.
5. Real‑Time Code Understanding
Parsing code accurately, especially across different languages and frameworks, is a monumental task. We initially tried using ANTLR4 grammars for everything but found it too slow and brittle. We pivoted to a hybrid approach: tree‑sitter for fast, incremental parsing, and ANTLR for deep analysis when needed. This gave us both speed and depth.
🎓 What We Learned
This hackathon pushed us to think deeply about how developers actually want to interact with Elasticsearch. Some key insights:
- Natural language is the interface of the future, but it must be backed by structured tools. Users love asking "show me slow queries," but they also need to see the exact Elasticsearch commands being run.
- Permission systems build trust. By showing exactly what the agent intends to do, we've seen users become more willing to delegate complex tasks.
- Visual design matters. The Blueprint editor isn't just a gimmick—it helps users reason about agent behavior in ways that code alone cannot.
- Elasticsearch expertise is in high demand. Every developer we spoke to wanted help with query optimization, mapping design, and performance tuning. An agent that can provide this assistance is genuinely valuable.
🚀 What's Next
Atlarix for Elasticsearch is just the beginning. After this hackathon, we plan to:
- Open‑source the Elasticsearch toolset so anyone can build on it.
- Create a plugin marketplace where developers can share and remix agents.
- Add more data sources (PostgreSQL, MongoDB, Redis) so agents can understand your entire stack.
- Improve the Blueprint editor with real‑time collaboration and version control.
- Launch Atlarix Cloud—a hosted version with team workspaces and enterprise features.
We believe that the future of software development is collaborative intelligence: humans and AI agents working together, each bringing their strengths. Atlarix is our contribution to that future, and this hackathon is the perfect place to share it with the Elasticsearch community.
Built with ❤️ by the NorahLabs team
Log in or sign up for Devpost to join the conversation.