chapters transcript notes
click any line to jump to that moment in the video
0:15 Hello everyone and welcome back to another episode of Agentic Thinking. Matthias, can you believe it? We're already there at episode 24. It It has only been a month. Yes, we're episode 24 already. 0:27 we There's many conversations happening with Raven coming out. I did a lot of demos 2 weeks ago around just building one video every day of the week just to build more videos there around 0:37 how to use the tool, how to how to leverage it. we're jumping back in today for conversations around net new news around all things Identic as . welcome everyone back to the show. 0:48 Matthias, hello. It's great to see you again. What are we talking about today? many news to catch up on. a couple weeks ago we were really 0:58 excited about Fable, which had just been released. What happened to Fable since? Gone. Yeah, [laughter] ? It's out. that was that was a short ride. 1:10 let's see what happened I had been smart enough to say when I got access to Fable, I should have just run it on all my code bases and say, "Find all the security holes. Write me a report around all the security gaps I 1:20 have." Cuz I don't have access to it . It's gone from I can't use it at this point. it's wild. weirdly enough I I saw it documented on on Azure Foundry 1:31 the other day. , I think lots of providers are still struggling to even update the documentation on it. As far as I'm aware, unless I missed something, it's still not available. 1:42 let's just go with that, ? and since we're talking Anthropic and since we talked much around pricing changes, they did a 1:52 very, very interesting and very quiet U-turn. , a a few weeks ago, we talked about , Anthropic announcing a 2:02 pricing change to their subscription models that would have come in June 15th, which was a week ago. and that was 2:12 specifically with respect to , , using , Claude code headlessly. , either the Claude code SDK or using Claude-P, ? Which , 2:24 allows you to run it , in an in a in a in an automated fashion. And they said, starting June 15th, , you're no longer going to be able to use your subscription 2:35 budget, if you will, , whenever you invoke the tool in in in such a automated fashion. And then just , a few days before the 15th, , very 2:46 quietly, they suddenly put a note on on the announcement saying they're pausing that and they're not going to introduce it. And that's case . , nothing's 2:56 changed. , they they say they're reviewing alternative options, but far nothing's been announced. Very interesting. , for the time being, 3:06 make the most of your Claude subscriptions, , , if you if you want to use it , non-interactively, , because this is 3:16 as much as you're going to get out of it, , as you as you can. It will it if and when it changes, it will definitely will not change for the better. I think this is really interesting that 3:27 they're doing this. And I would also argue this is probably a large pushback from the community and seeing how much of the community is using this, you know, running Claude, , a standalone without , headless, without 3:38 having to have someone in front of it. That's part of the value of having the agents around in general. And , not being able to have that access to your pro and max subscriptions is here 3:49 is a really big deal, I think, for a lot of people. , likely the community and I say this a lot about Microsoft MVPs, it's the invisible hand that can move Microsoft, ? We 3:59 don't We have the ability to rally the troops and be vocal about what we're not happy about feature change-wise and move or shift some of those the sentiment one direction or the other to 4:10 get a product that we to use and want to and want to leverage. Maybe this is part of the same thing around the community around Anthropic. , hopefully it stays. hopefully that we 4:21 continue to use this with our with our cloud subscriptions. , that's another good one. In other news, I just want to maybe along these lines with Mythos or Fable disappearing from the market, 4:32 we had a new contender in the market. Have you seen this new one from Japan? Has recently been announced. There's a new model called I'm going to get the name wrong. As- Asaka? Asana? 4:44 .ai. , it's a Japanese model that's apparently ranking really high in the marks from a new company. , I think there's this nervousness around 4:57 Let's talk about some of the political issues here. US and Anthropic puts out this model and then all of a sudden the US says, "Nope, the government says shut it down. Only US citizens can use this model." 5:08 how do you verify that only US citizens are using the model and all these other implications cuz it's security risks or whatever they say. every other nation-state is ", we should have our own AI 5:19 as ." Because they need to compete at that Mythos- level, but do they have the , same level of capability? , it's competing 5:30 areas where we want to have a lot of these countries have access to these really high-end models for their citizens and their development and you know, making sure their company can move their their their world their part of 5:41 the world can move forward. , this is really interesting. Did you see this announcement around Asana AI? possibly. I don't particularly recall it, but one thing I do recall, and I 5:52 definitely wanted to mention that today, GLM 5.2 has been in the news a lot. I saw that one as . Yeah. Open source, that's one from China again. 6:02 yeah, new almost frontier model open source from China, and there's a lot of noise currently that 6:12 compares it to Opus, but at a fraction of the price. half, almost a half the price at this point. That's what I was seeing in Yeah, I know I Yes. 6:24 this one is interesting. I And it's probably worth pointing out to people. you If you If you If you're not looking into 6:36 using local models, ? If If you're If you're using open source models, but from some provider, it's it's very important for you to check what their data retention policies are. 6:47 Sure. I personally use Vercel AI Gateway a lot. , it's it's a 6:58 a wrapper around all kinds of model providers, which means you have one bill, you have a one API, you have one very neat interface to 7:09 see all your model consumption, but they they they do not host models. They just route your requests to other providers, 7:21 which could be Microsoft or Anthropic or OpenAI or whatnot, ? And , when you I'm obviously we're not doing 7:32 screen shares on this podcast, but if if if you if you go to the to the model list on on Vercel AI Gateway, if you click through to individual models, you can see 7:44 which providers they support. And it then also shows per provider whether or not your requests are used for training 7:55 or not, and whether or not there's a zero data a retention policy in place. And sometimes the exact same model can be offered 8:05 through different providers, but with for instance, one of them retains your data, others don't. sometimes there's a pricing 8:18 important. to to check that. they also have an option if you're on a pro account to say only make providers available to me that offer zero data 8:28 retention. and that's a global filter, and that gives you complete certainty that. and why am I saying that? You We talked GLM 8:39 52, , we talked models from China or elsewhere, open source. if you want to seriously look into them, particularly in in a business 8:49 context, things data retention are very, very important. And this is a very neat way for you to check, ? Is that something your provider offers? Do you Do you want to select you 9:00 know, you've got a choice of five providers. Do you want to select only the three that have that retention even if maybe their pricing is slightly 9:11 higher. , definitely something to look into. it's it's certainly something I I did recently, which is why Sure. I thought I'd share it. this is the Vercel I'm going to call 9:23 this is the I'm looking at the trying to find the guide for this one. There's a guide around the cost-aware model routing with AI Gateway. Is that what you're describing, or is there a specific feature that it's doing? 9:34 Vercel AI Gateway is the AI Gateway, . it's it's the name of Got it. Yep. You 9:48 load money into an account and then sort of you use it. Perfect. And they have very competitive pricing, 9:58 very very neat tracking interface for all your requests. And obviously a single endpoint you target, very 10:09 neat . I'm putting that in the chat window as . it's the Vercel AI Gateway. I'm not not using that one yet. That's a good thing you bring that up. Open Router would be another one . That was known, ? 10:20 it's a competitor to Open Router. . Interestingly, Open Router tends to be more expensive for some models compared to Vercel. . Excellent. one that I'm I'm 10:31 using a lot is I'm using Foundry a ton. Foundry is is my model provider of choice and I by default everything that comes out of Foundry is no data retention 10:41 policy. I'm not passing data through to the other model providers as . another interesting development this is is XAI is doing a lot more contracts work with other companies. 10:53 I've seen some news around this this idea of , , we need data centers with compute on them and there's a lot of revenue generation coming from organizations 11:03 that want to host models and run a service and you need the hardware. I was thinking I've seen the to the tune of $4 million over the next couple months. they're borrowing at a $124,000 11:17 a month bill, a lot of hardware to run these models on. this is becoming another whole economy around do you have the hardware? And if you have the hardware, if you have large 11:27 colossus- style size V machines, you can start using that as leverage to to have people host models and run models through things, which is very interesting. . Find that really really neat as . 11:38 I'm going to put here the open router as . , open router here in the chat window as for those who want to check that out as . If you don't mind, just a quick note on Foundry. , 11:48 something which is worth noting. , people maybe don't know. for for LLMs, there are there are three main alternative APIs that are 12:00 currently established in terms of how you can talk to an LLM. there's the OpenAI chat completions, which is the original 12:11 that's been around for the longest. Standard. Yeah. Yeah. Then there's the OpenAI responses API, which is much newer, and that's more tailored towards the needs of agentic systems. , 12:23 a more modern. And then there's the Anthropic messages API, which is on par with OpenAI responses. And the the the issue with Foundry models is that they don't open 12:35 they don't provide all of those APIs for each model. In particular, only offer the chat completions API, which is quite dated for a lot of 12:47 their models. , from my point of view, that's quite a disadvantage compared to other providers Vercel for instance, where you don't have to make those kinds of choices. , it's quite technical. I 12:58 appreciate it, and Yeah. people will never even have looked into different LLM APIs, but ultimately, that stuff is really important when it comes to being token 13:10 efficient for instance. And because, you know, responses and messages APIs, they are particularly tailored towards caching and being able to be very 13:22 effective with respect to the payload that's being sent back and forth. And that's again we're we're getting to this phase of 13:33 agents were just thrown out into the world and everyone was trying to figure out how to use them and I think we're starting to step into this optimization phase. I keep saying we're we're we're phase one of every technology is 13:44 get it working, get it out there, get people using it and then phase two feels come back, optimize. . again and I'm also seeing a lot of messaging around, , mixed 13:54 models and use some models that are on your local machine and other models that are in the cloud and how do we run these higher-end models that I saw an article just yesterday talking about the 14:04 GLM 5.2 and if you use a lower quantization of the model, meaning it you you shrink the size of it, you can run parts of it on a smaller machine. And they're doing run the layer of 14:17 AI modeling that you need at the time. hot loading parts of the model and running the AI through that. there's all these new techniques around trying to bring these models local on 14:27 your machine, again driving down costs. And if you have a machine someone did the math it was pay hundreds of dollars a month for an AI or run it locally for the cost 14:39 of electricity, which was a dollar or less a month. something insane because the cost of electricity that's for sure. That's [laughter] good. You have a much higher price over there. 14:50 But as I'm looking at this going, yeah, if if the price differential becomes high and you want that agent to run all the time and not run out of things or even for security standpoints, you don't 15:00 want to send any data to somewhere else. these I think localized models are going to become more and more tuned to a very specific purpose. Why not run much smaller models that are very 15:10 refined for what you want it to do a billion. Why do I need an image processing model if I'm just going to send a code all the time? that doesn't make sense to me. I I think we're getting to this optimization era where we're going to 15:21 have models that are going to be much more efficient that way. Which is a perfect segue into something I was quite keen to talk about today. Great. Loop engineering is something that's all 15:33 over the place . I don't know if you've heard of it as , ? This is super hot . Give us the run for people who haven't heard 15:43 about loop engineering with agents. Give us the high-level overview of this. What what is this thing about? the 15:53 it all kicked off with a famous quote famous quote by Peter Steinberger, , open code guy. I'm quoting he said, "You shouldn't be prompting coding agents anymore. 16:04 You shouldn't be prompting coding agents anymore." Let me emphasize that. You should be designing loops that prompt your agents. , that is pretty much what loop engineering is. 16:15 We've come from prompt engineering a couple years ago to context engineering, which was really big last year, and we're in the loop engineering space. ? , prompt 16:26 engineering was all about us learning to prompt our LLM to prompt the agent very , , to get the best possible outputs. 16:37 we've then moved on to realizing, , we need to focus much more on on context management because context windows are precious and limited, , that's how skills came in and 16:48 progressive disclosure. and that's when people learned, , about tracking the the the size of their context window and 16:58 being very efficient with memory files. but nonetheless, even with, very efficient context 17:08 engineering practices, you if you were very serious and and working with agents, you ended up having to be very reactive and having to 17:20 put a prompt in, let your agent work, either for a minute or if you're lucky for half an hour, but then you were still presented with some 17:30 output and probably some overstatement with respect to how successful they were and you were back in the loop there. , ultimately that one doesn't scale particularly 17:41 because you don't know when that happens, ? You don't know do I need to sit here and wait because I'm going to have to be come up with I'm going to have to come 17:51 up with another prompt in a minute or do I do I allow myself to completely context switch to a different project because this one may run for for 30 45 minutes. You don't know, ? And 18:02 at scale this one is quite a burden on you as an engineer. which is how we moved to loop 18:12 engineering where we're saying put another agent in there to be the first responder, , and if think about how you how you train 18:23 and instruct an agent to be the one who receives the first agent's response and then to act on that, , by 18:33 either pushing back or delegating to another reviewer agent or 18:44 running some tests and checking whether, , what the first agent claimed they had done was done, , if you think about it, what you as an engineer 18:56 did in in the prompt engineering and context engineering phase, a lot of it was very repetitive and there were patterns there which are quite straightforward to automate. And 19:07 this is why nowadays people invest a lot more in those higher level agents who who generate 19:17 prompts on your behalf, ? , that's the whole point. and that's what the what the Steinberger quote comes down to. You shouldn't be writing the prompt. You 19:27 should you should have an agent that knows how to how to produce the next prompt. Yeah, correct. And and it's if you if you Google loop engineering, , you're 19:38 you're going to have a lot to read because this is what everyone talks about . And it's it's just a very natural progression from where we've come from. 19:49 Matthias often when I'm seeing things, particularly these articles, these new patterns that are evolving, I look at this going this is no different than running an actual engineering team. 19:59 [laughter] instead of having people and managers of engineers and teams of engineers, I'm instead just giving that to an agent, and we're 20:09 mimicking, I feel , in a lot of ways the exact same structure as we would be doing development with a team. I I would talk to a manager, here's our main 20:19 objective, this is the feature that we have, here's the research that I have. Mr. Manager of engineering team, you go figure out how to build the CI/CD 20:29 pipeline, the new feature, the new UI. it's up to you to figure it out. What other inputs do you need, ? And , you you let them just go build, task everything out, break it 20:39 down into manageable elements. That's knowledge that we would give to people and have them do it. It's just This always feels a repeat repeating process that we would normally 20:49 have done with teams. We're just moving this up a layer. yeah, I think layer is is the crucial point here. That's how I think about it. It's all about which layer 21:00 are you as a human at, ? And in an ideal world, you want to be as high up as possible, ? And if you think about it, , a an engineering system has many different layers, 21:11 ? It The lowest one would be one particular problem to address, , I don't know, a bug fix or, , at a at at 21:22 this particular feature to to the CLR TypeScript yes function writer of that thing. that's that's what I do, ? Yeah. And and , if you if you don't have a 21:32 layout system, what do you have to do in if working with agents, you have to prompt it, you have to wait 21:42 their response, and then you have to somehow judge whether the response is good, and you can close that, or whether you need to push back on 21:53 and and have them do another round, ? And , at this lowest layer, you can easily imagine how you would create an agentic loop that 22:03 does that on your behalf. But then you're one level up, ? And then you can think of, , someone can be a supervisor that has multiple of those work items 22:16 and they're responsible for it, and you give them an entire milestone, let's say, , 5 10 15 work items, and then they can coordinate how these 22:28 low-level loops run. And then from that you can go one level up, and you can have someone who oversees an entire project, 22:38 ? And turn and turns that into milestones, etc. etc., ? , it's almost infinite with respect to how high up you can go, but all of that 22:48 depends, and this is really what loop engineering comes down to. This is all of that depends on very good agent-driven verification. If you're not able to , to to 23:00 have an agentic loop defined where you get complete confidence from your agent judging that the task was completed successfully, the whole thing 23:10 is going to break down. And and this is this is the real technical difficulty nowadays. looking at this one. , Matthias, you shared with me an interesting 23:20 article from LangChain, which I think LangChain does a really good job on articles. I've found them to be very beautiful, very informative. I've learned a lot from them. . I have the link of that inside the chat window. , if you want to learn more 23:30 about what an agentic loop is, how does this work? you can have some really rich documentation. and I would agree with this one. I I've also 23:40 found when working with my team, Matthias, the gen- the the team members on my team that are have been doing engineering for a while and have been leading others or 23:51 directing others, I feel are getting really good at being able to get great output from AI agents. , that engineering team lead or manager, 24:04 giving them the time to learn how to use agents, learn how to build loops, learn how to build patterns, I think really is going to be in a big advantage. And , that skill set is not I don't think it's lost. I think it's just shifting 24:15 slightly from what it was and how to use it to build software and and and things moving forward. , absolutely loving this one. Great article. Let me ask this question 24:25 directly to you, Matthias. Have you built a loop system yet? Have you played with making one or creating one or do you have versions of a a similar looping 24:35 system? you've described to me in the past I think you've built this already Exactly. Yeah. Months ago. Yeah. But people are getting on on board with this. Yeah. , I've I've built my own and 24:47 it's it's being refined every day. but it's it's it's grown step by step from me establishing some routine, 24:59 how I engage, , with my agents, and then figuring out what I'm doing, I don't have to be doing. This is something which I can codify, and which I 25:11 where there's judgment involved, I can delegate that judgment to to an agent that I trust, ? And , it And then it it ended up as as a as a 25:22 sequence of of those, , gradual, , , letting go of, , 25:33 stuff I did myself as opposed to, you know, handing it over to an agent. to , it's quite abstract. , something very specific, ? , , 25:43 long time ago, last year, I established a system where I would use GitHub issues to start new work, , the the issue would could would contain, 25:53 specs and and requirements, and I would then, , I I then I I had, , a a setup where I can 26:03 delegate an issue to an agent, , and, , the very first iteration of that was me delegating to an agent, and then sort of, , the agent ran in GitHub actions 26:15 and, , came back at some point, , with a pull request. Sure. ? And , what I for a while, what I then ended up doing was I, , 26:26 got notified the pull request was created. I went into the pull request, had a quick read of, , what the summary was, but then I would delegate it to another agent using a skill, 26:37 Yep. and, , that agent would run a review skill. Yep. Sure. it would specifically come back either, , with a ready for merge 26:48 verdict, , but in most cases it would come back with a whole range of bits that needed to be addressed, ? Sure. And then when that happened, I would then 26:58 invoke yet another agent with a different skill, and that skill was targeting the the previous response. It 27:08 it had to inspect what was raised as existing issues, and it had to work on that. And then what once that agent was done, I came back and invoked the reviewer skill. , as you can see, 27:19 that's there's, , there's a recurring pattern here. It's very laborious when you do that manually, and this is just an example of something that I've done 27:30 turned into an agent-driven workflow because it doesn't need me, to to invoke another agent with 27:41 another skill, ? This is definitely something you can delegate. and Automate more of it. takes is to review the outcome and to make a judgment call, and this 27:52 is really, , why we need an LLM in the loop here to make a judgment whether or not to consider this done or whether to 28:02 push it back to to an implementation agent. And , there we go. That's one example, and I'm very very happy with that , 28:12 ? And most of your in your example here as you're doing this, , I have a feature, write out the issues, fix an issue, resolve the issue, evaluate 28:23 the issue, and come back. And this is this is verbatim what's happening in this article around they're talking about exactly that that flow pattern. in lieu of that that pattern of things that 28:33 looping around, were most of your agents running ? , at the time I think when you're doing this, tokens were cheap. All of those agents were in the cloud, ? Most of that work was being done with agents that were from 28:44 services the premier models are you looking at moving some more of that dividing some of that work to some local and some cloud models or 28:54 some premier models? what what is your thoughts ? this is I think this is this is the shift I think I'm seeing, ? That's a great pattern, but I don't want to pay the high cost of 29:04 all those tokens for all that work to be done in the in premier models. , how does this change moving forward? personally, I I have not really 29:15 shifted much to local models. I only use them for privacy reasons, , when I don't want to send stuff into the cloud, but I I don't use them for cost 29:26 reasons because we have we have a lot of good alternatives. If you want to be cost efficient, we have many models to choose from, which is why I talked about Vercel AI Gateway earlier, ? 29:38 this this is how you get access, you know, to a whole range of differently priced models. , and, , that's where I've been doing most 29:50 experimentation, . What what can you achieve, , with non-premier models? , not GPT or Claude, ? , 30:03 oftentimes at a fraction of the cost without , without giving up too much. And , this is where the loop engineering comes back in because, obviously, if you if 30:15 you have to loop, which I explained earlier, where , an agent drives that constant ping-pong between this agent does the implementation, that 30:25 agent does the review. If this is automated, then you can afford for particular feature to take 20 or or 25 of those loops, , 30:36 which, , it may take additional loops when you use a cheaper model, but you can afford to do that. You would still save money at the end of the day, ? It will just 30:46 It takes a little longer, ? And , with that setup, I would also recommend that the reviewer is the more expensive model, Yeah. 30:56 and the implementer is the cheaper model, , ? Makes sense. Yes. And And the idea is require that the more expensive model with the better reasoning skills, you're you're telling it in 31:08 its skill, you're telling it, "When you write this issue on GitHub, be very verbose, you're going to give this task to an agent to build." you describe , "I want you to build this for very detailed, define the 31:20 inputs, define the output, be more verbose." . Because, again, going back to what we've seen in papers before, which is that first shot on the model is 31:30 by far the best. You're going to get your best results on that first very clean context window. If you don't get it dialed in that first shot, the second shot, third shot, fourth shot, as you 31:41 continue talking with it, it just continues to corrupt its context, and it gets confused, and it doesn't really give you the results you want. , the the closer you can get to that one-shot prompting with more descriptions up 31:52 front, the better your output will become anyways. . , my solution for that, or or my way of working, I talked about using GitHub issues for specs and 32:03 starting new features, ? I never write those myself. What what I do is I create an issue where I have an idea, but then I've got an agentic loop 32:14 where that idea is researched, . validated, and and converted into very detailed specs that an implementing 32:24 agent then can work with quite even if it's not a top-tier model, ? , before I even get into the implementation and review loop, I have a 32:34 a research and specification loop, which is really crucial as , particularly if you if you don't want to be reliant on on very expensive top 32:44 frontier models, , ? If you throw stuff into, , office and GPT 55, fine, you can afford to be vague. They'll figure it out. But, 32:56 not all of us have money to burn. , if you want to be a bit more efficient there, then invest more into planning, which is effectively what I'm talking about here, ? 33:06 And then the the planning agent is definitely going to spend, , as many tokens as as an 33:16 implementation agent would be if you give them a vague prompt to start with. And that's definitely worth it. that research and and specification 33:27 phase is extremely important. And yet again, this can also be another agentic loop, ? I I think of producing specification 33:38 in the same way as implementing code, , a specification requires the exact same 33:49 verification loop, for instance, ? , in fact, I for my non-trivial 34:00 projects, I maintain all my specifications in in under source control. , they they don't just live in a GitHub issue or . 34:10 They go through a whole source control and pull requests and review cycle. And a specification for a particular feature is often times multiple files. 34:21 It's , it ends up being very very detailed. I find this very interesting that you've used GitHub as your main source of storage of information, repos of 34:33 information, and issue tracking and getting all these task things. One of the items I look at, , I was looking with Alex Powers recently around his tool, which is the task flow 34:43 assistant, which does a similar thing when you ask a question and then it builds a bunch of documentation, but instead of doing it through GitHub and GitHub issues, it's building a series of markdown files. , "Hey, 34:53 I'm going to design the plan of what we're going to build. From that plan, I'm going to make a checklist and in that checklist we'll do a lot of these deterministic patterns, making sure that 35:03 we're able to loop through and build out the infrastructure that we need for the the task flow or the the particular workspace or infrastructure. , I I I the idea that you're going down the GitHub route. 35:13 I personally, in our company, we're using a ton of GitHub and I think the integration the tight integration between GitHub, agents, execution of things, GitHub actions, that makes a lot 35:24 of sense. . and I think Matias this comes out of your your your world of you're a developer. , this is comfortable to you. . I was always hesitant, not 35:35 hesitant, but I didn't really understand what was going on GitHub. I'm using it much , it's become very clear to me. , I I just the amount of consumption that I 35:45 use directly on top of GitHub, , what's local, what's remote, what's a branch, what's not a branch, is this branch going to be permanent or not, protecting branches. There's a 35:55 whole bunch of new things that I haven't really been exposed to, but it just becomes second nature to me and conceptually I'm there. Do I know how to write the the direct commands in Git to 36:05 do all those things anymore? No, I tell my agent to do that. But, I do know that I need to go fetch changes every time I'm working on code things to to pull things in to what I'm doing and and how 36:16 I'm getting code back out to those different branches. , I'm becoming much more familiar with the terms. It's becoming second nature . But, I think that's just cuz of my rich exposure to that platform and how I use 36:28 that platform with my agents. Let me ask you another question on this one cuz might be just a a separate thought here. A pattern that I'm seeing evolve in my workflow 36:39 is on my local machine, I have a whole bunch of repos just from different projects all over the place. Throughout my day, I want agents or an 36:50 agent to work on various projects. I use GitHub to track my changes. I use GitHub to keep record of those code items, but a lot more recently, 37:02 I went on a trip. Matthias, you told me this recently for you. I went on a trip and I had a GitHub Copilot running on my computer here locally at home and I had a Claude 37:12 agent running at home. And both of them I turned into remote sessions. , I could talk to GitHub and I could talk to Claude code and give them commands and work on projects. 37:23 I found it really interesting. how do we handle multiple repos, multiple projects with a single agent? 37:34 what I'm finding is I'm pointing the agent starting it locally on my machine, putting it at the root folder. , I do a on my computer I have C repos and 37:45 that's where I put all the repositories of all my projects. I'm pointing the agent at that root level of the folder that it can see every single project. And then I can say, ", agent, we're going to work 37:56 on project Power BI Tips website." Oh, and finds the repo. , I found the repo. I can go into it. There's already an agent file there. It has instructions for the agent. The agent can then have 38:06 context awareness of that project. , I can switch context. And , what I'm doing more often is I'm giving my agent "We're going to work on this 38:16 project for the next 15 minutes or 20 minutes" or build something or fix something. Give it the context, tell it the folder, it goes into it, does the work, it says we're done, we push it, complete it, and then all my CDICD stuff 38:27 kicks in and builds the app. Do you do something similar? Do you point your agents at a root level? Do you only use them in the service? how do What's your workflow with using agents on 38:37 top of multiple repositories or projects? . Yeah, great question. And if if he particularly if he want that 38:47 agent session to be really long-running, which I'm hearing between the lines that that's what you were after, you need to make sure that that Let's call it main agent, that that main agent 38:58 does not do any research or implementation and is merely there to delegate. Oh, interesting. And and if you do that, then you're able to particularly if you use 39:09 Claude, , where you get a million token context window on most models, with that one you can you can go for days and days without , having 39:20 to recycle or restart your session. but only if you're able for this main agent to to take to understand that you've given it a task and then for for 39:32 that agent to be able to delegate to another agent with its own context window to do the task, ? And this is where the GitHub actions integration I talked 39:43 about earlier comes in, ? , you know, that this agent that you're talking about, the one you're interfacing with, that's meant to overlook several projects. If that were 39:54 using GitHub issues for instance to kick off sub agents to work on particular items in inside that particular 40:04 repository all it needed was to produce the prompt create an issue using your GitHub login, which it has on your machine, and 40:15 then have some watcher in place which Claude by the way is really good at to find out when that issue 40:29 when that agent that's running in GitHub actions is done. ? Yep. And high level that that is a very scalable architecture where your main agent is 40:39 the one that you interface with and who understands what's what the world of all your projects but it would never ever go into any of those 40:50 projects specifically because then you waste then you load too much stuff into your context window. It would it would only go as far as 41:02 translate your request into a viable prompt and delegate the prompt to another agent and and that way Yeah. we talked about layering 41:12 earlier that way you are at a very high level Yeah. because all the real engineering exactly everything else happens 41:22 on lower layers which means that happens with dedicated agents that have their own environment their own context window they they get a task they do it they 41:32 come back and then and then an agent one level above responds to to to the to the to the task ultimately 41:43 this is what loop engineering is in in some very simple terms. 41:56 that you can play with but this is definitely an area where we're going to see lots of products and companies and 42:06 and innovation and all of that ultimately ultimately it'll be quite hard for any single engineering team to decide, you 42:16 know, which system do they want to invest into cuz there's just much choice . This is I think the hardest part . Every time I look around the 42:26 corner, there's a new system showing up, a new AI, a new system, a new service that's changing how I want to think about things. We haven't We haven't It It feels to me a lot of the 42:37 technology in the AI space is still proliferating. It's still fracturing and become There's many, many new ideas coming out all at the same time. We haven't quite yet gotten back to the consolidations phase. , , we 42:48 pick these three, four, five handful of things. Innovation is happening fast that we're not able to consolidate yet. We're still There's still the branching effect of many new 42:59 patterns, technology pieces that are coming out. Awesome. All . , I think we've talked about many of our main topics today. We've talked about some pricing. We talked about looping and agents, which I think is extremely 43:10 powerful. We'll have some more reads around that in the near term. One final just point of note here I want to just throw out for people who are using Power BI and specifically 43:20 agents to build Power BI. I haven't had a lot of time to work on it last week, but there's going to be more videos coming here in the near future. Rayfin is absolutely amazing. I think it's a wonderful program that that 43:31 a system that allows us to build things agentically. You may have also heard that the Power BI skills, skills for Fabric, have appeared. And in those skills, you can use skills to go 43:42 talk directly to Power BI Desktop and have Desktop build things for you. , all of these things I think need to be on our docket for explaining and showing and demoing how these tools work 43:53 directly in here on the on the podcast. we'll come up with some good content for Friday. Friday we'll do another session where we're going to get on the computers, share our screens, and show people exactly what's 44:04 happening for , these different tools and systems that are coming out. , that being said, Matthias, thanks for another great conversation. I'm learning much from you. I'm learning much from the community. This is super fun. 44:15 we appreciate your time today. , thank you all for listening. We appreciate you there out there as . Let us know in the comments if you this content, if you what we're doing here, please subscribe to our channel as . It helps us , 44:26 broaden our horizon to other people who may want to hear about this. And if you have questions, submit them down below and we'll , monitor them on YouTube and or probably turn them into new topics. Absolutely. Thanks, Mike. 44:37 Thanks, Matthias. We'll see you all next time. .