Looking Back on My First AI Agent Competition

Introduction

Last December, I entered an AI agent competition that Kakao and KIISE held at KSC 2025. At first I just wanted the experience of writing a proposal and getting it submitted. Then, without really expecting it, we made the finals and won an Encouragement Award.

This post is a record of what happened along the way and what I took from it.

Picking a Topic

The theme was agents that change everyday life. Everyday life covers so much that we could easily have spent all our time just picking a topic.

So I started with a broad area and kept narrowing it down. I went from negotiation agents, which I was already interested in, to agents for secondhand trading, and then to agents that close the information gap between buyers and sellers in secondhand trading.

Looking back it's an obvious approach, but if I had tried to find the perfect answer from the start, I think I would have just wasted time. Carving the idea out of a big block worked much better than trying to plan everything up front. It also made me think this kind of process gets a lot easier when you've spent time poking around fields outside AI, like economics or the humanities.

Writing the Proposal

The preliminary round judged proposals, and the finals were about actually building the system. Our team got very positive feedback in the preliminary round.

What I cared about most in the proposal was the story. We defined a pain point that society or a specific industry has, pointed out the structural limits of existing approaches, laid out what we were proposing, and described the quantitative and qualitative effects we expected, all as one flow.

For the problem definition at the start, I put a lot of work into using objective data to show the problem was real and worth solving. Instead of just listing statistics, I wrote it like an essay and built a story around the numbers. The whole time, I kept asking myself whether I would buy this argument if I were a judge.

Building It

Building the system was the most painful part of the competition, and also where I learned the most.

We built two LLM agents on top of NegotiationArena and added a rule-based checker, with the idea that it would keep the negotiation safe. But when I saw the other teams at the finals, the bar was much higher. Some had added Graph RAG, and some brought services that actually worked.

We were the only team made up entirely of undergrads, and we were up against teams of mostly grad students, but competitions don't grade on that. In the end, our lack of technical depth was our biggest mistake. If I did it again, I wouldn't stop at a working prototype. I'd add more depth, like using negotiation models from recent papers or connecting to a real chat service to measure user satisfaction.

The Finals

The finals were held at the Yeosu Expo Convention Center, where we presented in front of people from Kakao and the other teams. We presented second, so we finished early and could watch the other teams in a fairly relaxed mood. Watching them, I realized how much the overall preparation and the quality of the slides and demo videos affected the results.

Honestly, I didn't manage our schedule well. The slides took much longer than expected, so I was working on them right up to the deadline and had no time left to polish a script or practice. I stayed up until dawn getting ready, but once I was on stage my mind went blank. I ended up reading the script word for word, and I really regretted that.

The top teams put as much effort into persuading the audience as into the technical side. Their slides were clean, and they did things like adding narration to their demo videos or pausing the video to explain. You could tell they had thought hard about how to get their point across.

That's when I realized that no matter how good my argument is, it doesn't count for much if it doesn't reach the audience. Next time I'll set my own deadline at least two days early and keep time aside for practice. It also made me want to volunteer to present more often in team projects at school.

Leading the Team

While we were preparing, unexpected things kept coming up, like gaps in skill between teammates, schedule conflicts, and simply not having enough time. Through that, I realized a team lead's job isn't to blame teammates. It's to set up rules and systems so the project keeps moving no matter what.

It was my first time leading a project team, and I was pretty inexperienced. At first I split up the roles, set rules for git branches and commit messages, and vaguely trusted that everyone would take it from there. But setting rules and never following up was pretty close to leaving people on their own.

What mattered most was checking in regularly and giving concrete milestones. I needed to keep track of where each person was stuck and spell out the intermediate goals so the overall schedule didn't slip. In the end, leading the team wasn't just about dividing up work. It was about building a feedback loop so one person's setback didn't turn into a risk for the whole project.

Next time I lead a team, I'll respect people's independence but first make sure the work is being tracked clearly.

Wrapping Up

At first I only wanted to submit a proposal, and somehow we made it to the finals. The result was nice, but learning where I fell short meant more to me. Next time I want to use what I learned here and do even better.