WEBVTT 00:00.080 --> 00:07.960 This slide introduces the central theme of this section, moving from impressive agent demos to systems 00:07.960 --> 00:10.000 that actually work in production. 00:10.560 --> 00:17.920 Many AI agents look powerful in controlled demonstrations, but fail when exposed to real world complexity, 00:18.680 --> 00:20.600 as highlighted on the opening slide. 00:20.920 --> 00:27.920 This gap exists because production environments demand reliability, safety, and human accountability. 00:28.600 --> 00:35.920 This section focuses on three pillars that separate toy agents from practical ones task decomposition, 00:36.080 --> 00:39.120 long term memory, and human in the loop control. 00:39.560 --> 00:41.360 These are not optional enhancements. 00:41.640 --> 00:47.320 They are foundational requirements for systems that operate autonomously in real organizations. 00:47.880 --> 00:54.560 The visuals on this slide reinforce the idea of agents as working systems embedded in real environments, 00:54.720 --> 00:56.600 not isolated experiments. 00:57.240 --> 01:03.750 Building production ready agents requires engineering discipline, not just clever prompts or large 01:03.750 --> 01:04.350 models. 01:04.510 --> 01:11.750 Throughout this section, we will focus on design decisions that earn trust, making behavior predictable, 01:12.030 --> 01:15.550 failures recoverable, and control transparent. 01:16.270 --> 01:23.190 The goal is not maximum autonomy at all costs, but dependable collaboration between humans and AI. 01:23.590 --> 01:30.750 This slide explains why so many agent projects fail after deployment, as described on page two. 01:31.110 --> 01:37.630 The gap between demo and production usually comes down to three design flaws over automation without 01:37.630 --> 01:43.950 safety rails, poorly designed memory systems, and insufficient human oversight at critical decision 01:43.950 --> 01:44.510 points. 01:44.990 --> 01:49.270 Over automation leads agents to act beyond their reliability envelope. 01:49.630 --> 01:55.310 Poor memory design causes agents to lose context or accumulate irrelevant noise. 01:55.710 --> 01:59.710 Lack of oversight removes accountability when things go wrong. 02:00.390 --> 02:04.220 The slide introduces three guiding principles for practical agents. 02:04.220 --> 02:07.660 Reliability, observability and controllability. 02:08.060 --> 02:12.620 Reliability ensures the agent behaves consistently even in edge cases. 02:12.940 --> 02:17.620 Observability allows engineers to understand and debug agent behavior. 02:17.980 --> 02:21.500 Controllability keeps humans in command of important decisions. 02:21.780 --> 02:24.620 The key insight on this slide is essential. 02:25.100 --> 02:29.060 A practical agent is one you can trust, not just admire. 02:29.540 --> 02:35.140 Trust is earned through transparent behavior, predictable execution, and graceful failure. 02:35.140 --> 02:35.780 Handling. 02:36.420 --> 02:41.500 Without these properties, autonomy becomes a liability rather than an advantage. 02:41.700 --> 02:47.980 This slide introduces task decomposition as a core design technique for practical agents. 02:48.700 --> 02:55.780 Task decomposition is the process of breaking large, complex goals into smaller, well-defined, and 02:55.780 --> 02:57.860 independently executable steps. 02:58.460 --> 02:59.860 As shown on the slide. 03:00.060 --> 03:04.740 This transformation turns overwhelming objectives into manageable units. 03:05.490 --> 03:07.370 The benefits are clearly outlined. 03:07.810 --> 03:12.970 Better planning allows each subtask to be optimized with the right tools and strategies. 03:13.650 --> 03:19.570 Easier debugging makes it possible to isolate failures to individual steps instead of troubleshooting 03:19.570 --> 03:20.770 entire workflows. 03:21.690 --> 03:26.330 Safer execution enables validation at each stage before moving forward. 03:27.090 --> 03:30.250 The example workflow on the slide illustrates this clearly. 03:30.810 --> 03:38.450 Prepare a market report is decomposed into gathering data sources, analyzing trends, generating visualizations, 03:38.650 --> 03:41.610 synthesizing findings, and reviewing results. 03:42.650 --> 03:46.250 Task decomposition is not about making agents slower. 03:46.850 --> 03:51.650 It is about making them safer, more reliable, and easier to control. 03:52.410 --> 03:56.770 Without decomposition, automation becomes brittle and dangerous. 03:56.970 --> 04:04.170 This slide explains why task decomposition is not just helpful, but mandatory for production systems. 04:04.730 --> 04:07.680 The first reason is cognitive load reduction. 04:07.880 --> 04:14.320 Breaking tasks into smaller chunks prevents the LM from being overwhelmed by complexity, which directly 04:14.320 --> 04:15.920 improves output quality. 04:16.520 --> 04:23.800 Second, decomposition prevents critical errors by creating explicit checkpoints, it reduces the risk 04:23.800 --> 04:26.440 of missteps or hallucinated actions. 04:26.960 --> 04:31.560 Each step becomes a validation opportunity rather than an implicit assumption. 04:32.200 --> 04:35.040 Third, decomposition enables recovery. 04:35.480 --> 04:42.160 If a single step fails, the system can retry or correct that step without restarting the entire workflow. 04:42.880 --> 04:46.080 This dramatically improves resilience and efficiency. 04:46.720 --> 04:49.880 The golden rule at the bottom of the slide is worth emphasizing. 04:50.320 --> 04:55.720 If a task cannot be decomposed into clear, actionable steps, it cannot be automated safely. 04:56.320 --> 04:59.600 Decomposability is a prerequisite for production readiness. 05:00.120 --> 05:03.240 This rule should guide every agent design decision. 05:03.640 --> 05:10.430 This slide presents concrete strategies for decomposing tasks Effectively, different problem types 05:10.430 --> 05:12.950 require different decomposition approaches. 05:13.590 --> 05:18.790 Goal based decomposition breaks high level objectives into hierarchical subgoals. 05:19.430 --> 05:24.030 Sequential workflows define linear chains where each step's output feeds. 05:24.030 --> 05:24.750 The next. 05:25.310 --> 05:31.310 Conditional branching introduces decision points that select different execution paths at runtime. 05:32.030 --> 05:38.150 MapReduce patterns distribute work across parallel subtasks and then aggregate results. 05:38.710 --> 05:41.510 The best practice call out at the bottom is critical. 05:42.030 --> 05:49.150 Continue decomposing until each step maps cleanly to a single tool, API call, or atomic action. 05:49.750 --> 05:56.230 This level of granularity enables precise error handling, targeted retries, and clear observability. 05:56.750 --> 06:00.070 Good decomposition is not about creating more steps. 06:00.350 --> 06:05.630 It is about creating clear steps when each step has a single responsibility. 06:05.870 --> 06:08.270 The system becomes easier to reason about. 06:08.470 --> 06:10.100 Test and trust. 06:10.140 --> 06:14.300 This slide explains why memory is essential for practical ages. 06:14.700 --> 06:19.100 Stateless agents are fundamentally limited, as described on the slide. 06:19.300 --> 06:25.660 They forget past interactions, repeat, resolve mistakes, and lack context for personalization. 06:26.140 --> 06:31.260 Every session starts from zero, which is inefficient and frustrating for users. 06:31.780 --> 06:34.620 Long term memory changes this completely. 06:35.060 --> 06:39.900 It transforms agents from reactive systems into adaptive collaborators. 06:40.420 --> 06:43.300 Memory enables continuity across sessions. 06:43.420 --> 06:49.220 Learning from historical outcomes and personalization based on user preferences and patterns. 06:49.740 --> 06:53.500 The key transformation highlighted on the slide is powerful. 06:53.940 --> 06:57.460 Memory is the difference between a calculator and a colleague. 06:57.940 --> 07:01.700 A calculator produces correct answers but never improves. 07:02.140 --> 07:07.860 A colleague remembers context, learns from experience, and adapts behavior over time. 07:08.380 --> 07:12.410 In production systems, this distinction matters deeply. 07:12.930 --> 07:17.210 Without memory, agents cannot evolve with memory. 07:17.370 --> 07:21.490 They can become increasingly useful and aligned with user needs. 07:22.650 --> 07:26.290 This slide dives into practical memory architecture. 07:26.570 --> 07:28.610 Three memory types are outlined. 07:28.890 --> 07:35.250 Vector databases provide semantic memory, enabling contextual retrieval and similarity search. 07:35.770 --> 07:39.730 They are ideal for recalling relevant past conversations or documents. 07:40.290 --> 07:47.330 Relational databases store structured facts and state such as user preferences, configurations, and 07:47.330 --> 07:48.690 entity relationships. 07:49.210 --> 07:56.210 Event logs capture episodic memory actions taken and outcomes observed, supporting audit trails and 07:56.210 --> 07:57.330 learning over time. 07:58.050 --> 08:04.370 The slide also poses three critical design questions what to store, when to store it, and when to 08:04.410 --> 08:05.170 retrieve it. 08:05.810 --> 08:08.250 The rule at the bottom answers these clearly. 08:08.570 --> 08:12.960 Store decisions and outcomes, not raw conversation transcripts. 08:13.560 --> 08:17.680 This approach keeps memory compact, relevant, and privacy conscious. 08:18.120 --> 08:23.000 Memory should support reasoning and improvement, not become an uncontrolled archive. 08:23.280 --> 08:28.800 This slide addresses the risks of long term memory without careful management. 08:28.960 --> 08:30.840 Memory becomes a liability. 08:31.200 --> 08:33.000 Three risks are highlighted. 08:33.200 --> 08:35.960 Stale data leading to incorrect decisions. 08:36.200 --> 08:37.040 Memory bloat. 08:37.080 --> 08:41.240 Degrading performance, and privacy leakage from excessive retention. 08:41.720 --> 08:44.440 The mitigation strategies are equally important. 08:44.840 --> 08:47.600 Time to live policies automatically expire. 08:47.600 --> 08:50.000 Memories based on age and relevance. 08:50.400 --> 08:51.040 Relevance. 08:51.040 --> 08:51.520 Scoring. 08:51.520 --> 08:54.160 Continuously prunes low value memories. 08:54.600 --> 08:58.880 User consent ensures sensitive information is stored responsibly. 08:59.280 --> 09:03.200 The guiding principle at the bottom of the slide summarizes everything. 09:03.400 --> 09:06.560 Memory must be curated, not accumulated. 09:07.040 --> 09:13.560 Thoughtful retention policies are essential for safe, compliant, and performant agent systems. 09:13.600 --> 09:16.830 The final slide brings all concepts together. 09:17.350 --> 09:23.190 Practical agents decompose tasks aggressively into atomic validatable steps. 09:23.870 --> 09:30.470 They use memory, intentionally storing decisions and outcomes with clear retention and retrieval policies. 09:30.830 --> 09:37.710 And they keep humans in control by requiring approval for high risk actions and providing override mechanisms. 09:38.350 --> 09:41.310 The slide also emphasizes designing for reality. 09:41.510 --> 09:48.230 Production systems must expect failure, enable oversight, and earn trust through consistent, transparent 09:48.230 --> 09:48.950 behavior. 09:49.430 --> 09:55.790 The final insight is especially important the best agents are collaborators, not replacements. 09:56.150 --> 10:01.070 Success comes from augmenting human capability while preserving human judgment. 10:01.630 --> 10:06.470 Practical agents are powerful, yet trustworthy, autonomous, yet accountable. 10:06.830 --> 10:12.590 This mindset is what separates sustainable AI systems from risky automation experiments. 10:12.910 --> 10:16.230 And it is the foundation of real world agentic AI.