RAG Is Not Enough: The Evolution of Enterprise AI

Software engineer Rajश्री argues that Retrieval-Augmented Generation (RAG) alone is insufficient for enterprise AI, as production demands shift from simple knowledge retrieval to complex software engineering tasks. The evolution from RAG to advanced RAG, agentic retrieval, and governed AI workflows marks a transition where AI engineering resembles software engineering more than prompt engineering.

Author: Rajश्री | Software Engineer & Full Stack Developer For the last few years, Retrieval-Augmented Generation RAG has become one of the most popular architectures in enterprise AI. And for good reason. A large language model may be excellent at reasoning and language generation, but it does not automatically know your company's internal policies, customer records, product documentation, support tickets, contracts, or constantly changing business data. RAG provided an elegant solution. Instead of retraining the model whenever enterprise knowledge changes, retrieve relevant information at inference time and provide it to the model as context. The architecture looked simple: User Query ↓ Retrieve Relevant Information ↓ Build Context ↓ LLM ↓ Generate Answer This was a huge step forward. A company could take its existing documentation, index it, connect a language model, and suddenly employees could ask questions about internal knowledge using natural language. But then production happened. The questions became harder. Users stopped asking only: "What is our leave policy?" They started asking: "Am I eligible for this leave based on my current employment status?" They stopped asking: "What is our refund policy?" They started asking: "Can I approve this customer's refund, and if yes, process it." They stopped asking: "What does this support document say?" They started asking: "Check the customer's account, verify the issue, determine whether they're eligible for replacement, create the ticket, and notify them." And suddenly the problem changed. This was no longer simply a knowledge retrieval problem . It became a software engineering problem . The system needed: That leads to a very important realization: RAG is not enough. Not because RAG is obsolete. Not because vector databases are useless. Not because agents have replaced retrieval. But because retrieval is only one capability of a production enterprise AI system. The real evolution looks more like: LLM ↓ RAG ↓ Advanced RAG ↓ Agentic Retrieval ↓ Tool-Using AI ↓ Stateful AI ↓ Governed AI Workflows ↓ Reliable Enterprise AI Systems And understanding this evolution is where AI engineering begins to look much more like software engineering—and much less like prompt engineering. Before discussing why RAG is not enough, we need to give RAG the credit it deserves. Large language models have an important limitation: The model's parameters are not your company's database. Imagine an employee asks: "What is our company's enterprise customer refund policy?" A general-purpose LLM may know what refund policies usually look like. But it doesn't automatically know your company's current policy . Your organization may have: Refund Policy.pdf Enterprise Customer Policy.pdf Finance Guidelines.pdf Regional Exceptions.pdf Support Documentation/ RAG creates a bridge between the model and that external knowledge. A simplified architecture looks like this: Enterprise Knowledge │ ┌─────────────┼─────────────┐ ↓ ↓ ↓ Documents Wikis Knowledge Base │ │ │ └─────────────┼─────────────┘ ↓ Chunking ↓ Embeddings ↓ Vector Database ↓ Retrieval ↓ Relevant Context ↓ LLM ↓ Answer This solved several major problems. The model can work with internal company information without that information being part of its original training data. If a policy changes, the knowledge source can be updated without retraining the model. The model can generate answers based on retrieved enterprise context rather than relying entirely on its pretrained knowledge. A well-designed system can show users which documents or records support the answer. For many knowledge-based applications, RAG is significantly simpler than fine-tuning a model for every knowledge update. So yes: RAG is extremely useful. But it solves a specific problem: "How can an LLM access relevant external knowledge?" Enterprise AI eventually asks a much larger question: "How can an AI system reliably accomplish a business objective?" Those are very different problems. This is one of the most important distinctions in enterprise AI. Imagine an employee asks: "Can I approve this refund?" A basic RAG system may retrieve: Refund Policy.pdf Customer Refund Limits.pdf Approval Guidelines.pdf The model can read them and explain the rules. But the actual question is not: "What does the refund policy say?" It is: "Given this specific customer's account, transaction amount, my role, the current approval state, and applicable regional rules, am I authorized to approve this refund?" Now look at everything the system needs: Policy + User Identity + Role + Permissions + Customer Data + Transaction Data + Current Workflow State + Business Rules + Reasoning A vector database cannot provide all of this. And an LLM should not be expected to invent it. This is the first major architectural lesson: Retrieval provides context. It does not automatically provide the complete state of the business. One of the mistakes developers make when building their first RAG system is assuming: Enterprise Knowledge = Documents Real enterprise environments are much messier. A company may have: Enterprise │ ┌───────────────┼────────────────┐ ↓ ↓ ↓ Documents Databases APIs │ │ │ ↓ ↓ ↓ Wiki CRM ERP PDFs HRMS Payments Policies Tickets Inventory Manuals Analytics Identity And these sources behave differently. A policy document is not the same thing as a customer database. A customer database is not the same thing as an API. An API response is not the same thing as a knowledge graph. A transaction table should not necessarily be embedded into a vector database simply because you're building a RAG system. This is where practical AI engineering begins. The engineer needs to ask: What kind of information is this, and what is the correct way to access it? For example: Unstructured knowledge ↓ Semantic / Hybrid Retrieval Structured business data ↓ SQL / Database Query Real-time information ↓ API Relationships ↓ Knowledge Graph Business operation ↓ Tool / API / Workflow This is a much more useful mental model than: "Let's put everything into a vector database." Suppose your RAG system is giving poor answers. A common reaction is: "Maybe it doesn't have enough information. Let's add more documents." So the team adds another 100,000 documents. Then another 500,000. Eventually the system contains: Old Policies New Policies Regional Policies Draft Policies Archived Policies Internal Notes Duplicate Documents Different Versions Conflicting Documents Now retrieval itself becomes harder. The problem was not lack of data. The problem was information quality and information architecture . A simplified failure chain looks like this: Poor Data ↓ Poor Chunking ↓ Poor Indexing ↓ Poor Retrieval ↓ Wrong Context ↓ Wrong Reasoning ↓ Wrong Answer Adding more documents doesn't necessarily improve the system. Sometimes it makes it worse. A production AI engineer therefore asks: These questions are often more important than: "Which embedding model should I use?" A simple RAG pipeline may look like: Query ↓ Embedding ↓ Vector Search ↓ Top K Chunks ↓ LLM This is useful for prototypes. But production retrieval often requires more. A stronger architecture might look like: User Query ↓ Query Understanding ↓ Intent Detection ↓ Metadata / Permission Filtering ↓ Hybrid Search ↓ Vector Retrieval + Keyword Retrieval ↓ Candidate Documents ↓ Reranking ↓ Context Selection ↓ Context Compression ↓ LLM Possible techniques include: The important point is: Better RAG is not simply "use a better vector database." Retrieval is an information architecture problem. This is where enterprise AI becomes a serious security problem. Imagine a company has: Document A → Public Document B → Engineering Document C → Finance Document D → HR Document E → Executive An employee from Engineering asks: "What was the company's executive compensation strategy?" A naive RAG system might retrieve Document E because it is semantically relevant. The LLM now has access to information that the employee should never have seen. This is not a hallucination problem. This is an authorization failure . And the solution should not be: Retrieve sensitive information ↓ Tell the LLM: "Please don't reveal it." That is not a security boundary. Authorization needs to happen before sensitive information reaches the model. A safer architecture is: User ↓ Authentication ↓ Identity / Role ↓ Authorization ↓ Allowed Data Scope ↓ Retrieval ↓ LLM This distinction is critical: The model should not be trusted to enforce access control. The application architecture must enforce it. Let's take a practical example. A customer asks: "Where is my order?" The company's documentation might explain shipping policies. RAG can answer: "Standard shipping usually takes 3–5 business days." But that's not what the customer actually wants. They want to know: "Where is my specific order right now?" That information lives in a live system. Customer ↓ AI Assistant ↓ Order Lookup Tool ↓ Order Management API ↓ Current Order Status ↓ LLM ↓ Natural Language Response Here, RAG may still be useful for explaining shipping policies. But the actual order status should come from the source of truth . This leads to a practical rule: Use retrieval for knowledge. Use systems of record for facts that must be current. Don't embed something into a vector store simply because you can. This is probably the biggest transition in enterprise AI. Early systems focused on: Question ↓ Answer Modern enterprise systems increasingly need: Intent ↓ Reason ↓ Retrieve ↓ Decide ↓ Act ↓ Verify ↓ Report Result Consider an IT support assistant. The user says: "My company laptop isn't working and it's still under warranty. Create a replacement request." A basic RAG system can explain the replacement policy. A useful enterprise AI system should potentially: Now we have: Knowledge + Live Data + Reasoning + Tools + Workflow + State + Verification That is far beyond basic RAG. Tools are one of the most important additions to enterprise AI. An AI system might have access to: Search Tool SQL Tool CRM Tool ERP Tool Email Tool Calendar Tool Ticketing Tool Payment Tool Internal API For example: "Find overdue invoices above ₹10 lakh and notify the responsible account managers." The system may need to: User Request ↓ Understand Intent ↓ Query Finance Database ↓ Filter Invoices ↓ Identify Account Managers ↓ Apply Notification Policy ↓ Send Emails ↓ Verify Delivery ↓ Return Summary RAG can provide the policy. The tools perform the work. This distinction matters: Knowledge without action has limited operational value. This is where "agentic AI" can become over-engineering. Just because an LLM can call a tool doesn't mean it should have unrestricted access to that tool. Imagine an AI agent with access to: Delete Customer Refund Payment Send Email Create Contract Modify Database Transfer Money Giving the model all of these capabilities and saying: "Use them responsibly." is not an enterprise architecture. It is a liability. Instead, actions should have explicit boundaries. For example: Low Risk ↓ Automatic Execution Medium Risk ↓ Policy Check + Validation High Risk ↓ Human Approval A refund under a small threshold might be automatic. A large financial transaction might require approval. Deleting an important customer record might require multiple controls. This is where AI governance becomes part of engineering . The word agent is now used everywhere. But an agent is not simply: LLM + Tool Calling A useful agentic system needs some concept of: Goal ↓ Planning ↓ Action ↓ Observation ↓ Evaluation ↓ Next Action For example: User: "Investigate why sales dropped last quarter." An agent might reason: 1. Query sales database. 2. Compare previous quarter. 3. Identify affected regions. 4. Check product performance. 5. Retrieve sales strategy documents. 6. Check CRM notes. 7. Identify major changes. 8. Synthesize findings. The key difference is: The system can decide what information it needs and what actions to take next. That is more powerful than a fixed RAG pipeline. But it is also harder to control. A demo agent may look impressive: LLM ↓ Tool ↓ LLM ↓ Tool ↓ LLM But what happens when the model keeps calling tools? Search ↓ Search Again ↓ Search Again ↓ Search Again ↓ Search Again You now have: A production agent needs boundaries. For example: Maximum Steps Maximum Tool Calls Maximum Runtime Token Budget Retry Limit Allowed Tools Allowed Arguments And sometimes the best engineering decision is not to use an agent at all. If the workflow is deterministic: Step 1 ↓ Step 2 ↓ Step 3 ↓ Step 4 a normal workflow engine may be safer and more predictable than an autonomous agent. This is a very important AI engineering principle: Use autonomy where uncertainty exists. Use deterministic software where determinism is possible. Another common misconception is: "AI memory means storing previous conversations." That's only one small part of the problem. Enterprise workflows often last much longer than a single conversation. Imagine an employee's hardware replacement: Monday ↓ Issue reported Tuesday ↓ Diagnostic information requested Wednesday ↓ Diagnostics uploaded Thursday ↓ Manager approval requested Friday ↓ Replacement approved The AI needs to understand the state of the workflow. Something like: { "workflow": "hardware replacement", "employee id": "EMP-4821", "device id": "LTP-8841", "status": "manager approval pending", "ticket id": "INC-29482", "last action": "approval requested" } This is not simply conversation memory. It is application state . And this distinction is important for engineers coming from traditional software development. AI systems still need the same fundamentals: AI doesn't remove software engineering. It increases the number of places where you need it. Vector search is extremely useful for semantic similarity. But semantic similarity is not the same as understanding relationships. Imagine an enterprise contains: Employee ↓ Works For ↓ Department ↓ Owns ↓ Application ↓ Processes ↓ Customer Data ↓ Governed By ↓ Policy These relationships can matter more than textual similarity. A knowledge graph can explicitly represent them. For example: Employee → belongs to → Department Department → owns → Application Application → accesses → Database Database → contains → Customer Data Customer Data → governed by → Policy Now the system can reason over relationships. This does not mean: "Knowledge graphs will replace vector databases." The more realistic architecture is often: Vector Search + Keyword Search + SQL + Knowledge Graph + APIs Different information requires different retrieval strategies. Once we combine these capabilities, the architecture becomes much more interesting. USER │ ↓ ┌─────────────────┐ │ AI Gateway │ │ Auth / Limits │ └────────┬────────┘ │ ↓ ┌─────────────────┐ │ Intent / Router │ └────────┬────────┘ │ ↓ ┌─────────────────┐ │ Planner / Agent │ └────────┬────────┘ │ ┌────────────────┼────────────────┐ ↓ ↓ ↓ Retrieval Tools Memory │ │ │ ↓ ↓ ↓ Vector / Search APIs / DB State Store │ │ │ └────────────────┼────────────────┘ ↓ ┌─────────────────┐ │ Policy Engine │ └────────┬────────┘ │ ↓ LLM / Model │ ↓ ┌─────────────────┐ │ Validator │ └────────┬────────┘ │ ↓ Business Action │ ↓ ┌─────────────────┐ │ Audit / Tracing │ └─────────────────┘ Notice something important: RAG is still there. It just isn't the entire system. This is perhaps the biggest conceptual shift for software engineers entering AI. In traditional application development, we might think: Frontend ↓ Backend ↓ Database In AI applications, beginners sometimes replace the backend with: Frontend ↓ LLM That is usually not enough. A production AI application still needs: Frontend ↓ Backend / AI Gateway ↓ Authentication ↓ Authorization ↓ Orchestration ↓ Models ↓ Retrieval ↓ Tools ↓ Databases ↓ Policies ↓ Observability The model is a component. It is not the whole application. This is why AI engineering is increasingly becoming an extension of software engineering. This is worth saying explicitly. If the user asks: "What is our remote-work policy?" RAG is a good fit. If the user asks: "What is the current balance in my account?" Use the source-of-truth system. If the user asks: "Calculate this month's revenue." Use a database or analytics system. If the user asks: "Create a support ticket." Use the ticketing API. If the user asks: "Explain why this transaction was rejected according to policy." You may need: Transaction Data + Policy Retrieval + Business Rules + Reasoning The architecture should follow the problem. Not the other way around. This leads to a simple rule: Don't force every enterprise problem into RAG. A chatbot can sometimes get away with being imperfect. Enterprise systems usually cannot. Imagine an AI assistant says: "Your refund has been processed." But the refund API failed. The response sounds perfect. The user believes the transaction happened. But it didn't. This is much worse than a poorly written answer. Therefore enterprise AI needs verification . A useful execution pattern is: Decide ↓ Execute ↓ Verify ↓ Respond For example: AI decides: "Create replacement ticket." ↓ Ticket API called. ↓ API returns: ticket id = INC-29482 ↓ System verifies: Ticket actually exists. ↓ User receives: "Replacement request created successfully. Ticket: INC-29482" The AI should not simply claim that something happened. The system should verify that it actually happened. This is another area where AI prototypes and production systems differ dramatically. A developer tests: "Ask the chatbot ten questions." If the answers look good, they conclude: "The RAG system works." That's not enough. Enterprise AI needs systematic evaluation. For retrieval: Did we retrieve the correct source? Did we retrieve enough relevant information? Did we retrieve unauthorized information? Did ranking put the best evidence first? For generation: Is the answer grounded? Is it relevant? Did it introduce unsupported claims? Did it cite the correct evidence? For agents: Did it choose the correct tool? Did it use the correct arguments? Did the tool succeed? Did it recover from failure? Did it stop when the task was complete? For business workflows: Was the actual task completed? Was policy followed? Was authorization respected? Was the final state correct? The evaluation target therefore becomes: Model Quality + Retrieval Quality + Tool Reliability + Policy Compliance + Task Completion This is much closer to traditional software testing. In a traditional backend application, when something fails, you inspect: Logs Metrics Traces Database State AI systems need the same discipline. Suppose a user receives a wrong answer. You should be able to reconstruct: User Query ↓ Detected Intent ↓ Retrieved Sources ↓ Ranking ↓ Context Sent to Model ↓ Model Decision ↓ Tools Called ↓ Tool Arguments ↓ Tool Results ↓ Policy Checks ↓ Final Response Without this information, debugging becomes: "The AI gave a weird answer." That's not engineering. A production system should make the AI's execution trace inspectable. Prompt injection gets a lot of attention—and rightly so. But enterprise AI security is much broader. Consider: User Input ↓ Prompt Injection ↓ Retrieval ↓ Sensitive Data ↓ Tool Call ↓ External System Potential risks exist at every stage. You need to consider: A useful principle is: Never treat the LLM as a trusted security boundary. The LLM can reason. The application must enforce security. A demo can take 15 seconds to answer. A production customer-support assistant may not have that luxury. Imagine a single request triggers: Query Rewrite ↓ Vector Search ↓ Keyword Search ↓ Reranking ↓ LLM Call ↓ SQL Query ↓ Another LLM Call ↓ API Call ↓ Validation ↓ Final LLM Call The system may be accurate. It may also be painfully slow and expensive. Therefore production AI engineering involves trade-offs: Accuracy ↕ Latency ↕ Cost ↕ Reliability Sometimes a smaller model is sufficient. Sometimes deterministic code is better. Sometimes retrieval can be skipped. Sometimes caching makes more sense. Sometimes an agent should be replaced with a fixed workflow. The best architecture is not the one with the most AI. It is the one that solves the business problem with the right amount of AI. We can now summarize the architectural evolution. User ↓ LLM ↓ Answer Good for: Problem: The model doesn't automatically know enterprise knowledge. User ↓ Retriever ↓ Enterprise Knowledge ↓ LLM ↓ Answer Solves: "How do we give the model private knowledge?" But not: "How does the system operate inside the business?" Query ↓ Query Understanding ↓ Hybrid Search ↓ Filtering ↓ Reranking ↓ Context Selection ↓ LLM Improves knowledge access. Still primarily focused on answering. User ↓ Planner ↓ Retrieve ↓ Evaluate ↓ Retrieve Again ↓ Reason ↓ Answer Retrieval becomes dynamic. The system decides what information it needs. AI ├── Search ├── SQL ├── CRM ├── ERP ├── Email └── Internal APIs The system can now perform operations. AI + Memory + Workflow State + History The system can participate in long-running workflows. Models + Knowledge + Tools + Memory + Permissions + Policies + Human Approval + Observability + Evaluation Now we are getting closer to production enterprise AI. If you're coming from a software engineering background and want to move into AI engineering, don't start by memorizing every AI framework. Start by learning how to design systems. A practical progression looks like this: Software Engineering Fundamentals ↓ APIs + Databases + Authentication ↓ LLM APIs ↓ Embeddings + Retrieval ↓ RAG ↓ Evaluation ↓ Tool Calling ↓ Agents / Orchestration ↓ Memory / State ↓ Security + Governance ↓ Production AI Systems This path is much more valuable than simply learning: Framework A Framework B Framework C because frameworks change. Architecture principles remain. If I were building a serious AI project to learn these concepts, I wouldn't build another: "Chat with PDF." It's useful for understanding RAG. But it doesn't demonstrate enough engineering depth. Instead, build something closer to: Imagine an internal assistant for a company. A user can say: "My laptop is slow. Check whether my device is under warranty and tell me what I should do." The system can: User ↓ Intent Detection ↓ Employee Authentication ↓ Retrieve Device Information ↓ Query Asset Database ↓ Retrieve Warranty Policy ↓ Reason About Eligibility ↓ Respond Then extend it: "Create a support ticket." Now: User ↓ AI ↓ Check Permission ↓ Create Ticket via API ↓ Verify Ticket ↓ Store Workflow State ↓ Return Ticket ID Then extend it again: "What happened to my ticket?" Now the system retrieves: Current Ticket State + Previous Actions + Relevant Policy + Conversation Context At this point you've built something much closer to a real AI system. And you've learned: That is AI engineering. This is probably the single most important lesson from all of this. Don't start with: "I want to build an agent." Start with: "What problem am I solving?" Don't start with: "Which vector database should I use?" Start with: "Where does the authoritative information live?" Don't start with: "Which LLM is the smartest?" Start with: "What capabilities does this workflow actually require?" Don't start with: "How autonomous can I make the system?" Start with: "Which decisions can safely be automated?" And don't start with: "How do I make the demo impressive?" Start with: "How do I make the system reliable?" After everything we've discussed, it would be easy to conclude: "RAG is outdated." That's the wrong conclusion. RAG is not going away. It is becoming a component . The architectural shift is: Old Mental Model Enterprise AI = LLM + Vector Database to: Modern Mental Model Enterprise AI = Model + Knowledge + Retrieval + Tools + Data + Memory + Policies + Workflows + Observability + Evaluation RAG remains one of the most important ways to provide contextual knowledge. But it no longer carries the entire responsibility. This is where the story ultimately comes together. Early AI applications were primarily designed around: "Give me an answer." RAG improved that: "Give me an answer based on my company's knowledge." Agentic systems push further: "Figure out what needs to happen." Tool-using systems go further: "Do it." Stateful systems add: "Remember where we are in the process." Governed systems add: "Do it within the rules." Production systems add: "Prove that it actually worked." So the evolution is: Answer ↓ Grounded Answer ↓ Reasoned Decision ↓ Action ↓ Stateful Workflow ↓ Governed Automation ↓ Verified Business Outcome That is the real evolution of enterprise AI. There is an interesting misconception that becoming an AI engineer means leaving software engineering behind. I don't think that's true. In fact, strong software engineering fundamentals become even more valuable. Because production AI still needs: The difference is that now one component of the system is probabilistic. And that creates a new engineering challenge. Traditional software usually aims for: Input → Deterministic Logic → Output AI systems often look more like: Input ↓ Probabilistic Reasoning ↓ Tool / System Interaction ↓ Validation ↓ Controlled Output So the engineer's job becomes designing the boundaries around that probabilistic component. That is why I believe: The future AI engineer will not be less of a software engineer. They will need to be more of one. A production AI engineer does not simply know how to call an LLM API. They think about the complete system. They ask: What is the business objective? Where is the source of truth? What information does the model need? What should be retrieved? What should be queried directly? What actions can the AI perform? Who is authorized to perform them? What happens if a tool fails? What happens if the model is wrong? What happens if the retrieved document is malicious? What happens if the agent gets stuck? What happens if the API times out? How do we verify the result? How do we evaluate the system? How do we trace a failure? How do we control cost? How do we scale it? These are not "prompt engineering" questions. They are systems engineering questions . And that is exactly where enterprise AI becomes interesting. RAG changed enterprise AI. It solved a fundamental problem: How can an LLM access knowledge that isn't contained in its training data? But enterprises eventually need more than knowledge. They need systems that can: That's why: LLM + Vector Database is not an enterprise AI architecture by itself. A more realistic architecture is: Enterprise AI │ ┌────────────────────┼────────────────────┐ ↓ ↓ ↓ Knowledge Actions State │ │ │ RAG Tools Memory │ │ │ └────────────────────┼────────────────────┘ ↓ Orchestration ↓ Reasoning ↓ Governance ↓ Verification ↓ Business Outcome ↓ Observability + Evaluation RAG isn't disappearing. It is becoming one layer of something much larger. The real evolution of enterprise AI is not: RAG → Replace RAG It is: Retrieval ↓ Reasoning ↓ Action ↓ State ↓ Governance ↓ Verification ↓ Reliable Business Workflow And perhaps the most important shift is this: The question is no longer "How do I build a better RAG chatbot?" The better question is "What business outcome should this AI system reliably accomplish, what information and tools does it need, what can go wrong, and how will I prove that it worked?" That is the point where building AI stops being about making an impressive demo. It starts becoming engineering . Models + Knowledge + Retrieval + Tools + Data + Memory + Policies + Workflows + Evaluation + Observability A vibe coder asks: "Which AI tool can I plug in?" An AI engineer asks: "What problem am I solving, what system should own the truth, what can the AI do, what must it never do, and how will I know when it is wrong?" The difference isn't the model. It's the engineering. Hi, I'm Rajshree , a Software Engineer and Full Stack Developer passionate about building modern web applications and exploring the intersection of software engineering, AI, machine learning, and intelligent systems . I enjoy turning ideas into working products, understanding how systems behave beyond the demo stage, writing about what I learn, and continuously exploring the transition from traditional software development to production-grade AI engineering . 🌐 Portfolio: https://rjshree.com https://rjshree.com 💼 LinkedIn: https://linkedin.com/in/rjshree https://linkedin.com/in/rjshree 💻 GitHub: https://github.com/rjshree https://github.com/rjshree If you enjoyed this article, follow along for more writing on software engineering, AI, technology, system architecture, and the journey from developer to AI engineer. Thanks for reading.