As someone who takes a lot of notes, I’m always looking for tools and strategies (such as the Cornell Method) that can help me improve my own note-taking process. And while I generally prefer pen and paper (because it’s been shown to help with memory and synthesis), there’s no denying that technology can help improve our accumulated abilities. This is especially true in situations like meetings, where actively participating and taking notes can conflict with each other at the same time. Being distracted by looking down or tapping away at the keyboard to jot down notes can make it difficult to stay focused in a conversation. Because you have to quickly decide which details are important, and there’s always the risk of missing important details while you’re working. I’m trying to capture the old one. Needless to say, when faced with back-to-back meetings, summarizing and extracting important details from pages of notes becomes more complicated, and when considered at the group level, the waste of individual and group time is significant. Modern businesses with this type of management overhead.
As we face these challenges every day, our team—a small team of tigers we like to call the Office of the CTO (OCTO)—saw an opportunity to use AI to enhance our team meetings. They developed a simple and straightforward proof of concept to record and summarize virtual team meetings using AWS services such as Lambda, Transcribe, and Bedrock. This allows you to collect notes from the meeting, but automatically captures the finer details of the discussion, allowing you to stay focused on the conversation itself (it also creates a to-do list). And today we’re open sourcing this tool, which our team calls “Distill,” in the hope that others may find it useful as well. https://github.com/aws-samples/amazon-bedrock-audio-summarizer.
In this post, I’ll walk you through the high-level architecture of the project and how it works, as well as preview how we worked with Amazon Q Developer to transform Distill into a Rust CLI.
Structure of a simple audio summary app
The app itself is simple, and that’s intentional. I agree with the idea that a system should be as simple as possible, but not simple. First, upload the meeting’s audio files to your S3 bucket. The S3 trigger then notifies the Lambda function, which starts the recording process. An Event Bridge rule is used to automatically invoke a second Lambda function when there is a Transcribe operation starting with: summarizer- Status has been newly updated. COMPLETED. Once the recording is complete, this Lambda function takes the recording and sends it to Bedrock with instruction prompts to generate a summary. In our case we are using Claude 3 Sonnet for inference, but the code can be adapted to use any model available in Bedrock. Once the inference is complete, a summary of the meeting, including high-level takeaways and to-dos, is saved back to your S3 bucket.
I’ve talked many times about the importance of handling infrastructure as code, so we used the AWS CDK to manage the infrastructure for this project. CDK provides a reliable and consistent way to deploy resources and ensure that the infrastructure can be shared by anyone. Additionally, it provided a great way to iterate on ideas quickly.
distillation use
If you try this (and I hope you do), setup is quick. Clone the repository and follow the steps in the README to deploy the app infrastructure to your account using the CDK. After that, there are two ways to use the tool:
- audio file
sourceSelect a folder in the created S3 bucket, wait a few minutes, and check the results here:processedfolder. - Use the Jupyter notebook we put together to step through the process of uploading audio, monitoring transcription, and retrieving audio summaries.
Below is an example output (minimal deletion) from a recent OCTO team meeting where only a portion of the team was able to attend.
Below is a summary of the conversation in readable paragraphs.
The group discussed potential content ideas and approaches for upcoming events such as VivaTech and re:Invent. There were suggestions for keynote addresses and fireside chats or panel discussions. The importance of creating thought-provoking upcoming events was highlighted.
In summarizing Werner’s recent tour of Asia, the team reflected on key points such as engagement with local college students, developers, startups and underserved communities; Indonesia’s initiatives on disability inclusion were highly praised. Helpful feedback was shared on logistics, balancing work and downtime, and the optimal event format for Werner. The group plans to investigate ways to translate these learnings into an internal newsletter.
Other topics covered included upcoming advisory meetings that Jeff could attend virtually, and the evolving role of the modern CTO with an increasing focus on social impact and a global perspective.
Key action items:
- Change the team meeting schedule to next week
- Lisa distributes agendas for future advisory meetings when available.
- Roger, drafting potential panel questions for VivaTech
- Explore recording/streaming options in the VivaTech panel
- Determination of cross-team content ownership for Asia Tour highlight recaps
Plus, the team created a Slack webhook that automatically posts these summaries to team channels, so people who can’t attend can see what was discussed and quickly review action items.
Remember. AI isn’t perfect. Some of the summaries included above contain errors that require manual reconciliation. But it’s still okay. Because it still speeds up the process. This is just a reminder that we still need to be discerning and engaged in the process. Critical thinking is more important than ever.
There is value in solving everyday problems little by little.
This is just one example of a simple app that can be quickly built and deployed to the cloud to increase organizational efficiency. Depending on which study you look at, about 30% of business employees say they don’t complete action items because they don’t remember key information from a meeting. You can chip away at those statistics by getting personalized notes delivered right after the meeting, or having an assistant automatically create action items from the meeting and assign them to the right people. Technology doesn’t always solve “big” problems all at once. Sometimes it’s about solving everyday problems little by little. We look for simple solutions that become the foundation for progressive, meaningful innovation.
I’m particularly interested to see where this goes next. We now live in a world where AI-powered bots can monitor your calls and act in real time. Take notes, answer questions, track tasks, remove PII, and even search for items that distract and slow down calls while an individual is trying to find data. By sharing our simple app, we don’t mean to show off the “shiny new thing”, but to show that if we can build it, you can too. And I’m curious how the open source community will utilize this. Extension method. What to build on top of it. And this is what I find really interesting. The potential for simple AI-based tools to help us in more and more ways. It is not a replacement for human ingenuity, but an assistant that makes us better people.
To that end, while working on this project with my team, I started my own pet project to turn this tool into a Rust CLI.
Building a Rust CLI from scratch
I blame Marc Brooker and Colm MacCárthaigh for turning me into a Rust enthusiast. I’m a systems programmer at heart, and as I became more familiar with the language, my heart started beating much faster. And this became even more important to me when I came across Rui Pereira’s amazing research on the energy, time and memory consumption of different programming languages ​​and realized its enormous potential to help build more sustainably in the cloud.
While experimenting with Distill, we wanted to see what effect moving a function from Python to Rust would have. Using the CDK, we were able to quickly change our stack to move our Lambda functions to the AL2023 runtime and then deploy Rust-based versions of our code. If you’re curious, this function had an average cold start that was 12x faster than the Python variant (34ms vs. 410ms) and used less memory (21MB vs. 79MB). Inspired, I decided to get my hands dirty. I was planning to turn this project into a command line utility and put some of what I learned in Ken Youens-Clark’s “Command Line Rust” into practice.
I’ve always loved working from the command line. every grep, catand curl That little black box reminds me a lot of driving old cars. It may be a little more difficult to turn, it may make a bit of noise and complain, but you will feel a connection to the machine. Actively using code, like taking notes, helps you stay on task.
Since I’m not a Rust expert, I decided to test Q. I still have many questions about the language, idioms, ownership model, and common libraries I’ve seen in sample code like Tokio. To be honest, learning how to interpret what the compiler objects to is probably the most difficult part for me of Rust programming. With Q open in my IDE, it was easy to ask “silly” questions without stigma, and using the references Q provided meant I didn’t have to dig through tons of documentation.
As the CLI began to take shape, Q took on an increasingly important role, providing deeper insights that informed coding and design decisions. For example, I was wondering if using slice references would cause inefficiencies when the list of items is large. Q was quick to explain that while fragmenting an array may be more efficient than creating a new array, it will likely impact performance at scale. It felt like a conversation. Q allowed me to bounce ideas off, feel free to ask follow-up questions, and receive prompt, non-judgmental answers.
The last thing I would like to mention is the ability to send codes directly to Q. I’ve been experimenting with code refactoring and optimization, which has helped me understand Rust better and allowed me to think more critically about my code. I wrote. This shows how important it is to create a tool (in my case, an IDE) that builders are already comfortable using.
Coming soon…
I plan to share the code for my Rust CLI in the coming weeks. I need some time to finalize this and ask more experienced people to review it. You can get a sneak peek here.
As always, start building now! And get your hands dirty while doing it.
