WEBVTT 00:00:00.000 --> 00:00:01.760 You know, the modern software development landscape, 00:00:02.480 --> 00:00:04.759 it's this profound paradox of choice. Everywhere 00:00:04.759 --> 00:00:06.580 you look, there's a new tool, a new framework 00:00:06.580 --> 00:00:08.759 they all promise to revolutionize everything. 00:00:09.019 --> 00:00:12.140 And it can leave you feeling, well, confused, 00:00:12.539 --> 00:00:15.820 genuinely stressed by just the sheer number of 00:00:15.820 --> 00:00:17.359 options, especially when you're trying to build 00:00:17.359 --> 00:00:19.460 with AI. It really is that feeling of always 00:00:19.460 --> 00:00:22.000 chasing the next shiny object. So our mission 00:00:22.000 --> 00:00:24.160 in this deep dive is to just cut through that 00:00:24.160 --> 00:00:26.539 noise entirely. We're going to have to synthesize 00:00:26.539 --> 00:00:30.280 a complete integrated text. a set of tools that's 00:00:30.280 --> 00:00:33.740 been rigorously tested for over a year, and it's 00:00:33.740 --> 00:00:35.979 focused completely on building applications with 00:00:35.979 --> 00:00:38.409 AI first. So this isn't just a list, it's more 00:00:38.409 --> 00:00:41.229 of a battle -tested blueprint for creating, say, 00:00:41.350 --> 00:00:44.670 robust AI agents or scalable ARG systems. Exactly. 00:00:44.929 --> 00:00:47.170 And the core philosophy is simple. Focus on what 00:00:47.170 --> 00:00:49.350 a tool enables you to do, not just the tool itself. 00:00:49.710 --> 00:00:52.229 We're all about solving real problems, not chasing 00:00:52.229 --> 00:00:54.909 micro -trends. So we'll start with the non -negotiable 00:00:54.909 --> 00:00:57.509 foundations databases, caching, then move into 00:00:57.509 --> 00:01:00.009 the specialized stacks for agents and ARRAG, 00:01:00.070 --> 00:01:02.289 and we'll finish with deployment and some really 00:01:02.289 --> 00:01:05.049 powerful local tools. Okay, let's dive into that 00:01:05.049 --> 00:01:07.680 foundational layer. The application's main filing 00:01:07.680 --> 00:01:10.219 cabinet, the database. It seems like we're shifting 00:01:10.219 --> 00:01:12.719 back to a classic choice here. It's the big SQL 00:01:12.719 --> 00:01:15.379 comeback. Yeah. We're seeing PostgreSQL, usually 00:01:15.379 --> 00:01:17.980 through managed services like Neon or SuperBase, 00:01:18.280 --> 00:01:21.260 really become the standard for new AI apps. But 00:01:21.260 --> 00:01:24.159 why the hard pivot back to SQL? Yeah. I mean, 00:01:24.379 --> 00:01:27.719 for years, NoSQL, things like MongoDB or Firestore, 00:01:28.019 --> 00:01:30.040 they kind of dominated the startup scene because 00:01:30.040 --> 00:01:32.620 they were so flexible. Right, but this is a crucial 00:01:32.620 --> 00:01:35.099 shift for an AI -first stack. Large language 00:01:35.099 --> 00:01:38.540 models just, they understand structured relational 00:01:38.540 --> 00:01:42.019 data extremely well. So when you ask an LLM to 00:01:42.019 --> 00:01:44.219 write a query to go get some data, it does a 00:01:44.219 --> 00:01:46.939 brilliant job with SQL. And that switch... It 00:01:46.939 --> 00:01:49.659 just dramatically simplifies that whole interaction 00:01:49.659 --> 00:01:52.120 layer between the AI and your data. So the LLM 00:01:52.120 --> 00:01:54.260 is basically acting as this sophisticated query 00:01:54.260 --> 00:01:56.159 generator that just happens to be fluent and 00:01:56.159 --> 00:01:58.120 post -graspable. That's a huge performance benefit. 00:01:58.439 --> 00:02:00.939 Exactly. And speaking of foundational tools, 00:02:01.019 --> 00:02:03.739 you need that short -term memory for speed, right? 00:02:03.819 --> 00:02:06.719 Caching. Redis is still the industry standard 00:02:06.719 --> 00:02:09.479 there for just lightning fast lookups. Now, if 00:02:09.479 --> 00:02:11.460 you're building an entirely open source stack 00:02:11.460 --> 00:02:13.819 and you need to run everything locally, its drop 00:02:13.819 --> 00:02:18.099 -in equivalent is Valky. But using Redis, that 00:02:18.099 --> 00:02:21.199 introduces a dependency on one vendor, even if 00:02:21.199 --> 00:02:23.879 it is an industry standard. Does Valky sort of 00:02:23.879 --> 00:02:26.199 mitigate that risk for teams that are really 00:02:26.199 --> 00:02:28.419 focused on an open source architecture? Absolutely. 00:02:28.500 --> 00:02:30.620 For enterprise level stuff, Redis is often fine. 00:02:30.800 --> 00:02:33.159 But Valky gives you that freedom, that true self 00:02:33.159 --> 00:02:35.659 -hostability, which is vital for a lot of large 00:02:35.659 --> 00:02:38.120 scale open source projects. OK, so moving into 00:02:38.120 --> 00:02:40.879 the actual building process. The most consistently 00:02:40.879 --> 00:02:42.960 used tool in the source material seems to be 00:02:42.960 --> 00:02:46.159 the AI coding assistant, Quad. paired with your 00:02:46.159 --> 00:02:48.759 open source project, Archon. Oh, Claude is probably 00:02:48.759 --> 00:02:51.419 open on my machine more than my IDE. And yeah, 00:02:51.539 --> 00:02:53.580 Archon is just a set of open source scripts and 00:02:53.580 --> 00:02:55.939 guidelines. It helps you manage your API keys, 00:02:56.120 --> 00:02:57.759 usage rates, and context windows when you're 00:02:57.759 --> 00:02:59.400 dealing with big models like Claude. It just 00:02:59.400 --> 00:03:01.819 keeps the whole process clean. The key here isn't 00:03:01.819 --> 00:03:04.120 just using Claude, though. It's how you use it. 00:03:04.479 --> 00:03:06.819 Precisely. We have to move beyond these vague 00:03:06.819 --> 00:03:09.219 requests. So instead of asking, how do I make 00:03:09.219 --> 00:03:12.439 a button? You ask for a specific React component, 00:03:12.580 --> 00:03:15.699 call it PrimaryButton, that uses Tailwind CSS 00:03:15.699 --> 00:03:19.199 for styling, accepts three specific props for 00:03:19.199 --> 00:03:22.520 text and clicks, and includes a precise hover 00:03:22.520 --> 00:03:25.520 effect. The accuracy of the ask really dictates 00:03:25.520 --> 00:03:27.520 the quality of the result. You're tailoring the 00:03:27.520 --> 00:03:30.180 AI to fit right into your existing stack immediately. 00:03:30.780 --> 00:03:33.319 But before you even commit to code, prototyping 00:03:33.319 --> 00:03:36.909 is recommended using a no -code tool. Yeah, think 00:03:36.909 --> 00:03:39.650 of NAN like visually stacking Lego blocks to 00:03:39.650 --> 00:03:41.990 test out your logic. It's perfect for quickly 00:03:41.990 --> 00:03:44.330 mocking up an AI agent idea, checking if a tool 00:03:44.330 --> 00:03:46.830 works, or testing system prompts before you invest 00:03:46.830 --> 00:03:49.270 any time writing production code. Plus, it's 00:03:49.270 --> 00:03:51.349 open source and self -hostable, so it's a great 00:03:51.349 --> 00:03:53.370 risk -free step in the middle. So just to circle 00:03:53.370 --> 00:03:56.409 back, since LLMs prefer SQL, Does that mean NoSQL 00:03:56.409 --> 00:03:59.250 databases are functionally dead for new AI projects? 00:03:59.389 --> 00:04:02.889 No, but SQL, like PostgreSQL, simplifies LLM 00:04:02.889 --> 00:04:05.610 data interaction dramatically. It's a huge productivity 00:04:05.610 --> 00:04:07.750 boost. That definitely provides some clarity. 00:04:08.150 --> 00:04:10.270 Let's move from the foundation into the core 00:04:10.270 --> 00:04:13.289 stack for AI agents themselves, how we build 00:04:13.289 --> 00:04:15.889 and manage them. OK, so for the frameworks, you 00:04:15.889 --> 00:04:17.910 have to distinguish between the individual agent 00:04:17.910 --> 00:04:21.889 and the coordinator. For the individual agents, 00:04:21.910 --> 00:04:26.120 the workers, the choice is Pydantic AI. And why 00:04:26.120 --> 00:04:29.160 Pydantic AI? There are so many wrapper frameworks 00:04:29.160 --> 00:04:31.920 out there. Pydantic AI offers maximum control 00:04:31.920 --> 00:04:34.040 without what we call abstraction -distraction. 00:04:34.579 --> 00:04:36.459 A lot of frameworks make you fight their own 00:04:36.459 --> 00:04:38.639 complex rules just to get basic stuff working. 00:04:39.040 --> 00:04:41.540 Pydantic AI gives you the flexibility to build 00:04:41.540 --> 00:04:43.720 reliable agents without the tool getting in your 00:04:43.720 --> 00:04:46.220 way. Right. And once you have those capable individual 00:04:46.220 --> 00:04:48.040 agents, you might need a central manager. Yeah. 00:04:48.259 --> 00:04:50.259 And that's where LandGraph comes in. Yep. LandGraph 00:04:50.259 --> 00:04:53.060 connects multiple Pydantic AI agents for those 00:04:53.060 --> 00:04:55.800 more complex multi -agent systems. It's built 00:04:55.800 --> 00:04:58.199 to manage the state, tracking what's happening 00:04:58.199 --> 00:05:00.199 across agents. and making sure they follow a 00:05:00.199 --> 00:05:02.860 workflow. But the critical advice from the source 00:05:02.860 --> 00:05:06.620 is, don't over -engineer. Only use multi -agent 00:05:06.620 --> 00:05:09.000 systems when you really need to. Start simple. 00:05:09.339 --> 00:05:12.660 Managing complexity is the priority. Got it. 00:05:13.199 --> 00:05:15.579 Now let's talk security, especially when these 00:05:15.579 --> 00:05:17.620 agents are interacting with sensitive user accounts 00:05:17.620 --> 00:05:20.560 like Gmail or Slack. We need a security guard. 00:05:20.730 --> 00:05:23.370 Tool authorization is essential. We use Arcade 00:05:23.370 --> 00:05:26.769 for that. It acts as the security guard, automatically 00:05:26.769 --> 00:05:29.589 handling the secure Outh and permissions. So 00:05:29.589 --> 00:05:31.930 when your agent needs permission to read a user's 00:05:31.930 --> 00:05:34.470 inbox, Arcade makes sure that whole process is 00:05:34.470 --> 00:05:36.550 secure and the permissions are really detailed. 00:05:36.649 --> 00:05:38.670 There aren't many alternatives that do it so 00:05:38.670 --> 00:05:40.910 seamlessly. OK, and once the agents are deployed, 00:05:41.350 --> 00:05:43.009 knowing if they're actually working efficiently 00:05:43.009 --> 00:05:46.240 is critical. That brings us to observability 00:05:46.240 --> 00:05:49.439 with LangFuse. Observability is just non -negotiable 00:05:49.439 --> 00:05:51.139 in production. You have to be able to see what 00:05:51.139 --> 00:05:53.399 your agents are doing. LangFuse monitors, token 00:05:53.399 --> 00:05:56.879 usage, total cost, latency, all the tool calls. 00:05:57.639 --> 00:06:00.240 I still wrestle with prompt drift myself. Without 00:06:00.240 --> 00:06:03.079 LangFuse, debugging agents in production is almost 00:06:03.079 --> 00:06:05.220 impossible. Hold on. For listeners who might 00:06:05.220 --> 00:06:08.740 be new to production AI, what exactly is prompt 00:06:08.740 --> 00:06:11.579 drift? Prompt drift is when an agent, over many, 00:06:11.579 --> 00:06:13.959 many runs, starts to deviate from its original 00:06:13.959 --> 00:06:16.660 instructions or it behaves unpredictably. And 00:06:16.660 --> 00:06:18.639 that usually leads to a drop in performance. 00:06:19.160 --> 00:06:20.939 Langfuse is really the only way you can catch 00:06:20.939 --> 00:06:24.040 that early. So for a beginner, is observability 00:06:24.040 --> 00:06:26.279 really necessary right from the start or is that 00:06:26.279 --> 00:06:28.939 something you can just layer on later? Yes, because 00:06:28.939 --> 00:06:31.540 monitoring cost and latency is essential early 00:06:31.540 --> 00:06:34.600 on. You really don't want unexpected bills. That's 00:06:34.600 --> 00:06:37.230 a very practical motivation. Let's pivot now 00:06:37.230 --> 00:06:39.810 to ARGI Retrieval Augmented Generation, which 00:06:39.810 --> 00:06:42.769 is how we give the AI that open book exam to 00:06:42.769 --> 00:06:44.850 make sure its answers are factual. Right. And 00:06:44.850 --> 00:06:47.629 the first step in ARGI is clean data extraction. 00:06:48.430 --> 00:06:50.699 The decision here is pretty simple. If you're 00:06:50.699 --> 00:06:53.339 dealing with complex documents like PDFs, Excel 00:06:53.339 --> 00:06:56.240 files, you use Dockling. It's a great framework 00:06:56.240 --> 00:06:58.660 for pulling clean data out of messy, structured 00:06:58.660 --> 00:07:01.000 files. And for websites? For web data, you use 00:07:01.000 --> 00:07:04.160 Crawl4 .ai. It's fast, really efficient, and 00:07:04.160 --> 00:07:06.199 it automatically handles that crucial step of 00:07:06.199 --> 00:07:08.720 cleaning up all the junk, the ads, the navigation 00:07:08.720 --> 00:07:11.019 menus, so you're left with just the core content 00:07:11.019 --> 00:07:14.339 for the AI to ingest. So, Dockling for files, 00:07:14.500 --> 00:07:16.939 Crawl4 .ai for the web. This brings us back to 00:07:16.939 --> 00:07:19.319 the Vector database. It searches for similar 00:07:19.319 --> 00:07:22.370 concepts and meaning, not just exact words, and 00:07:22.370 --> 00:07:24.370 the sources recommend sticking with Postgresql 00:07:24.370 --> 00:07:26.970 and the PG Vector extension. Why would you skip 00:07:26.970 --> 00:07:29.850 a dedicated, faster vector database, like, say, 00:07:30.069 --> 00:07:33.279 Pinecone or Qdrant? This is a really pivotal 00:07:33.279 --> 00:07:35.519 architectural decision. Most our RAID systems, 00:07:35.860 --> 00:07:37.860 they need both a normal SQL database for user 00:07:37.860 --> 00:07:41.000 data and a vector database. By using Postgres 00:07:41.000 --> 00:07:43.319 with PG Vector, you only have to manage one scalable 00:07:43.319 --> 00:07:45.980 database instead of two separate systems. The 00:07:45.980 --> 00:07:48.899 slight speed tradeoff is just. It's overwhelmingly 00:07:48.899 --> 00:07:51.680 balanced by the huge savings in development time 00:07:51.680 --> 00:07:54.560 and maintenance headaches. Simplicity wins. So 00:07:54.560 --> 00:07:56.699 the tradeoff is really about developer efficiency 00:07:56.699 --> 00:07:58.959 and maintenance. That's a very pragmatic choice 00:07:58.959 --> 00:08:01.879 for a battle -tested stack. Absolutely. and that 00:08:01.879 --> 00:08:04.540 simple unified architecture. It also supports 00:08:04.540 --> 00:08:07.339 long -per -memory through a tool called mem0. 00:08:07.540 --> 00:08:10.139 Mem0 is a framework that turns that PG vector 00:08:10.139 --> 00:08:12.600 database into the agent's memory bank, which 00:08:12.600 --> 00:08:14.920 lets it recall previous conversations or user 00:08:14.920 --> 00:08:16.879 preferences over time. Now here's where it gets 00:08:16.879 --> 00:08:19.579 interesting. Knowledge graphs. This is an advanced 00:08:19.579 --> 00:08:22.980 technique using Neo4j and graffiti. Right. A 00:08:22.980 --> 00:08:25.459 vector database finds similar text in a document. 00:08:26.000 --> 00:08:28.240 A knowledge graph finds relationships between 00:08:28.240 --> 00:08:30.949 different pieces of data. It's fantastic for 00:08:30.949 --> 00:08:33.169 complex reasoning queries like, who worked with 00:08:33.169 --> 00:08:35.730 Steve Jobs at Apple after 2010 who also founded 00:08:35.730 --> 00:08:38.789 their own company? Neo4j is the dedicated graph 00:08:38.789 --> 00:08:41.730 database for that. But how does the AI process 00:08:41.730 --> 00:08:44.090 and store that relational data in the first place? 00:08:44.429 --> 00:08:46.789 That's where Grokkity comes in. It helps the 00:08:46.789 --> 00:08:49.269 LLM structure plaintext by identifying these 00:08:49.269 --> 00:08:51.909 subject -verb -object triples. It's basically 00:08:51.909 --> 00:08:54.250 mapping entities and their relationships accurately 00:08:54.250 --> 00:08:56.070 so they can be stored in the graph. It takes 00:08:56.070 --> 00:08:59.029 you far beyond simple keyword searching. Whoa. 00:08:59.279 --> 00:09:02.460 Imagine a single AI agent connecting a knowledge 00:09:02.460 --> 00:09:04.980 graph to understand complex hierarchies, then 00:09:04.980 --> 00:09:07.000 fetching a real -time price using BraveSearch 00:09:07.000 --> 00:09:09.279 and scoring its own faithfulness with Ragas. 00:09:09.639 --> 00:09:11.580 That's some serious power being managed there. 00:09:11.820 --> 00:09:14.899 That brings us right to quality control. RAGAS. 00:09:15.139 --> 00:09:17.899 You can't optimize what you don't measure. RAGAS 00:09:17.899 --> 00:09:20.860 scores your ARGI system based on specific metrics 00:09:20.860 --> 00:09:23.899 like faithfulness, which means is the answer 00:09:23.899 --> 00:09:26.860 actually verifiable in the source material, and 00:09:26.860 --> 00:09:28.860 relevance to the user's question. It's really 00:09:28.860 --> 00:09:31.259 specialized for measuring ARGI performance. And 00:09:31.259 --> 00:09:34.019 finally, when the agent needs current, real -time 00:09:34.019 --> 00:09:36.990 facts from the internet, what's the choice? The 00:09:36.990 --> 00:09:40.490 Brave Search API. It's privacy -focused, it doesn't 00:09:40.490 --> 00:09:42.870 track you, and crucially, it maintains its own 00:09:42.870 --> 00:09:45.429 independent search index. This gives the agent 00:09:45.429 --> 00:09:48.009 fresh, unbiased information when it needs current 00:09:48.009 --> 00:09:50.750 context, making sure that open book exam is always 00:09:50.750 --> 00:09:52.950 up -to -date. So if dedicated vector databases 00:09:52.950 --> 00:09:56.429 are significantly faster, why accept that speed 00:09:56.429 --> 00:09:58.690 trade -off for architectural simplicity? Because 00:09:58.690 --> 00:10:01.649 managing one scalable database, Postgresql, saves 00:10:01.649 --> 00:10:04.070 monumental development and operational time. 00:10:04.669 --> 00:10:06.480 Welcome back to the Deep Dive. We've covered 00:10:06.480 --> 00:10:08.840 the foundational architecture, agent frameworks, 00:10:09.100 --> 00:10:11.799 and RA systems. Now we're shifting into the final 00:10:11.799 --> 00:10:14.840 rapid segment, web automation, full stack choices, 00:10:15.100 --> 00:10:17.659 and essential local dev tools. OK, let's start 00:10:17.659 --> 00:10:20.379 with automation. This part is about agents that 00:10:20.379 --> 00:10:23.360 actually control a browser. You know, clicking 00:10:23.360 --> 00:10:26.340 buttons, filling out forms, navigating complex 00:10:26.340 --> 00:10:29.360 UIs, not just reading data. For deterministic, 00:10:29.600 --> 00:10:32.000 predictable, step -by -step scripting, Playwright 00:10:32.000 --> 00:10:34.539 is still the industry standard. It's super reliable 00:10:34.539 --> 00:10:37.200 for that kind of scripted automation. But where 00:10:37.200 --> 00:10:39.840 does the AI truly take control of the browser? 00:10:40.080 --> 00:10:42.620 That's browser -based. And this is powerful. 00:10:42.960 --> 00:10:45.120 You give the agent a natural language task like, 00:10:45.460 --> 00:10:47.399 log into my account and download the monthly 00:10:47.399 --> 00:10:49.639 statement. And browser -based controls a secure 00:10:49.639 --> 00:10:52.059 browser environment to complete it. All the sessions 00:10:52.059 --> 00:10:54.360 are recorded for debugging, and it has built 00:10:54.360 --> 00:10:57.059 -in anti -bot detection, which is vital when 00:10:57.059 --> 00:10:59.059 you're scraping or interacting with modern websites. 00:10:59.519 --> 00:11:01.899 Okay, shifting to the full stack. Given the agents 00:11:01.899 --> 00:11:04.740 are Python -based, what's powering the API layer? 00:11:04.940 --> 00:11:08.299 Fast API. It's a modern high -performance API 00:11:08.299 --> 00:11:11.299 framework in Python. It's just faster and cleaner 00:11:11.299 --> 00:11:13.899 than older alternatives like Flask, and it keeps 00:11:13.899 --> 00:11:15.860 your stack cohesive since the agents are already 00:11:15.860 --> 00:11:18.559 in Python. And then on the front end, the recommendation 00:11:18.559 --> 00:11:21.779 is React with simple, fast, and importantly, 00:11:22.080 --> 00:11:24.320 AI coding assistants have massive training data 00:11:24.320 --> 00:11:26.940 on React, so code generation is highly reliable. 00:11:27.259 --> 00:11:29.419 And for styling, it's that standard component 00:11:29.419 --> 00:11:32.120 set of Shadulation running on Tailwind CSS. Yeah. 00:11:32.250 --> 00:11:35.429 That combo makes building beautiful UIs really 00:11:35.429 --> 00:11:38.049 fast. But here's an interesting specialized tool, 00:11:38.509 --> 00:11:41.269 Lovable. Claude is great for logic and code structure, 00:11:41.710 --> 00:11:44.070 but Lovable is an AI agent that's specifically 00:11:44.070 --> 00:11:46.590 optimized for generating beautiful, aesthetically 00:11:46.590 --> 00:11:49.090 pleasing user interfaces. Its training is all 00:11:49.090 --> 00:11:51.250 about design patterns, so it fills that gap where 00:11:51.250 --> 00:11:54.090 general LLMs often fail on visual detail. And 00:11:54.090 --> 00:11:56.289 before committing to that full React build, the 00:11:56.289 --> 00:11:58.409 source really stresses using Streamlit first. 00:11:58.620 --> 00:12:01.919 Streamlit is the ultimate rapid UI prototyping 00:12:01.919 --> 00:12:04.679 tool. It lets you build a full interactive UI 00:12:04.679 --> 00:12:07.919 like a test chat box or data dashboard directly 00:12:07.919 --> 00:12:10.600 in Python with minimal code. It's the easiest 00:12:10.600 --> 00:12:12.720 way to test your agent's functionality and user 00:12:12.720 --> 00:12:15.120 experience before you graduate to the complexity 00:12:15.120 --> 00:12:17.620 of a full React app. In terms of infrastructure, 00:12:17.740 --> 00:12:20.879 we have three clear choices. Docker, Render, 00:12:21.120 --> 00:12:24.480 and GitHub Actions. Right. Docker solves that 00:12:24.480 --> 00:12:27.039 ancient, it -works -on -my -machine problem by 00:12:27.039 --> 00:12:29.460 packaging your app into a guaranteed container. 00:12:30.200 --> 00:12:32.480 Render is the simplest PaaS, or platform -as 00:12:32.480 --> 00:12:34.720 -a -service, for deployment. It lets you define 00:12:34.720 --> 00:12:37.419 your infrastructure as code, which we love. We 00:12:37.419 --> 00:12:39.379 prioritize its simplicity over the complexity 00:12:39.379 --> 00:12:41.480 of something like Kubernetes just for speed and 00:12:41.480 --> 00:12:43.899 ease of maintenance. And GitHub Action serves 00:12:43.899 --> 00:12:46.539 as the CICD automation robot. Can you clarify 00:12:46.539 --> 00:12:48.740 that a bit? Yeah, CICD stands for Continuous 00:12:48.740 --> 00:12:51.559 Integration Continuous Deployment. GitHub Actions 00:12:51.559 --> 00:12:53.639 is just the automation layer that handles all 00:12:53.639 --> 00:12:55.299 the automated testing and deployment when you 00:12:55.299 --> 00:12:58.139 push new code. And on top of that, we use CodeRabbit 00:12:58.139 --> 00:13:00.919 for automated AI code review, which specifically 00:13:00.919 --> 00:13:03.440 checks for AI -generated code inconsistencies, 00:13:03.740 --> 00:13:05.639 which is something traditional bots often miss. 00:13:06.000 --> 00:13:08.820 Finally, for privacy local experimentation, what's 00:13:08.820 --> 00:13:12.019 the game changer tool? Olamma. This tool makes 00:13:12.019 --> 00:13:15.559 it so simple to run any open source large language 00:13:15.559 --> 00:13:18.720 model like Olamma 3 or Mistral on your own local 00:13:18.720 --> 00:13:21.320 machine. Before Olamma, running these models 00:13:21.320 --> 00:13:24.200 was technically complex, you needed deep system 00:13:24.200 --> 00:13:27.000 knowledge. Now it's a simple, reliable command 00:13:27.000 --> 00:13:29.220 line interface. It really changed the game for 00:13:29.220 --> 00:13:31.960 local experimentation and privacy. And alongside 00:13:31.960 --> 00:13:34.679 Olamma, you'd use OpenWebUI, which is a local 00:13:34.679 --> 00:13:37.259 self -hosted version of the chat GPT interface. 00:13:37.639 --> 00:13:40.779 And maybe SIRXNG for local web search that aggregates 00:13:40.779 --> 00:13:43.299 results without relying on external APIs, perfect 00:13:43.299 --> 00:13:45.860 for running fully private RAG agents. So let's 00:13:45.860 --> 00:13:48.240 synthesize the major takeaways from this highly 00:13:48.240 --> 00:13:50.779 focused proven stack. First, AI first is the 00:13:50.779 --> 00:13:53.320 future. It's not an add -on. It defines how software 00:13:53.320 --> 00:13:56.139 is going to be architected. Second, focus rigorously 00:13:56.139 --> 00:13:58.679 on capabilities over chasing new tools. Solve 00:13:58.679 --> 00:14:01.240 the problem first. Third, and this is big, start 00:14:01.240 --> 00:14:03.940 simple. Use Streamlit before React. Use a single 00:14:03.940 --> 00:14:05.960 agent before you bring in LandGraph. And most 00:14:05.960 --> 00:14:08.820 critically, find what works, like this stable 00:14:08.809 --> 00:14:11.870 set of choices and minimize the time spent just 00:14:11.870 --> 00:14:14.789 jumping between different tools. This stack really 00:14:14.789 --> 00:14:17.669 provides a clear, reliable reference point when 00:14:17.669 --> 00:14:19.929 you feel that initial overwhelm. It is stable, 00:14:20.169 --> 00:14:22.629 it's reliable, and it's tested for AI -first 00:14:22.629 --> 00:14:25.350 development in 2026. Use it as your clear reference 00:14:25.350 --> 00:14:27.669 guide. And to leave you with one final thought 00:14:27.669 --> 00:14:30.309 to mull over. While retrieval -augmented generation 00:14:30.309 --> 00:14:32.990 gives agents basic facts, the true complexity 00:14:32.990 --> 00:14:35.269 and potential of knowledge graphs, powered by 00:14:35.269 --> 00:14:38.809 tools like Neo4j, go far beyond simple document 00:14:38.809 --> 00:14:41.669 retrieval. It's the key to modeling, querying, 00:14:41.970 --> 00:14:44.029 and truly understanding these highly complex, 00:14:44.230 --> 00:14:46.009 multi -layered relationships that are hidden 00:14:46.009 --> 00:14:48.190 within massive corporate or scientific datasets. 00:14:48.649 --> 00:14:50.409 That might just be the next great frontier for 00:14:50.409 --> 00:14:51.789 the most advanced autonomous agents.