A RAG AI agent that's production-ready — not a weekend prototype

Retrieval-augmented generation solved one of the fundamental problems with large language models: they hallucinate. Ask an LLM a question about your company's return policy, and without retrieval, it will generate a plausible-sounding answer based on patterns it learned during pretraining — an answer that might be completely wrong for your specific business. RAG fixes this by inserting a retrieval step between the question and the generation: before the LLM produces a response, the system searches a corpus of your actual content, pulls the most relevant passages, and feeds them to the model as context. The LLM generates its answer grounded in those passages rather than from parametric memory. The result is a response that is accurate, specific, and traceable to a source. That's the theory. In practice, getting RAG to production is where most teams stall.

The architecture of a RAG system looks deceptively simple on a whiteboard. Query comes in, embeddings convert it to a vector, vector search finds the nearest chunks in a database, those chunks go into the LLM prompt, and the LLM generates a grounded answer. Five boxes, four arrows, one afternoon to sketch. But each box hides a set of engineering decisions that compounds into weeks or months of work. Which embedding model? OpenAI's ada-002, Cohere's embed-v3, an open-source model you host yourself? Where do you store the vectors? Pinecone for managed hosting, Weaviate for open source, pgvector if you want to stay in Postgres, Qdrant if you want performance at scale? How do you chunk the content? Fixed token windows, recursive character splitting, semantic segmentation based on headings, sliding windows with overlap? How much overlap? What's the chunk size? Every choice interacts with every other choice, and the "right" answer depends on your specific content, your query patterns, and your accuracy requirements.

Asyntai exists because most businesses that need RAG don't need to make those decisions. They need the outcome — an AI agent that answers questions accurately using their own content — without the infrastructure project. Asyntai is a fully managed RAG system. It crawls your website, processes uploaded documents, chunks content into semantically coherent passages, indexes them for retrieval, and at query time retrieves the most relevant passages to ground the LLM's response. You don't provision a vector database. You don't choose an embedding model. You don't write a chunking algorithm. You paste a script tag on your site, and the retrieval pipeline runs on infrastructure you never touch.

The crawling layer is the entry point to the pipeline. When you connect a domain, Asyntai's crawler follows links across your site, extracts text content from each page, and feeds it into the chunking system. It handles JavaScript-rendered pages, respects robots.txt, and re-crawls on a schedule you set so that your retrieval index stays current as your content changes. You can also upload documents directly — PDFs, Word docs, knowledge base exports — for content that lives behind authentication or isn't published on a website. The crawler is deliberately opinionated: it extracts text and structure, discards navigation chrome and boilerplate, and produces clean passages ready for chunking. You don't configure the crawler's behavior because the decisions it makes — what to extract, how to handle dynamic content, when to re-index — are the same for virtually every customer.

Chunking is where most custom RAG implementations spend disproportionate time and where subtle mistakes cause the most retrieval failures. The naive approach — split text every 500 tokens — creates chunks that cut mid-paragraph, mid-sentence, or worse, mid-concept. A passage about your return policy might be split across two chunks, with the conditions in one chunk and the timeline in another. When a customer asks "how long do I have to return an item?", the retrieval step might pull the chunk with the conditions but miss the one with the timeline, and the LLM generates an incomplete answer. Asyntai's chunking respects document structure: headings, paragraph boundaries, list items, and logical topic shifts. Each chunk is a self-contained passage that makes sense on its own — not an arbitrary slice of text. This matters more than most people realize when evaluating RAG quality, because retrieval can only be as good as what it retrieves.

The retrieval step itself is where the RAG acronym earns its keep. When a visitor asks a question, the system converts it to a vector representation and searches the index for the most semantically similar passages. Semantic search is the key differentiator from keyword search: a question like "what's the deadline for sending stuff back?" retrieves passages about "return policy" and "30-day return window" even though none of the query's exact words appear in the content. This handles the reality of how people ask questions — they don't use the same vocabulary as your documentation. Asyntai's retrieval pipeline ranks candidates by relevance and feeds the top passages to the LLM as context for generation. The model sees only these passages, not the entire index, which keeps the context window focused and reduces the chance of the model cherry-picking a tangentially related passage to support a wrong answer.

Generation grounding is the mechanism that prevents hallucination. The LLM is instructed to answer based on the retrieved passages and to explicitly acknowledge when the retrieved content doesn't contain an answer. This is an architectural constraint, not a prompt trick — the system is designed so the model operates on retrieved context rather than relying on its pretrained knowledge of your business (which is almost certainly nonexistent or outdated). When a customer asks about a product that isn't in your knowledge base, the agent says "I don't have information about that product in my knowledge base" rather than inventing specifications. When someone asks a question where the answer spans multiple topics, the agent synthesizes across retrieved passages but doesn't fill gaps with generated material. This behavior is what makes RAG trustworthy for customer-facing deployment — the boundary between "I know this because it's in the content" and "I'm guessing" is enforced by the system, not left to the model's judgment.

But here's what separates Asyntai from a textbook RAG implementation: the system doesn't stop at retrieval and generation. Most real-world customer interactions require information that doesn't live in any document. Order statuses, account balances, inventory levels, appointment availability, subscription details — this data changes by the minute and exists in your business systems, not your knowledge base. A pure RAG agent can tell a customer what your return policy is, but it can't tell them whether their specific order is eligible. It can explain your pricing tiers, but it can't tell them which plan they're on or how many messages they've used this month. For those questions, you need the agent to call your APIs — and that's what Custom Tools provide.

Custom Tools extend the RAG agent with tool-calling capability. You define a tool in your dashboard: a name, a description of when the AI should use it, your API endpoint, and the parameters the AI should extract from the conversation. When a customer's question requires live data, the agent calls your endpoint, gets the response, and combines it with retrieved knowledge base content to compose a complete answer. The return eligibility example is the canonical case: the agent retrieves your return policy from the knowledge base (RAG) and calls your order API (Custom Tool) to get the order date and item details, then synthesizes both into a specific answer — "Your order was placed 12 days ago, and your 30-day return window is still open." Neither RAG alone nor tool calling alone could produce that answer. The combination is what makes the agent genuinely useful.

This RAG-plus-tools architecture is significant because it addresses the most common criticism of RAG systems: "it can answer general questions, but it can't help me with my specific situation." That criticism is valid for RAG-only implementations. A knowledge base can tell you what a company's refund policy is, but it can't tell you whether you qualify. Custom Tools bridge that gap by connecting the agent to live data sources. The RAG layer handles the "what are the rules?" questions. The tool layer handles the "what's my situation?" questions. The agent handles the composition. For the customer, it all looks like one conversation with one agent that knows their policies and their data.

User Context adds a third data layer that further differentiates a managed RAG agent from a from-scratch implementation. Through a JavaScript API, you push known information about the logged-in visitor — their name, email, customer segment, plan tier, recent purchases — into the widget before the conversation starts. The agent uses this context to personalize responses and skip the "can I have your order number?" back-and-forth. A logged-in customer asking "when does my plan renew?" gets an immediate answer because the agent already has their identity and can call the right API. Without User Context, the agent would need to ask for identifying information, verify it, and then make the tool call — adding friction to every interaction. With it, the RAG agent feels like it already knows the customer.

The multilingual dimension of RAG is another area where a managed system significantly outperforms a custom build. Asyntai's retrieval pipeline supports cross-lingual query matching — a question asked in German retrieves relevant passages from an English knowledge base because the semantic representation captures meaning independent of language. The generation layer then composes the response in the visitor's language. You maintain one knowledge base in your primary language, and the RAG agent serves visitors in 36 supported languages. Building this in a custom pipeline means either maintaining parallel knowledge bases in every language (expensive, fragile, always out of sync) or implementing a translation layer in the retrieval pipeline (complex, latency-sensitive, and another failure point). The managed approach just handles it.

Smart escalation is the safety net that makes a RAG agent suitable for production customer support. No retrieval system has perfect coverage, and no set of tools covers every scenario. When the agent encounters a question outside its knowledge base and tools — or when it hits a boundary you've defined, like "never approve refunds over $200 without human review" — it captures the customer's information, the full conversation history, and any data it retrieved, then routes everything to your team. The escalation includes the retrieved passages and tool call results, so your human agent sees exactly what the AI found and where it stopped. This means your team handles only the cases that genuinely require human judgment, with full context, rather than starting every escalated conversation from scratch.

The engineering effort saved by a managed RAG agent compounds over time. A custom pipeline requires ongoing maintenance: embedding model updates when the provider releases a new version, vector database scaling as your content grows, chunking adjustments when you restructure your site, monitoring for retrieval quality degradation, prompt engineering when the LLM's behavior shifts. Each of these is a small project individually, but they accumulate into a significant operational burden. A managed RAG agent absorbs all of this. The crawling, chunking, embedding, indexing, retrieval, generation, and serving infrastructure is maintained by the platform. You maintain your content — the words on your website and the documents in your knowledge base. The RAG pipeline turns that content into an agent without ongoing engineering from your team.

The question of when to build versus when to buy a RAG implementation comes down to differentiation. If your RAG pipeline is your product — if you're building a search engine, a research tool, or a platform where retrieval quality is the core competitive advantage — then you need custom embeddings, custom re-ranking, custom chunking, and full control over every layer. If RAG is a means to an end — you need an AI agent that answers customer questions accurately using your content, and you want it deployed this week — then a managed RAG agent is the pragmatic choice. You skip the infrastructure project, skip the embedding model evaluation, skip the vector database provisioning, skip the chunking experiments, and get a production-ready RAG agent with tool calling, personalization, multilingual support, and escalation built in.

The gap between a working RAG prototype and a production RAG deployment is where most teams lose momentum. The prototype works in a notebook: you embed a few documents, query a local vector store, get reasonable answers. Then reality sets in. How do you keep the index current when content changes? How do you handle documents that are too large for a single chunk? What about tables, images with text, PDFs with complex layouts? How do you serve the retrieval pipeline at low latency for concurrent users? How do you handle content in multiple languages? What about queries that require data not in any document? Each question spawns a sub-project, and the RAG agent that was supposed to be deployed in two weeks is now a quarter-long initiative. Asyntai collapses that timeline because every one of those sub-projects is solved at the infrastructure level. You don't encounter the questions because the answers are built into the platform.

Production RAG isn't just retrieval and generation — it's retrieval, generation, tool calling, personalization, escalation, multilingual support, analytics, and a chat interface, all working together in a system that handles real customer conversations at scale. That's the stack Asyntai provides. Your content goes in. Grounded, accurate, actionable answers come out. The retrieval-augmented generation pipeline runs in the background, invisible to both you and your visitors, doing the thing that RAG was always supposed to do: making an AI agent that tells the truth.