WEBVTT 00:00.280 --> 00:04.720 So I am genuinely blown away by how well that did. 00:04.760 --> 00:10.040 And and you know, again, how easy it was for us to get to that point of having these different, this 00:10.040 --> 00:16.960 crew of different agents building that product and the fact that that user interface just worked right 00:16.960 --> 00:22.640 away, like it just came up and it ran and, and it looked so great and that the functionality behind 00:22.640 --> 00:27.840 it there was like a front end and back end and it all held together and did its thing. 00:28.200 --> 00:33.720 So I hope that you're going through the same as what I'm going through, somewhat some disbelief and 00:33.760 --> 00:35.160 I hope you're seeing similar results. 00:35.200 --> 00:39.760 I've put that particular example in something called example Output new. 00:39.760 --> 00:41.920 And there's also you'll see a couple of other examples in there. 00:41.920 --> 00:44.240 If you you want to try out the ones that I generated. 00:44.240 --> 00:45.400 But you should try it yourself. 00:45.400 --> 00:48.520 Play with different models and experiment. 00:48.520 --> 00:50.440 And that's not all you should experiment with. 00:50.480 --> 00:54.800 Now this this week has some important projects for you. 00:54.840 --> 00:57.040 This this is where you really learn. 00:57.040 --> 01:00.280 You learn by building stuff yourself, by coming in. 01:00.360 --> 01:03.640 Take an example like this and just build it step by step. 01:03.680 --> 01:05.240 Take it a piece at a time. 01:05.240 --> 01:06.960 Gradually add to it. 01:07.160 --> 01:13.480 So the first way you can add to it, the easy way you can add to it is to have your team grow. 01:13.760 --> 01:15.160 Your team is hiring. 01:15.200 --> 01:16.480 Add in some more. 01:16.680 --> 01:21.720 The role that I call test engineer wasn't really a test engineer because this was some something that 01:21.720 --> 01:26.480 wrote test cases, but you could actually have a test engineer that's responsible for going through 01:26.520 --> 01:29.720 maybe writing a test plan and then executing the test plan. 01:29.760 --> 01:33.080 You could add a business analyst that fleshes out the requirements. 01:33.120 --> 01:34.680 You could you could have some more detail. 01:34.680 --> 01:37.720 You could have an even richer user interface. 01:37.880 --> 01:40.880 Honestly, the sky's the limit with this. 01:40.920 --> 01:42.840 We're just scratching the surface. 01:43.040 --> 01:50.520 We only had four people in this team, and and you can just keep on and on going and try different models 01:50.520 --> 01:52.160 and see where it takes you. 01:52.600 --> 01:59.520 But that's the relatively easy change there is then a harder change for you, which is the real challenge 01:59.520 --> 02:00.360 of the week. 02:00.600 --> 02:01.640 And here it is. 02:02.160 --> 02:08.960 So the thing is that this was all very well, but ultimately it only produced one Python module for 02:08.960 --> 02:10.280 the back end code. 02:10.400 --> 02:15.240 And then of course front end module to go with it and a test module to go with that. 02:15.240 --> 02:21.240 But it was all still very much on rails in that there was just the one, the one module that was already 02:21.440 --> 02:22.800 fixed at the beginning. 02:23.080 --> 02:30.200 Now, it would be a lot better if your team could build a whole system piece by piece, working on the 02:30.200 --> 02:34.800 different classes to build the different modules and then assembling them together. 02:35.160 --> 02:42.560 But therein lies a problem, because you would need to have a workflow that's a little bit more interactive 02:42.600 --> 02:49.320 in that potentially you'd need to have different classes being created by different agents. 02:49.720 --> 02:51.440 Now there's a few ways to do this. 02:51.480 --> 02:57.350 One way is, of course, you'll want to use structured outputs as a way to get more clarity from the 02:57.510 --> 02:59.670 engineering lead about who's doing what. 02:59.710 --> 03:04.350 Use structured outputs as a way to construct the different modules that need to be written. 03:04.750 --> 03:10.830 But ultimately, you're probably going to want to call an engineer a certain dynamic number of times. 03:10.830 --> 03:14.990 That will depend on how many modules the engineering lead wants to create. 03:15.110 --> 03:20.550 So it's not like you're fixed when you write the code that you know exactly how many tasks will be run 03:20.870 --> 03:21.070 now. 03:21.110 --> 03:24.350 Crew allows you to do that and it makes it quite easy for you. 03:24.350 --> 03:29.270 You can create a task object at runtime while it's actually running. 03:29.270 --> 03:34.710 You can have a task object, and one of the the fields you can have is have a callback. 03:34.950 --> 03:40.470 And actually the callbacks with the agent and the callback can make it create another task. 03:40.470 --> 03:47.310 So you can use this approach to build a more dynamic system where the results of completing one thing 03:47.470 --> 03:49.750 causes another thing to happen. 03:49.750 --> 03:54.190 And so you can assign tasks for each of the modules that need to be built. 03:54.430 --> 03:56.830 And that is the challenge for you. 03:57.150 --> 04:05.150 Add structured outputs and then add the dynamic creation of tasks so that an entire set of modules can 04:05.150 --> 04:10.630 be created, and you can build a whole system and then apply that. 04:10.670 --> 04:13.230 And I don't necessarily have a system to be built. 04:13.230 --> 04:15.670 You should apply that yourself to your day job. 04:15.710 --> 04:20.310 Think of a system that you would like, whether it's building a website, whether it's building an e-commerce 04:20.310 --> 04:25.670 platform, whether it's building something to organize medical records, whatever line of business, 04:25.670 --> 04:31.550 whatever profession you work in, think about the challenge that you could set your crew and have it 04:31.550 --> 04:38.390 be something which which is dynamic and which could involve building an entire system with several modules. 04:38.550 --> 04:43.590 And once you've done that, of course, or while you're doing it, you must share your progress. 04:43.590 --> 04:48.710 This will be hugely something that that will generate excitement on LinkedIn. 04:48.710 --> 04:50.670 So post updates there. 04:50.710 --> 04:53.630 Tag me so that I can weigh in and get it more visibility. 04:53.950 --> 04:59.950 These are projects that really count, and it really helps you to build and solidify your expertise 04:59.950 --> 05:02.350 and demonstrate it to others. 05:03.110 --> 05:05.830 Actually, to correct myself there, I was right the first time. 05:06.190 --> 05:12.230 If you want to to work with callbacks, then the way you do it is at the task level, not the agent 05:12.230 --> 05:12.750 level. 05:12.750 --> 05:15.630 And I'm looking right now in the crew docs. 05:15.630 --> 05:16.110 At docs. 05:19.390 --> 05:21.270 Or just just click on tasks right there. 05:21.470 --> 05:24.550 And it's worth looking through this because there's lots of lots of interesting information here that 05:24.550 --> 05:25.750 you might want to try out. 05:25.910 --> 05:33.190 So the callback you can specify when you create a task, the in the code you would say callback equals. 05:33.190 --> 05:36.710 And then the name of a function that should be called back. 05:36.710 --> 05:39.670 And that is where you could potentially create a new task. 05:39.990 --> 05:44.910 So it talks generally about the fact that you can create tasks from from YAML as we know well. 05:44.950 --> 05:48.750 Or you can also do it just by having the full code version of it too. 05:48.790 --> 05:54.190 As you can imagine, you can just pass in the description the expected output instead of specifying 05:54.230 --> 05:55.630 the YAML config. 05:56.030 --> 05:59.630 Then there's a lot of interesting stuff here that's worth taking a quick peek at. 05:59.790 --> 06:05.510 There's stuff we know about, but then there's also task guardrails, a analogous concept to what we 06:05.510 --> 06:07.390 looked at with OpenAI agents SDK. 06:07.750 --> 06:12.950 Using guardrails a way to validate and transform outputs before they're passed to the next task. 06:13.190 --> 06:18.150 It looks like it doesn't have the same constraint that OpenAI has that it needs to be input of the very 06:18.150 --> 06:19.870 first one, or output of the very last one. 06:19.990 --> 06:23.190 You can implement this at any task, it appears. 06:23.550 --> 06:30.470 And then there's stuff about how to handle errors with with those guardrails and then structured outputs. 06:30.510 --> 06:31.950 We know about that. 06:31.950 --> 06:36.990 That is of course using the output pedantic or output JSON is another way of doing it. 06:37.310 --> 06:42.350 And now integrating tools with tasks is of course something that we know about. 06:42.350 --> 06:46.870 And creating a task with tools is is listed out here, which is. 06:47.430 --> 06:49.150 Yes, sorry, that is what we're used to. 06:49.190 --> 06:54.900 Again, that is using a tool like the surfer dev tool that we already used, actually, right in there 06:55.220 --> 06:57.980 referring to other tasks. 06:58.100 --> 07:03.020 The output is automatically related to the next one, but you can define the context that should be 07:03.020 --> 07:03.460 used. 07:03.460 --> 07:05.300 And and we we did that. 07:05.500 --> 07:08.060 There's some stuff on asynchronous execution. 07:08.100 --> 07:13.700 You know I remember I said last time I think that we would be using async every single week, and we 07:13.700 --> 07:15.540 haven't actually used async this week. 07:15.540 --> 07:17.820 We're going to it's going to make a comeback, don't worry. 07:17.820 --> 07:23.100 But if you miss it then you can read up around asynchronous execution of your crew tasks here. 07:23.340 --> 07:25.820 This then is the callback mechanism. 07:25.820 --> 07:28.940 This is where you can implement a callback function. 07:28.940 --> 07:36.500 So if you had referred to it like so, then your function will get called subsequently when the task 07:36.500 --> 07:37.340 completes. 07:37.660 --> 07:40.820 And then there's a more interesting stuff here. 07:41.300 --> 07:45.980 And uh, more now on the, uh, the guardrails as well. 07:46.420 --> 07:48.180 And there we go. 07:48.420 --> 07:53.500 So I, I do encourage you to take a read through this, read a bit more about things like guardrails, 07:53.500 --> 07:55.740 which are interesting, and also about using callbacks. 07:55.940 --> 08:01.460 And some of this may be helpful when you look to build this more advanced flow. 08:01.580 --> 08:08.460 When completing one task can trigger setting dynamically, creating multiple other tasks. 08:08.820 --> 08:12.500 And very sadly, that brings our crew week to an end. 08:12.540 --> 08:15.660 It's the end of week three, the end of crew week. 08:15.660 --> 08:19.380 We've done some great things, so we built some fun projects. 08:19.380 --> 08:21.660 The stock picker was was really interesting. 08:21.660 --> 08:23.620 You haven't used that for investment decisions, I hope. 08:23.860 --> 08:26.660 And the engineering team was just mind blowing. 08:26.780 --> 08:27.260 Wow. 08:27.660 --> 08:30.100 Um, so I really hope you enjoyed it. 08:30.100 --> 08:32.140 I hope you have the same feeling as me about crew. 08:32.180 --> 08:33.660 I really love crew. 08:33.900 --> 08:41.820 I prefer open agents SDK, but but I love crew too, and I'm excited to now move to a heavier weight 08:41.820 --> 08:46.420 framework in the form of Landgraaf for week four. 08:46.460 --> 08:48.660 It's going to be great and I will see you then.