Turn 10,994 Notes Into Memory - Paul Iusztin, Decoding AI & Louis-François Bouchard, Towards AI

I spent 18 months turning my Second Brain into my living research memory. Let me explain. So, within my Second Brain I currently have over 5,000 notes in Obsidian, and another 5,000 notes in Readwise, and some scattered in Notion and Google Drive, and all of this is growing on average with 250 files per month.

And this is what I want: on the left you can see my whole Obsidian vault, this huge mess, and whenever I start working on something, such as an article, a new project, a new codebase, a new feature, or whatever, I want to actually pull high-signal notes that are actually useful for my current work.

And you would ask yourself, why not use directly Codex, Claude, or NotebookLM? And the thing is that I am, but you need a system that sits between those harnesses and your Second Brain. Okay, so let's go back to the root of my problem, which is that I'm always losing my research.

For example, my reading list is a graveyard. When I'm scrolling social media and I see that cool X post, a new article, a new YouTube video, a GitHub repository, it doesn't matter. Whenever I actually want to start working on something, I never recall what I have in my Second Brain, or I have to spend a ton of time actually finding meaningful notes that I can use in my work,right?

And another problem that I have is that I want the system to actually be anchored into my personal notes, into my personal values, into my personal faiths. I want the system to be personal, to reflect my own thoughts,right?

And that's why in today's video, Louis-François and I will teach you how to build your own AI research OS. This also comes with code, so you can also try it out yourself. And I'm Paul Iusztin, I'm the Founder & CEO of Decoding AI, where I do a ton of content on courses on how to ship AI products, and I'm also the co-author of the LLM Engineer's Handbook bestseller.

And the system, the AI research OS, that I will teach you in this video is the system that I use in my daily work. And now I will pass the torch to Louis-François.

Thanks, Paul. So I'm Louis-François Bouchard. I'm the co-founder & CTO of Towards AI, where we build educational courses, and I'm also the creator of What's AI, a YouTube channel where I explain AI engineering techniques I used to explain AI research before, now focusing on AI engineering.

I'm also the author of the book Building LLMs for Production. And before that, I was a PhD student. So I honestly make research for a living. I used to do a PhD, as I said, in AI, and doing tons of research and research work.

Now I build courses, I write videos, I research for videos, I build trainings for companies for a living. And all of these things that I do start with very good research, and also leveraging tons of knowledge and insights that we get at Towards AI from building for clients.

So I have tons of notes as well, just like Paul, and we try to leverage them the best possible. And as you'll see, we'll build some sort of tool to leverage our Second Brain, where, as you'll see, there will be some differences between how I use it and how Paul uses it.

And that's the core goal of the repository that we built on this project, is that we want you to adapt it for your needs. The whole goal is, how can we make research better, but more specifically, how can we better leverage what we have.

So let's dive into it. And first, we need to figure out which tool to use and when, because this whole research system that we built is not for every query. If you just need a fast answer, like a few quick questions, or just something where that you would just Google, basically, well, obviously just Google it, or ask ChatGPT, Claude, whichever system you want.

But the problem when doing that is that if you have a lot of following-up questions, or it's a bigger project that you need to build on, and have basically a very long context or tons of information to share, relying on ChatGPT isn't ideal.

And it also means that you are fully dependent on the architecture that OpenAI or ChatGPT's team built. So the next step here is to ask yourself, for a more complex problem, do you need to act quickly, or do you want to build some next feature and do something very difficult?

If you just have a small repo for a quick change, or write one article, just do one thing that you know won't be repeatable that much, definitely use Codex or Cloud Code, or some agent that you trust. Sometimes you need to keep on digging to make it better, to improve efficiency, optimize it more.

And so typically, when you have to do that, you want your research sources, your research, to stick and to be able to refer to them in the future. So if you want a process like this, where the sources that you find, the notes that you take, stick around in time, and have an agent be able to leverage that efficiently, and being able to come back to this information, to ask follow-up questions, to digest content even more.

Andright now, for instance, when I make a new video, I want also the agent and the system to understand the previous videos I made, to not duplicate content, to not repeat myself, and to refer to some other content.

In this case, there are some tools that are very interesting that you might have tried before, like NotebookLM, that is super powerful to do research, to digest content efficiently, and to come back to it. But the problem with NotebookLM is that it's, well, first, the main problem is that you don't own it.

You cannot do anything you want with it. You cannot personalize as much as possible. It's not agent-native, and it's obviously weak for coding tasks, since it's just browser-based. So it's far from ideal, from something that Paul and I needed, and that most AI engineers need in general.

So if you need your agents to be able to leverage all you do, whether it is a big research, a new video, whatever you write, you do, you code, you typically want your other agents, your other projects, to be able to leverage what you learned from what you just did.

And one thing that we advise, especially for production, obviously for a product, is to build some sort of retrieval RAG pipeline with vector databases. But this needs an infrastructure. It's not really human-friendly to be able to digest quickly, to check notes, to make edits.

It's hard to inspect by hand. You need to build everything around it. It's definitely far from ideal for just something I want to use on a daily basis. Obviously, it's super powerful at scale, very interesting, especially in a product.

But as I said, this project is for us. And I don't want something live, super professional as a product. I just want something I will use, and that my agents and different projects can leverage as best as possible.

So the last question to ask ourselves here is that if you want everything there, but more personalization, so a personalized research assistant that builds some sort of Wikipedia that compounds over time, and is easily inspectable and usable, where you have tons of sources, documents, videos, comparisons, implementations, new research, new topics that you keep on adding, and that you keep on wanting to leverage and review easily, this is where you may want to build something yourself.

And in our case, we built the personalized research OS that we will share in this talk with exactly what we built and how. But the downside is that it definitely needs a bit more setup than just opening Cloud Code.

Right now, the main problem with using Cloud Code and other agentic tools is that you give Codex links, PDFs, and different information. For example, my most recent Loop Engineering video. And then the next session, you use Codex. You have to paste it all again, or ask it to use skills.

And whatever structure that Codex or ChatGPT, whatever tool that you use, built on the fly to leverage what you did, the scripts it ran, the scripts it had, you all lost it or kept it inside a skill that you have to ask it to reuse, and that usually isn't ideal, and just grows and grows over time.

And the problem is that all this information that you give to the model is not the bottleneck. The bottleneck is, how can you leverage it in the future? Meaning that with an agent, the context window becomes everything: the database, the file system, the memory, the reasoning space.

It has to do it all, and when you stop the conversation, it loses everything. And the thing is that we don't need necessarily to provide more and more and more context for a better research. You need a proper memory and context management, and ideally, some personality with it, especially in my case when I do videos.

So what we did is that we decided to build a system with plain files, mostly Markdown files, that we can leverage easily, and that agents can leverage easily. I won't detail it very much here, because Paul will talk about it in depth.

And as I said, Paul has like 5,000 or something notes. I have just a few hundred. But that's just to say that we need to consider that we didn't start from nothing. We already both had some sort of large database.

In my case, I made hundreds of videos, and I take many notes. So I still need to leverage these years of content that I already made, and tons of meetings that I have with my team, with clients, when we build for them, that I want to leverage as well, because we learn a lot by building for people.

We have highlights from interesting tweets that I see, interesting articles that I see, and I want all my projects to be able to leverage my agent skills. So I decided to pivot, and instead of having a folder for Cloud Code skills, and having all my meeting recaps in granola, and having years of notes on Apple Notes, and the tweets on a saved Chrome tab, instead, I moved everything automatically into Obsidian.

It's just a note reader, obviously, so you don't have to use that. You can just save it locally. But I used Codex to set up everything so that granola is automatically saved there. My notes are now on Obsidian, just because it's a nice UI.

I like it, and I can use it from my phone, my computer, my Windows, Mac, everything. So anyways, I moved everything to Obsidian, which means that it's saved locally in my file system, which means it's basically my companion for researching and building everything I build now.

And what we built, obviously, leverages that. We built a repo called AI research OS for this workshop, where it's basically just skills for Cloud Code and Codex with plugins, to be able to do a very deep research about a topic, or a simpler search or destination, different tools that you can use.

The most useful and complete one will be the research tool that I use, for example, when I kick off a new video topic. And the goal of this repo is to have you implement it, install the Cloud plugins from it, and tune it to your needs.

Right now, it can connect to, as I said, Obsidian with my local notes. It can use Readwise, NotebookLM, your GitHub repos, any links that you send for GitHub or YouTube videos, and web links, obviously, and documents. But there are tons of things missing, as we will discuss in the end, that you can easily implement, just asking Cloud Code or Codex to do so.

Like, for example, I implemented the YouTube video transcript in, honestly, a few seconds, just one prompt. It's super easy for Codex to implement it. So the thing is that this whole repository and this whole project is a very useful companion for my own work.

But as I said, it implements tons of features and state-of-the-art context management and memory management techniques that I believe AI engineers need to know. And now, Paul will dive into all this three-layer system that we built with the raw content, the index that I mentioned, and the wiki-like synthesized version of all your notes, all your research, all your work.

So he'll cover everything we did, how it ended up, and show how to use it.

Okay, so now I want to go over the three versions of our system, and how it progressed over time, and most importantly, why we added more complexity. So in the first version, we wanted to scope it just to create lessons for our Agent Engineering course.

So we wanted to keep it super simple, where we had as input a topic and a research MD as output. So within the input, we had the topic, plus a set of golden links, which were manually handpicked by us.

We applied this deep research algorithm, and we had as output a static research MD file. And if we go and zoom into the architecture, we first scraped the links of the golden links,right, because we already know them, and we use them as seed for context for the deep research algorithm, which was a really powerful technique, because we had more context on how to frame our questions.

And during the query rounds, we basically used a very classic deep research algorithm, where we had one main agent, the orchestrator, which created multiple questions based on the initial topic and the scraped context. And each agent managed its own question, and used Gemini, drawn it in Google to query it, basically Google, and gather multiple resources.

And each agent gathered these resources, which returned multiple links and created some executive summaries of each link. And then it passed all this information back to the agent, to the main agent, where the main agent basically aggregated all this information into a summarized way, so it did not explode in the context.

And we did this for three rounds. So basically, after three rounds of generating six queries per round, we ended up with like 40, 50 links in total. So you can imagine that there's a lot of noise over there.

So that's why we also applied a ranking algorithm, where we wanted to find the information with the highest signal. And basically, we compared each source against the topic, the initial topic of the user. And like that, we fully scraped only the top K elements based on the ranking score, and for the rest of the links, we just kept the summaries.

And then we compiled everything into this research MD file as a single flat file, which we used for each lesson of our course in our particular use case. But as you can imagine, it was pretty limited. For the course, it worked great,right?

We generated 35 lessons really quick. But we wanted more. So we started to aim this deep research loop to the Second Brain as well,right? Before, it was targeting only the public web, which made this pretty generic, and we had to manually find all those golden links.

So by aiming this deep research loop to the Second Brain, where we basically organically keep track of all the information of all the research that we really want, and it's filtered by us, we can organically gather all those golden links into our deep research algorithm.

So let's look at how this new algorithm looks like. It's basically the same loop,right? But now we target our own sources instead of just the public web. Now for input, we have only the topic, because we don't need the golden links.

As I said, the golden links are actually a reflection of our Second Brain system. In theory, you can also add them if you really want to, but that's the beauty of this new strategy, because you can just put as input some topic, and we'll find everything that it needs.

And then we use this topic only as seed for the context to generate the queries. And now we do the same deep research algorithm,right? The same query rounds, but instead of targeting only the public web, now we plug in all our Second Brains, such as our Obsidian, our Readwise, our NotebookLM, our GitHub.

You can also use, for example, Gemini deep research for this, like similar to how we use NotebookLM, or you can extend this with whatever you want, for example, YouTube, Google Drive, Notion, or whatever makes sense on your infrastructure.

The idea is that now we target our queries from the deep research algorithm to our Second Brain, plus the public web. And after we apply the same algorithm, such as ranking, fully scraping summaries, and compile everything into this research MD file.

But now we have another problem,right? This research MD file is static. It's a pile of static data. And usually, research is not static,right? So after you end up with this file, you most often realize that you want to ask another question, or some information is still, and you don't need it anymore, or basically, you want more out of this research MD file, which means that you need to start all of this from scratch.

And the operation that I showed you above is an expensive operation. It consumes a lot of tokens, and it takes a lot of time. So you don't want to run it from scratch. And that's why you need to add a wiki layer on top of it.

And that's why v3 of this system is actually a deep research algorithm, plus an LLM knowledge base on top of it, aka the wiki layer. So the new algorithm looks like this. So we have sources in and a wiki out.

And the sources, as I said before, can be like Obsidian, NotebookLM, Google Drive, or YouTube, Notion, even custom URLs,right? That's also powerful as well, where you use tools such as BrightData to parse basically any single-page application, any type of site, any type of public information that's out there, we can put it in.

And then you apply the same deep research algorithm. You store everything into raw files,right? Instead of compiling everything into a research MD file, now we store each file individually. And we create an index out of all these files.

And ultimately, we generate a wiki on top of it, which we can query. We can query basically the wiki plus the index. Okay, so this is just the high-level architecture of the new system. Let's zoom into it. So what I want to start with is that you should forget the infrastructure you think you need, such as vector databases, knowledge graphs, semantic search, text search.

All that is beautiful, but adds a lot of complexity, especially for like these personal wikis, personal research operating systems that you want to use very lightly. So I want a system just based on files,right? A simple mechanism that's very rooted into how your computer works.

And that's why we'll create all the system just based on files and just based on references. So no database, just a simple index based on references. And how this works, we have an agent that reads an index.yaml file that's basically a catalog of all your data, plus the summaries of each source and some metadata around it.

For example, here on theright, you can see part of an index.yaml file that contains 10 sources and 38 wiki pages as derivatives of these sources, where we can see there into the sources list of the YAML file, the first source, for example.

And as you can see, it has like the link to the original file, plus some metadata such as the origin, the title, the authors, the publication date, the summary, and things like this, which can be flexible,right? And the next step is that based on this index.yaml file, we need to point to all the wiki pages, to all the wiki derivatives, to all the raw sources.

So basically, this index.yaml file is an entry point for our agent,right? It's what we will give to our agent to actually reason on how to find our data. It's an index, ultimately,right? So the next step is to understand how the wiki actually looks like.

So on the left, you can see the high-level structure of the wiki, where we have the raw folder, the wiki folder, and the index. In the raw folder, we actually just have the raw data, which is immutable. You don't want to touch that.

And the index points to everything that we need. And in the wiki, we actually have derivatives created by the LLM, which contains things such as comparisons between multiple concepts, entities, or just simple notes as a reflection of our questions or repositories that we ingested.

And we can create multiple notes based on a repository,right? Or open questions that, based on our questions, that the LLM couldn't answer yet. And everything that you can analyze on top of your raw data. And on theright, based on Obsidian, we can see like the subgraph reflected just based on this index.

And this is just like the first iteration, but as the wiki grows, you can see connections made between entities and concepts. For example, concepts are things such as tool registry, context compaction, sandboxing. Or entities are open code, cloud code, MCP,right?

So as you can see, you can beautifully start visually and practically create connections. Now, the next of us question is, how do we actually query this wiki? So as I said, the agent will have as input this index.yaml file, which contains summaries and metadata about each source.

But what happens next,right? The next step is actually to look into the source wiki page, where the source wiki page is like an executive summary of each page. It's basically not just a summary, but a more expanded summary of each source.

And sometimes, the agent just looks into this, gets what it needs, and goes back, which is very token efficient,right? And if it doesn't find within this source wiki page, we also need links into the wiki derivatives, such as concepts, entities, notes, comparisons, and so on and so forth.

And only if it doesn't find the necessary information up to this point, it needs, and it actually reads the whole raw source,right? Which basically contains the whole article, the whole paper, the whole video, or whatever. And this makes, just through pure referencing and creating this simple hierarchy, this makes everything very token efficient.

Now, the beautiful part is that this wiki is actually alive,right? For example, every question leaves a trace into your wiki. So for every question, the LLM can create a new concept file, a new note file, a new comparison file, and every question is tracked into a log.

So basically, the wiki doesn't evolve only when you ingest new data or do a deep research round. It actually evolves as you start talking with it,right? That's the beautiful part, actually. And like that, you can see a true reflection of yourself, of what you haven't understood, of all your questions from the past.

And the beautiful part is that the wiki is never frozen,right? Similar to the research MD files. At any point, you can ingest a new custom link that you think that you need into the wiki, or even run a new deep research round.

Or as I said previously, the wiki keeps evolving just purely based on your questions. And another important thing to understand is that this wiki doesn't sit on top of your entire Second Brain,right? For example, in my particular use case, I use the PARA method coined by Tiago Forte, where all my data is structured between project areas, resources, and archive, where all my notes, resources that I save, sources that I save, PDFs, articles, or whatever, are just piped directly into the resource, a flat list.

And whenever I need something, I just reference them into projects and areas,right? And like this, Obsidian is just an immutable snapshot that the LLM never touches,right? So this is my data. I don't really want the LLM to touch my personal notes that I manually write,right?

So then how can we actually put this wiki to use,right? So as I said, we have the big Obsidian snapshot, which is our global Second Brain. And then whenever we start to work on a new project, we reference this Second Brain through this deep research algorithm that I explained, and we scope it down to our own project,right?

So basically, whenever we want to start working on something, we run this deep research loop, or we start ingesting some particular repositories, articles, notes, and so on and so forth. And we usually do that through a set of skills plugged into a harness.

And a project can be basically anything, such as writing a new article, doing a new video, doing a set of slides. I apply this technique doing this slide. Or you can even apply it for something more complex, such as writing a book, doing a course, or keeping track of a whole code base,right?

You can also use it for that. So basically, a project can be anything where you want, as I said initially, to transform research into work. The project is the work, and your Second Brain is the research. So now I want to show you a few demos.

So what you need to do is go to the AI Research OS workshop repository. And here you can find all the skills required to run what we presented into this presentation. And everything is packed as a Cloud Code plugin, but you can very easily tweak it and install it with any other harness.

And also in the README, you can find details on how to install all the other dependencies, because the thing is that this system is dependent on tools such as Obsidian, Readwise, NotebookLM, and so on and so forth. So you need to set up specific CLIs or authentication issues.

But I don't really want to waste any of your time with setup issues, and I want to go straight directly into the examples. So I prepared here three examples. The first one is a research on one of my previous articles on agentic engineering.

And within these files, I have a brain dump of everything that I knew I wanted to talk on this subject. And on top of that, I also added a few references that I knew 100% that I want to add into this wiki.

And what we need to do to actually trigger the algorithm on top of these files is to open up a Cloud session and then just call the skill, the research skill, and point it to this file. And that's it.

Everything else is baked directly into the skill. It will understand my intent that I want to create a wiki on agentic harness engineering, just looking at these files and looking at the topic. And it will know that before starting the deep research algorithm, it actually needs to scrape this information to use it as context when it frames the questions for the deep research algorithm.

Now, we need to wait a bit for the agent to reason on top of it. And I will actually just put it on auto mode to speed this up,right? I use this hundreds of times, so I know it won't delete anything from my computer, or it won't do anything weird.

Okay, so now this is the most important part,right? So it asks me how deep I want the deep research algorithm to be. We have light, deep, fast. This mostly controls how many questions you want to run per one round and how many rounds you want to run.

And usually, light or fast is more than enough, because remember, this process consumes a lot of tokens. So you kind of need to do the deep one only when you really want to look over tons and tons of notes.

And for this use case, I will just pick the light one to speed this up. And in this use case, it just does one round of three queries,right? And for the fast one, it does two rounds of three queries.

So I will just keep it around that spectrum. And now the process will take around 10 to 20 minutes to actually look around my Obsidian, to look around my Readwise, my NotebookLM, and run those queries on top of this.

And I actually run this,right? And now let's open this wiki that we created based on the prompt before in Obsidian, and let's look what's inside the wiki. So we have three big objects, the raw files, which are basically a raw copy of what we found, the index, which contains all the references towards the wiki,right?

We can also in Obsidian have this beautiful subgraph where we can very quickly understand what is going on. This is created purely based on this file. And then the most interesting part is inside the wiki, where we have comparisons, concepts, entities, and sources.

The sources contain the executive summary of our raw sources, so the LLM doesn't really need to every time when it reads them, and it needs them to read the raw sources, but it needs just the executive summaries, which are computed just one time during the ingestion.

And for example, for the comparisons, it understood out of the box that it needs to do comparisons between like agentic RAG versus file systems, or compaction versus recursive language models, or anything of interest based on the sources. And the most interesting part is actually the concepts.

So it automatically extracted all the concepts that we need to understand from this pile of resources. For example, if we open the agent loop resources, we automatically can look and get this beautiful summary containing graphs, text, and explaining us everything that we need on this topic.

And we can do the same on all the concepts from this wiki, or on the entities from the wiki, and so on and so forth. Okay, so now let's go to the second example. It's a simple example where I want to learn more on harness engineering and how harnesses work.

So in this prompt over here, I just want to ingest the three open source repositories on OpenCode, Py, and Hermes. And I don't want to do deep research at all,right? I just want to ingest those repositories and explore topics such as the general architecture, agents architecture, sub-agents, memory system, and the agent permission flow.

And let's run the research on top of these prompts. And now what the research will do, it will clone automatically all these repositories and will explore all the repositories on the topics that I gave here. And it will create notes at the individual level of each repository on how they work, on how the architecture works at the repository level.

And then we can create higher-level notes,right, within the wiki derivatives and compare other architectures or create aggregate architectures on the general trends of all those harnesses. And basically, explore and learn everything that we want about harness engineering directly from the code.

And again, usually I just do auto mode and let it do its own gist, but I already run this,right? So here is the wiki for these GitHub repositories. And again, we have the raw files, and we have the index and the wiki.

And here, probably within the repos, we can see all the three repositories. And for example, inside the OpenCode repositories, we can see empty files explaining everything that we need on particular topics, such as the permission flow, the memory system, and so on and so forth.

And we can see this in all the other repositories. And the most interesting part here is actually that we have comparisons on all of these,right? So we can actually understand the differences within the architecture within these harnesses. Or we also have all the concepts extracted from these repositories, and we can understand what are the key architectural decisions from these repositories.

So you can go crazy with this, and this is super useful if you want to, for example, write your own harness. And the third example is the simplest one in reality, which is just based on ingesting some simple links,right?

And again, I will just exit the previous run, and I want to run this example from scratch. And here, I just want to show you that you can use this also with a very basic setup where I just want to ingest three custom random links.

And as before, I just pass this prompt, and it will start the research process. And I want to highlight that you can run example 2 and on the GitHub repositories and this example without any other setup, like without setting up Obsidian, Readwise, or anything else.

You can just install this plugin and run these examples, because here is not dependent on any other service than Git and using code to get these URLs. And again, here, if we go into Obsidian and explore the wiki, create it out of this example 3, we can see the index, we can see the wiki itself with all the sources,right?

One executive summary for each source and all the concepts, extracted entities, and so on and so forth. And the idea is that as you start asking questions on top of this, everything starts to get more interesting. So now let's assume that we want to ask, for example, a question on harness engineering based on the wiki created out of the GitHub repositories.

So what we have to do is just, again, hit the research skill, point it to the wiki that we just created, and then just ask our question. And let's assume that I want to learn more on sandboxing, more exactly how remote sandboxing works and how it's plugged into the harness.

This can be basically any other question. And now what it will happen, it will basically query this wiki. It will give you an answer. And based on this, you can also start creating notes, comparisons, or maybe it will extract and find new entities that you care about.

Basically, it will start updating the wiki.

Allright, so now where is this project going? What is it? What should you do? First, it's still rough at some points. Like it needs more connectors, as you saw. We need to add Google Drive, Notion, Slack, and tons of other connectors that could be useful to you.

But to be honest, it's not really useful to me and my current workflow or to Paul. So we didn't add them yet, because the core of this project is to be useful for us and for you to take over and add whatever you need.

And the other main goal of this project is to teach memory and context management. So all these extra features aren't really useful towards that purpose. There are other some weaknesses, like it's hard to know which sources are outdated or weak or strong compared to some other system that we built.

So we know we can improve this, but again, it's not really the priority here. And lastly, it's still obviously a builder workflow. You use it through Cloud Code and Codex, and it's just to me in the terminal, and I just really like it.

So it's not a final polished product with a nice UI, nice UX. And honestly, that's by design. So we don't really care about this, because our goal is to teach AI engineering. It's not to build the next best product.

Still, we have a few next improvements we want to do very shortly, from having a stronger linting to a better memory compaction, because that's a big issue, and it's just very complicated in general to manage memory correctly. And the state-of-the-art is always progressing there.

We, as I said, need better source provenance to trust the sources and be able to rank them properly and reuse them properly if needed, and be able to know assets quickly as a user if this source is relevant or not.

And we have other next improvements to do. But those are mostly for optimization and for the future. And the thing is that we actually built all of that into another product that you can even build yourself, because we created a course called Agent Engineering, where we built a similar deep research system with a writing and research agent, where we build a system with the same goal to be able to learn best AI engineering practices.

It's a very in-depth course where I assume it takes around 60 hours to complete, with a final project being the multi-agent system I just described that you'll build for yourself. So if this presentation and the demo repo that you saw was interesting, please consider checking out the Towards AI Academy with our courses on there, including the Agent Engineering course, to learn more on the best practices when building around and with agents.