Lessons from My First AI Agent Competition

Reflections on building, leading, and and Learning through Friction

Reflections Posted by yidu song on January 30, 2026 · 8 mins read

Introduction

Last December, I participated in the AI Agent Competition hosted by Kakao and KSC 2025 (Korea Software Congress 2025). As this was my first major AI competition, my initial goal was humble: I just wanted to experience the process of drafting and submitting a formal proposal.

To my surprise, the project didn’t just end with a submission. We advanced to the finals and were honored with an Encouragement Award. While the recognition was rewarding, the real value of the journey lay in the “friction” we encountered along the way.

This post isn’t a celebration of a trophy, but rather a post-mortem of the process—a reflection on the technical gaps, the leadership challenges, and the hard-earned lessons that transformed my perspective on building AI agents.

Problem Definition: Chipping Away the Noise

The theme of the competition was “Agents that Innovate Daily Life.” Because the scope was so broad, I realized that maybe I could fall into the trap of spending too much time searching for the perfect idea from the start.

So, I took an iterative refinement approach—what I call the ‘Sculpting Method’. Instead of waiting for a single brilliant spark, I started with a broad domain I was passionate about—Negotiation Agents—and began chipping away at the details. We narrowed it down to Second-hand Market Agents, and finally to Agents that bridge information asymmetry in peer-to-peer trading.

The lesson here was clear: Don’t wait for the right answer; iterate toward it. I also realized that having a curious mind in fields outside of AI—such as economics and the humanities—makes this process significantly easier. It allows you to see pain points that a purely technical lens might miss.

The Proposal: Building a Data-Driven Rationale

If the implementation is the engine, the proposal is the roadmap. Our team received highly positive feedback on our proposal, and I believe the secret was focusing on the narrative arc rather than just technical specifications.

A winning proposal is essentially an essay backed by data. We followed a rigorous storytelling structure:

  1. Defining the Pain Point: What is the actual problem in society?

  2. Structural Limitations: Why haven’t existing solutions fixed this yet?

  3. The Proposition: How does our agent bridge this gap?

  4. Expected Impact: What are the quantitative and qualitative results?

The key is to provide contextual depth to the data. I constantly asked myself: “If I were the judge, would I be persuaded by this logic?” Approaching a technical document with the mindset of a storyteller made all the difference.

Implementation: Confronting the Technical Gap

The implementation phase was the most humbling part of the journey. Our system was built by adapting and modifying NegotiationArena, a framework designed for evaluating negotiation agents. We structured the architecture with two standalone LLM agents, coupled with a rule-based validator to ensure the safety and reliability of the process. At the time, we believed this logic was sound enough for a solid prototype.

However, the finals provided a stark reality check. Other teams showcased sophisticated systems involving Graph RAG or fully-integrated, production-ready services. While our team was the only one composed entirely of undergraduates—competing against graduate-level researchers—the competition didn’t grade on a curve. The gap in technical depth was a stark reminder of the distance between a functional prototype and a production-grade system.

Looking back, I realized that “it works” is not enough. If I could do it over, I would bridge the gap by:

  1. Integrating State-of-the-Art models directly from recent negotiation research.

  2. Conducting User Acceptance Testing to quantify satisfaction rather than just showing a demo.

This experience taught me that in field of AI, there is a massive gap between a working demo and a deep technical approach.

The Stage: Presentation and the Impact of Coordination Delays

The finals were held at the Yeosu Expo Convention Center, where we had to present in front of Kakao officials and fellow competitors. Being the second presenter, I thought I could get it over with quickly and relax. However, the reality was far from relaxed.

I’ll be honest: we encountered critical bottlenecks in the final stages of the project. Due to delays in internal coordination and asset preparation, the time reserved for rehearsal was severely compromised. When I finally stood on that stage, my mind went blank. I ended up reading word-for-word from my script—a moment I deeply regret.

Observing the top-tier teams was another eye-opener. Their technical depth was matched by the polish of their delivery. They didn’t just show a demo; they narrated it, paused for emphasis, and used clean visual designs to guide the audience’s attention.

I learned the hard way that if your logic doesn’t reach the audience, it might as well not exist.

My advice to anyone (and my future self) is this:

  • Front-load your deadlines by at least two days.

  • Buffer for the Blank Out: Only thorough practice can save you when your brain decides to short-circuit.

Leadership: From Passive Trust to System Design

Leading a project team for the first time was a steep learning curve. In the beginning, I thought that setting ground rules for Git branches and commit messages would be enough. I trusted my team to handle the rest.

But I soon realized that trust without a feedback loop lacks accountability. When unexpected variables—like skill gaps or schedule conflicts—arose, I learned that a leader’s job isn’t to blame the individuals, but to design a system where the project keeps moving regardless of those variables. The key wasn’t just delegation; it was:

  • Active Status Checks: Identifying where team members were stuck in real-time.

  • Granular Milestones: Breaking down the big goal into smaller, manageable wins to maintain momentum.

Leadership, I’ve found, is about building a fail-safe system that prevents individual setbacks from becoming project-wide risks.

Closing

This post turned out longer than I expected. Paradoxically, I believe the failures I encountered during the finals provided far more nourishment for my growth than the Encouragement Award itself.

There is a Korean proverb that says, “You cannot be full on the first spoonful.” It means that greatness takes time and repeated effort. This competition was my first spoonful—a mix of a small success and several meaningful setbacks. I intend to use every bit of this experience as fuel to take much larger strides in my next challenge.

Ultimately, I hope this reflection serves as a practical guidebook for those in a similar position. If my trial-and-error can help you navigate your first competition more effectively and save even a fraction of your time, this post will have fulfilled its purpose.