Twelve Labs
페가수스 1.5를 만든 사람들

김수
How Pegasus was brought to life: the story of the Twelve Labs Seoul team. From Researchers and MLEs to Data Engineers, Backend Engineers, and QA — hear directly from the Seoul team on how they built Pegasus 1.5.
How Pegasus was brought to life: the story of the Twelve Labs Seoul team. From Researchers and MLEs to Data Engineers, Backend Engineers, and QA — hear directly from the Seoul team on how they built Pegasus 1.5.

목차
뉴스레터 구독하기
뉴스레터 구독하기
영상 이해 분야의 최신 기술 업데이트, 튜토리얼 및 인사이트를 받아보세요.
영상 이해 분야의 최신 기술 업데이트, 튜토리얼 및 인사이트를 받아보세요.
AI로 영상을 검색하고, 분석하고, 탐색하세요.
2026. 4. 20.
8분
링크 복사하기
When a product is introduced to the world, what usually stands out first are its features and performance.
However, what truly shapes a launch is the judgment, effort, and collaborative process of the people behind it.
The same was true for Pegasus 1.5.
This release was driven by tighter integration across multiple roles—including Research, Machine Learning Engineering (MLE), Backend, Data, and Testing Infrastructure—all aligned under a single goal. Some took charge of training and data quality, while others redesigned the evaluation and serving architectures from scratch. Some built the user-facing API and SDKs, and others accelerated the release quality through automated testing within tight timelines.
Above all, for the Pegasus 1.5 team, this release was more than just a typical upgrade; it felt closer to "building again from the ground up." By restructuring our training code, serving infrastructure, and evaluation methodologies, we laid a solid foundation for the next chapter.
“Externally, it looks like a step up from 1.2 to 1.5, but internally, it felt much closer to starting from scratch again.” |
|---|
Sharper Goals, Higher Standards for Data
One of the major shifts in the Pegasus 1.5 release was that our model development objectives became much more defined.
Instead of simply aiming to improve the model overall, we first defined “which specific problems we want to solve better,” and designed our data and training strategies accordingly.
“I realized firsthand that the vague assumption of 'more data will automatically boost model performance' is wrong. If there is a specific capability you want to excel at, you need to collect data targeting that exact area. That was a huge takeaway for me. Data is King.” |
|---|
This paradigm shift also transformed our Data team. Previously focused primarily on collecting and delivering datasets, this time they worked closely to see how that data was actually utilized in training and where bottlenecks occurred. While past collaborations often felt fragmented—like touching only parts of an elephant—this process connected the entire pipeline end-to-end.
"When we were just handing over datasets, the sense of contributing to the overall company pipeline felt a bit indirect. But seeing how it’s actively used opened up many more ideas on how to spin the model’s flywheel even faster." |
|---|
“In the past, once we handed over the data, the subsequent processes felt like a black box. This time, seeing 'Ah, this is how it’s actually used' and 'These are the challenges' helped us continuously learn and improve.” |
|---|
Broader Roles, Evolved Collaboration
With Pegasus 1.5, individual ownership and roles naturally expanded.
At TwelveLabs, our Engineering and Research teams are organized into a Pod structure. Rather than sticking to rigid functional roles, team members tackle broader challenges centered around product goals. A Pod is a small, cross-functional team formed around a specific goal or product domain. For example, engineers, PMs, designers, and QA work together as one cohesive team with full autonomy over a specific feature or domain.
This allowed ML engineers to manage training tasks end-to-end, data engineers to handle pre-training optimization, and backend engineers to drive everything from API specifications to product integration and SDKs.
“In a functional organization, you're only assigned tasks matching your specific role, but we've transitioned to product-centric Pods. That means you leverage your specialty while naturally stepping into broader areas based on the project's needs. It naturally creates opportunities to engage with and understand higher-level architectures.” |
|---|
“It really feels like individuals are taking full, end-to-end ownership of projects. The scope of work has expanded, and personal ownership has grown significantly, which has been incredibly inspiring for me lately.” |
|---|
This shift wasn't about inflating workloads; it was about empowering individuals with deeper context, which in turn accelerated decision-making and execution.
Intense Timelines, High-Density Progress
(And some of our raw, behind-the-scenes moments)
This release came with tight timelines, described by many team members as incredibly intense. There were nights spent troubleshooting training issues or catch-up naps of just a few hours before jumping right back in.
“To be honest, my most vivid memory is going home at 7 AM on Saturday because the training run failed on Friday.” |
|---|
“There was a night we stayed at the office until 3 AM because a model wouldn't train, and we were so exhausted that we just started joking and laughing hysterically. It had that school-trip vibe... exhausting but incredibly fun. It definitely made me think, 'Yes, I am working at a startup.'” |
|---|
Yet, many noted that this high-intensity environment accelerated learning and growth. Kevin, who initially thought the timeline was nearly impossible, built our entire evaluation platform from scratch, gaining hands-on experience with the complete LLM lifecycle.
“While the schedule was incredibly tight and physically demanding, I can confidently say the payoff and learning experience were absolutely worth it!” |
|---|
Designing for the User Experience
This release went beyond backend optimizations to focus deeply on how users interact with these capabilities in the real world.
Our API design underwent intensive discussions and iterations, moving past just offering features to ensure a highly intuitive developer experience.
Previously, video analysis required an indexing step first. Now, we restructured it so users can process video directly with just a URL. While this shift might seem subtle on the surface, making it seamless took significant engineering thought.
“In the past, model improvements usually meant just updating internal logic, but with this release, we spent a lot of time thinking about how to design the API itself. We needed to keep it highly scalable while ensuring an intuitive flow for developers today.” |
|---|
This evolution extended to QA as well. Instead of simply checking if a feature worked, we evaluated quality based on whether it delivered an exceptional user experience.
“Tests that typically take a week or two were resolved in three to four days, allowing us to catch, report, and fix major bugs quickly, thanks to automated scripts and solid preparation.” |
|---|
Working Face-to-Face in Seoul
Reflecting on Pegasus 1.5, many team members highlighted the impact of working side-by-side in the Seoul office.
The magic wasn't just sharing a physical space; it was about closing the gap between alignment and execution.
Rather than drafting long Slack updates and waiting for overnight responses across time zones, the team could easily hop onto a quick huddle, collaborate on design choices, and make live changes. This speed was driven by having cross-functional decision-makers aligned directly within the Pod.
“We would just jump onto a Slack huddle, design together on the spot, and tackle bug fixes in real-time through pair programming.” |
|---|
“Having our engineering and research teams together in the Seoul office allowed us to align instantly in person, which drastically increased our focus and execution speed.” |
|---|
This went deeper than just better communication—it was a structural evolution in how we build.
Moving away from siloed cross-team handoffs, bringing the key decision-makers into a single, cohesive unit built a true sense of shared ownership. This drastically reduced the overhead of context switching and unlocked rapid decision-making.
“Before, it felt like cross-team coordination, but now that the key contributors are integrated into the same unit, we communicate constantly and build as one true team.” |
|---|
Luke, who managed testing infrastructure, summed up this shift perfectly:
"This one launched exactly on schedule." "Predicting timelines for complex machine learning models is notoriously difficult. Landing exactly when we planned is a testament to the team's maturing expertise and sheer execution. Watching it from the side, the team's synergy was impressive." |
|---|
A Foundation for What’s Next
Importantly, the team views the release of Pegasus 1.5 not as a final product, but as a powerful foundation for future innovation.
During this journey, we built an evaluation platform from zero to one, tightly integrated our data and training pipelines, and laid out a clearer roadmap to iterate and ship models faster.
“This process wasn't just about launching a single product; it was about building our future flywheel. I am confident our next releases will be even faster and more advanced.” |
|---|
There is also a strong sense of pride and healthy skepticism in our work. Lia, an ML Research Scientist, notes that while we have accomplished incredibly exciting things, we are constantly pushing the bar higher.
"Since I built the model, I'm naturally hyper-critical of it. When we did internal blind tests against Gemini, I voted thinking, 'Wow, Gemini is really good, Pegasus won't beat this.' But out of the four votes I cast, three of them went to Pegasus. I'm still trying to find the bug that caused that!" |
|---|
It is this exact spirit—challenging our own work and pushing boundaries—that drove Pegasus 1.5 to deliver outstanding real-world performance.
With an ambitious roadmap ahead, the team is highly aligned, confident, and ready to build next-generation video AI capabilities.
Wrapping Up
Pegasus 1.5 is more than a list of features and performance metrics.
It represents diverse minds collaborating closely, embracing wider ownership, and executing with speed. This shared effort ultimately delivered a powerful outcome.
A team ready to build what's next, faster. Pegasus 1.5 is just the beginning.
To learn more about Pegasus 1.5, visit our → Pegasus 1.5 Tech Blog
We are actively looking for talented individuals to join our journey → TwelveLabs Careers
When a product is introduced to the world, what usually stands out first are its features and performance.
However, what truly shapes a launch is the judgment, effort, and collaborative process of the people behind it.
The same was true for Pegasus 1.5.
This release was driven by tighter integration across multiple roles—including Research, Machine Learning Engineering (MLE), Backend, Data, and Testing Infrastructure—all aligned under a single goal. Some took charge of training and data quality, while others redesigned the evaluation and serving architectures from scratch. Some built the user-facing API and SDKs, and others accelerated the release quality through automated testing within tight timelines.
Above all, for the Pegasus 1.5 team, this release was more than just a typical upgrade; it felt closer to "building again from the ground up." By restructuring our training code, serving infrastructure, and evaluation methodologies, we laid a solid foundation for the next chapter.
“Externally, it looks like a step up from 1.2 to 1.5, but internally, it felt much closer to starting from scratch again.” |
|---|
Sharper Goals, Higher Standards for Data
One of the major shifts in the Pegasus 1.5 release was that our model development objectives became much more defined.
Instead of simply aiming to improve the model overall, we first defined “which specific problems we want to solve better,” and designed our data and training strategies accordingly.
“I realized firsthand that the vague assumption of 'more data will automatically boost model performance' is wrong. If there is a specific capability you want to excel at, you need to collect data targeting that exact area. That was a huge takeaway for me. Data is King.” |
|---|
This paradigm shift also transformed our Data team. Previously focused primarily on collecting and delivering datasets, this time they worked closely to see how that data was actually utilized in training and where bottlenecks occurred. While past collaborations often felt fragmented—like touching only parts of an elephant—this process connected the entire pipeline end-to-end.
"When we were just handing over datasets, the sense of contributing to the overall company pipeline felt a bit indirect. But seeing how it’s actively used opened up many more ideas on how to spin the model’s flywheel even faster." |
|---|
“In the past, once we handed over the data, the subsequent processes felt like a black box. This time, seeing 'Ah, this is how it’s actually used' and 'These are the challenges' helped us continuously learn and improve.” |
|---|
Broader Roles, Evolved Collaboration
With Pegasus 1.5, individual ownership and roles naturally expanded.
At TwelveLabs, our Engineering and Research teams are organized into a Pod structure. Rather than sticking to rigid functional roles, team members tackle broader challenges centered around product goals. A Pod is a small, cross-functional team formed around a specific goal or product domain. For example, engineers, PMs, designers, and QA work together as one cohesive team with full autonomy over a specific feature or domain.
This allowed ML engineers to manage training tasks end-to-end, data engineers to handle pre-training optimization, and backend engineers to drive everything from API specifications to product integration and SDKs.
“In a functional organization, you're only assigned tasks matching your specific role, but we've transitioned to product-centric Pods. That means you leverage your specialty while naturally stepping into broader areas based on the project's needs. It naturally creates opportunities to engage with and understand higher-level architectures.” |
|---|
“It really feels like individuals are taking full, end-to-end ownership of projects. The scope of work has expanded, and personal ownership has grown significantly, which has been incredibly inspiring for me lately.” |
|---|
This shift wasn't about inflating workloads; it was about empowering individuals with deeper context, which in turn accelerated decision-making and execution.
Intense Timelines, High-Density Progress
(And some of our raw, behind-the-scenes moments)
This release came with tight timelines, described by many team members as incredibly intense. There were nights spent troubleshooting training issues or catch-up naps of just a few hours before jumping right back in.
“To be honest, my most vivid memory is going home at 7 AM on Saturday because the training run failed on Friday.” |
|---|
“There was a night we stayed at the office until 3 AM because a model wouldn't train, and we were so exhausted that we just started joking and laughing hysterically. It had that school-trip vibe... exhausting but incredibly fun. It definitely made me think, 'Yes, I am working at a startup.'” |
|---|
Yet, many noted that this high-intensity environment accelerated learning and growth. Kevin, who initially thought the timeline was nearly impossible, built our entire evaluation platform from scratch, gaining hands-on experience with the complete LLM lifecycle.
“While the schedule was incredibly tight and physically demanding, I can confidently say the payoff and learning experience were absolutely worth it!” |
|---|
Designing for the User Experience
This release went beyond backend optimizations to focus deeply on how users interact with these capabilities in the real world.
Our API design underwent intensive discussions and iterations, moving past just offering features to ensure a highly intuitive developer experience.
Previously, video analysis required an indexing step first. Now, we restructured it so users can process video directly with just a URL. While this shift might seem subtle on the surface, making it seamless took significant engineering thought.
“In the past, model improvements usually meant just updating internal logic, but with this release, we spent a lot of time thinking about how to design the API itself. We needed to keep it highly scalable while ensuring an intuitive flow for developers today.” |
|---|
This evolution extended to QA as well. Instead of simply checking if a feature worked, we evaluated quality based on whether it delivered an exceptional user experience.
“Tests that typically take a week or two were resolved in three to four days, allowing us to catch, report, and fix major bugs quickly, thanks to automated scripts and solid preparation.” |
|---|
Working Face-to-Face in Seoul
Reflecting on Pegasus 1.5, many team members highlighted the impact of working side-by-side in the Seoul office.
The magic wasn't just sharing a physical space; it was about closing the gap between alignment and execution.
Rather than drafting long Slack updates and waiting for overnight responses across time zones, the team could easily hop onto a quick huddle, collaborate on design choices, and make live changes. This speed was driven by having cross-functional decision-makers aligned directly within the Pod.
“We would just jump onto a Slack huddle, design together on the spot, and tackle bug fixes in real-time through pair programming.” |
|---|
“Having our engineering and research teams together in the Seoul office allowed us to align instantly in person, which drastically increased our focus and execution speed.” |
|---|
This went deeper than just better communication—it was a structural evolution in how we build.
Moving away from siloed cross-team handoffs, bringing the key decision-makers into a single, cohesive unit built a true sense of shared ownership. This drastically reduced the overhead of context switching and unlocked rapid decision-making.
“Before, it felt like cross-team coordination, but now that the key contributors are integrated into the same unit, we communicate constantly and build as one true team.” |
|---|
Luke, who managed testing infrastructure, summed up this shift perfectly:
"This one launched exactly on schedule." "Predicting timelines for complex machine learning models is notoriously difficult. Landing exactly when we planned is a testament to the team's maturing expertise and sheer execution. Watching it from the side, the team's synergy was impressive." |
|---|
A Foundation for What’s Next
Importantly, the team views the release of Pegasus 1.5 not as a final product, but as a powerful foundation for future innovation.
During this journey, we built an evaluation platform from zero to one, tightly integrated our data and training pipelines, and laid out a clearer roadmap to iterate and ship models faster.
“This process wasn't just about launching a single product; it was about building our future flywheel. I am confident our next releases will be even faster and more advanced.” |
|---|
There is also a strong sense of pride and healthy skepticism in our work. Lia, an ML Research Scientist, notes that while we have accomplished incredibly exciting things, we are constantly pushing the bar higher.
"Since I built the model, I'm naturally hyper-critical of it. When we did internal blind tests against Gemini, I voted thinking, 'Wow, Gemini is really good, Pegasus won't beat this.' But out of the four votes I cast, three of them went to Pegasus. I'm still trying to find the bug that caused that!" |
|---|
It is this exact spirit—challenging our own work and pushing boundaries—that drove Pegasus 1.5 to deliver outstanding real-world performance.
With an ambitious roadmap ahead, the team is highly aligned, confident, and ready to build next-generation video AI capabilities.
Wrapping Up
Pegasus 1.5 is more than a list of features and performance metrics.
It represents diverse minds collaborating closely, embracing wider ownership, and executing with speed. This shared effort ultimately delivered a powerful outcome.
A team ready to build what's next, faster. Pegasus 1.5 is just the beginning.
To learn more about Pegasus 1.5, visit our → Pegasus 1.5 Tech Blog
We are actively looking for talented individuals to join our journey → TwelveLabs Careers
When a product is introduced to the world, what usually stands out first are its features and performance.
However, what truly shapes a launch is the judgment, effort, and collaborative process of the people behind it.
The same was true for Pegasus 1.5.
This release was driven by tighter integration across multiple roles—including Research, Machine Learning Engineering (MLE), Backend, Data, and Testing Infrastructure—all aligned under a single goal. Some took charge of training and data quality, while others redesigned the evaluation and serving architectures from scratch. Some built the user-facing API and SDKs, and others accelerated the release quality through automated testing within tight timelines.
Above all, for the Pegasus 1.5 team, this release was more than just a typical upgrade; it felt closer to "building again from the ground up." By restructuring our training code, serving infrastructure, and evaluation methodologies, we laid a solid foundation for the next chapter.
“Externally, it looks like a step up from 1.2 to 1.5, but internally, it felt much closer to starting from scratch again.” |
|---|
Sharper Goals, Higher Standards for Data
One of the major shifts in the Pegasus 1.5 release was that our model development objectives became much more defined.
Instead of simply aiming to improve the model overall, we first defined “which specific problems we want to solve better,” and designed our data and training strategies accordingly.
“I realized firsthand that the vague assumption of 'more data will automatically boost model performance' is wrong. If there is a specific capability you want to excel at, you need to collect data targeting that exact area. That was a huge takeaway for me. Data is King.” |
|---|
This paradigm shift also transformed our Data team. Previously focused primarily on collecting and delivering datasets, this time they worked closely to see how that data was actually utilized in training and where bottlenecks occurred. While past collaborations often felt fragmented—like touching only parts of an elephant—this process connected the entire pipeline end-to-end.
"When we were just handing over datasets, the sense of contributing to the overall company pipeline felt a bit indirect. But seeing how it’s actively used opened up many more ideas on how to spin the model’s flywheel even faster." |
|---|
“In the past, once we handed over the data, the subsequent processes felt like a black box. This time, seeing 'Ah, this is how it’s actually used' and 'These are the challenges' helped us continuously learn and improve.” |
|---|
Broader Roles, Evolved Collaboration
With Pegasus 1.5, individual ownership and roles naturally expanded.
At TwelveLabs, our Engineering and Research teams are organized into a Pod structure. Rather than sticking to rigid functional roles, team members tackle broader challenges centered around product goals. A Pod is a small, cross-functional team formed around a specific goal or product domain. For example, engineers, PMs, designers, and QA work together as one cohesive team with full autonomy over a specific feature or domain.
This allowed ML engineers to manage training tasks end-to-end, data engineers to handle pre-training optimization, and backend engineers to drive everything from API specifications to product integration and SDKs.
“In a functional organization, you're only assigned tasks matching your specific role, but we've transitioned to product-centric Pods. That means you leverage your specialty while naturally stepping into broader areas based on the project's needs. It naturally creates opportunities to engage with and understand higher-level architectures.” |
|---|
“It really feels like individuals are taking full, end-to-end ownership of projects. The scope of work has expanded, and personal ownership has grown significantly, which has been incredibly inspiring for me lately.” |
|---|
This shift wasn't about inflating workloads; it was about empowering individuals with deeper context, which in turn accelerated decision-making and execution.
Intense Timelines, High-Density Progress
(And some of our raw, behind-the-scenes moments)
This release came with tight timelines, described by many team members as incredibly intense. There were nights spent troubleshooting training issues or catch-up naps of just a few hours before jumping right back in.
“To be honest, my most vivid memory is going home at 7 AM on Saturday because the training run failed on Friday.” |
|---|
“There was a night we stayed at the office until 3 AM because a model wouldn't train, and we were so exhausted that we just started joking and laughing hysterically. It had that school-trip vibe... exhausting but incredibly fun. It definitely made me think, 'Yes, I am working at a startup.'” |
|---|
Yet, many noted that this high-intensity environment accelerated learning and growth. Kevin, who initially thought the timeline was nearly impossible, built our entire evaluation platform from scratch, gaining hands-on experience with the complete LLM lifecycle.
“While the schedule was incredibly tight and physically demanding, I can confidently say the payoff and learning experience were absolutely worth it!” |
|---|
Designing for the User Experience
This release went beyond backend optimizations to focus deeply on how users interact with these capabilities in the real world.
Our API design underwent intensive discussions and iterations, moving past just offering features to ensure a highly intuitive developer experience.
Previously, video analysis required an indexing step first. Now, we restructured it so users can process video directly with just a URL. While this shift might seem subtle on the surface, making it seamless took significant engineering thought.
“In the past, model improvements usually meant just updating internal logic, but with this release, we spent a lot of time thinking about how to design the API itself. We needed to keep it highly scalable while ensuring an intuitive flow for developers today.” |
|---|
This evolution extended to QA as well. Instead of simply checking if a feature worked, we evaluated quality based on whether it delivered an exceptional user experience.
“Tests that typically take a week or two were resolved in three to four days, allowing us to catch, report, and fix major bugs quickly, thanks to automated scripts and solid preparation.” |
|---|
Working Face-to-Face in Seoul
Reflecting on Pegasus 1.5, many team members highlighted the impact of working side-by-side in the Seoul office.
The magic wasn't just sharing a physical space; it was about closing the gap between alignment and execution.
Rather than drafting long Slack updates and waiting for overnight responses across time zones, the team could easily hop onto a quick huddle, collaborate on design choices, and make live changes. This speed was driven by having cross-functional decision-makers aligned directly within the Pod.
“We would just jump onto a Slack huddle, design together on the spot, and tackle bug fixes in real-time through pair programming.” |
|---|
“Having our engineering and research teams together in the Seoul office allowed us to align instantly in person, which drastically increased our focus and execution speed.” |
|---|
This went deeper than just better communication—it was a structural evolution in how we build.
Moving away from siloed cross-team handoffs, bringing the key decision-makers into a single, cohesive unit built a true sense of shared ownership. This drastically reduced the overhead of context switching and unlocked rapid decision-making.
“Before, it felt like cross-team coordination, but now that the key contributors are integrated into the same unit, we communicate constantly and build as one true team.” |
|---|
Luke, who managed testing infrastructure, summed up this shift perfectly:
"This one launched exactly on schedule." "Predicting timelines for complex machine learning models is notoriously difficult. Landing exactly when we planned is a testament to the team's maturing expertise and sheer execution. Watching it from the side, the team's synergy was impressive." |
|---|
A Foundation for What’s Next
Importantly, the team views the release of Pegasus 1.5 not as a final product, but as a powerful foundation for future innovation.
During this journey, we built an evaluation platform from zero to one, tightly integrated our data and training pipelines, and laid out a clearer roadmap to iterate and ship models faster.
“This process wasn't just about launching a single product; it was about building our future flywheel. I am confident our next releases will be even faster and more advanced.” |
|---|
There is also a strong sense of pride and healthy skepticism in our work. Lia, an ML Research Scientist, notes that while we have accomplished incredibly exciting things, we are constantly pushing the bar higher.
"Since I built the model, I'm naturally hyper-critical of it. When we did internal blind tests against Gemini, I voted thinking, 'Wow, Gemini is really good, Pegasus won't beat this.' But out of the four votes I cast, three of them went to Pegasus. I'm still trying to find the bug that caused that!" |
|---|
It is this exact spirit—challenging our own work and pushing boundaries—that drove Pegasus 1.5 to deliver outstanding real-world performance.
With an ambitious roadmap ahead, the team is highly aligned, confident, and ready to build next-generation video AI capabilities.
Wrapping Up
Pegasus 1.5 is more than a list of features and performance metrics.
It represents diverse minds collaborating closely, embracing wider ownership, and executing with speed. This shared effort ultimately delivered a powerful outcome.
A team ready to build what's next, faster. Pegasus 1.5 is just the beginning.
To learn more about Pegasus 1.5, visit our → Pegasus 1.5 Tech Blog
We are actively looking for talented individuals to join our journey → TwelveLabs Careers




