That's what happened to me. And it started with a system that barely worked.

I submitted my Kaggle capstone on December 3rd. It worked, barely. 45 minutes to analyze one research paper, and it crashed about half the time.

I celebrated finishing the semester the way any reasonable grad student would: I slept for 12 hours, avoided my laptop, and caught up on everything I'd been ignoring for weeks.

For a couple days, I didn't think about the capstone at all.

Then I made the mistake of opening the code. Just to look. Just to see what I'd built under pressure.

And I couldn't stop thinking: I know this can be so much better.

So I started working on it again. Not for a grade this time. Not for a competition. Just because I genuinely wanted to see how good I could make it.

By the time winter break was ending, I had a system that analyzed papers in under 3 minutes with 92% accuracy. I use it almost every day now.

This is the story of how a barely-functional capstone became my most useful tool and what it taught me about building AI systems that actually solve problems.

The Five-Day Sprint That Started Everything

The Kaggle x Google GenAI program was intense. Five days of workshops covering LangChain (a framework for building applications with large language models), Gemini APIs, and agent architectures. Drinking from a firehose.

The capstone requirement was straightforward: build something using multi-agent systems where multiple AI agents work together, each handling specialized tasks, coordinating to solve complex problems.

Most people built chatbots or simple task routers. I wanted to solve an actual problem I was dealing with in my Master's program at UF. I read a LOT of research papers for my coursework, and the manual analysis was killing me. Extracting key insights, noting methodologies, cross-referencing results across sections... it took forever.

If I could build a system where specialized agents handled different parts of the analysis like one for extraction, one for summarization, one for cross-referencing that maybe I could get those hours back.

The Three Weeks I Barely Had

The intensive ended on November 14th. The capstone window opened the same day. Deadline: December 3rd.

Sounds like plenty of time, right?

Except I also had semester project submissions and finals starting up. So while the capstone window was technically three weeks, my actual available time was closer to "random hours between cramming sessions and project deadlines."

What I managed to build:

In the scattered hours I had:

• Got PDF ingestion working (mostly)

• Built basic chunking and extraction

• Wired up one agent that could analyze papers

• Added some error handling (not enough)

December 3rd, late night:

I submitted it. The system worked. Took about 45 minutes per paper. Crashed maybe half the time. Error messages were cryptic.

It was functional enough to submit. That's about all I can say for it.

Most people would have moved on. Capstone done, semester done, time to relax.

But something about leaving it in that state bothered me. I knew what it could be, even if I didn't have time to build it yet.

When Celebration Ended, The Building Started

After finals ended, I did what any sane person would do: absolutely nothing. Slept in. Caught up with friends. Avoided opening my laptop unless it was to watch something mindless.

I needed the break.

But after a couple days, I was feeling human again. Bored, honestly. And I made the mistake of opening my capstone code. Just to look. Just to remember what I'd built in that frantic period.

Scrolling through the code, I kept seeing things that made me wince. Hardcoded values that should be configurable. Error handling that was barely there. Architecture decisions I'd made at 11 PM that seemed questionable in the cold light of post-semester clarity.

The system worked. But I knew it could be so much better.

And now I had something I didn't have during the capstone period: TIME. No competing deadlines. No finals to study for. Just me, the code, and genuine curiosity about how good I could make this thing.

So I started working on it again.

This decision to keep building something with no external reward, changed how I think about engineering. It stopped being about the grade and started being about solving a problem I genuinely cared about.

Actually Learning This Time

During the intensive, I'd learned the mechanics of LangChain and agent systems. During the capstone crunch, I'd barely had time to reference the documentation properly.

Now I could actually LEARN.

Started reading papers on arXiv about multi-agent orchestration on how to coordinate multiple agents efficiently, decide which agent handles which task, and manage the communication between them. Blog posts about production agent systems. LangChain documentation, properly this time instead of just ctrl+F-ing for what I needed. Discussions on Reddit and Discord about orchestration patterns and what actually works at scale.

The more I read, the more I realized my architecture was held together with hope and duct tape. It worked, but just barely.

I needed to rebuild it properly. And now I had the time and knowledge to do it right.

The Transformation

I spent the next couple weeks rebuilding core parts of the system:

Memory System: Ditched Python dictionaries for SQLite. Got persistence, proper querying, and the foundation for semantic indexing.

Agent Orchestration: Moved from synchronous to async execution. Instead of waiting for each agent to finish before starting the next, they could now run in parallel where appropriate. Latency dropped 60% immediately.

Observability: Added execution tracing to see actual bottlenecks, not assumed ones.

Reliability: Built retry logic with exponential backoff for API rate limits. When the system hit Gemini's rate limits, it would now wait and retry intelligently instead of just crashing.

Result: 45 minutes → 8 minutes per paper.

Better. But I kept thinking it could be faster.

Each improvement taught me something new about systems design. It wasn't just about making it faster as it was about understanding why it was slow and fixing the root cause.

Finding the Real Bottleneck

This is when I stopped thinking like a student and started thinking like an engineer.

Added P95 latency monitoring (shoutout to my distributed systems course). P95 means tracking the 95th percentile of response times, catching the slowest cases that averages hide. Started tracking every operation to see where time was ACTUALLY going.

That's when I discovered something surprising: the bottleneck wasn't the LLM API calls. It was the PDF processing. I was doing everything sequentially because that was easier to reason about during the crunch.

One async refactor of the ingestion pipeline later: 8 minutes → under 3 minutes.

Got aggressive about caching. Papers don't change after publication, so why reprocess? Reduced redundant API calls by 70%.

Added proper cost tracking (paying out of pocket as a grad student teaches you this fast).

Built session persistence because crashes weren't acceptable anymore. This was a tool I was using for actual coursework.

By the time winter break was ending, I had something I was genuinely proud of:

• Sub-3-minute processing

• 92% extraction accuracy

• Reliable error handling

• Cost-effective

The system I'd wished I could build during the capstone period but didn't have time for.

This experience taught me that assumptions are dangerous. I'd assumed the LLM calls were the bottleneck because they seemed expensive. Data proved me wrong. This lesson of measure first, optimize second has stuck with me.

What Happened Next

But the story doesn't end there.

Somewhere during my research phase, I came across a paper that made me sit up straighter: "Multi-Agent Collaboration via Evolving Orchestration" by Yufan Dang et al.

Reading it felt surreal. The researchers had formalized the exact architectural patterns I'd stumbled into through trial and error. My "Control Agent" the component that decided which agent to call and when was what they called a "puppeteer orchestrator."

I hadn't known the theory. I'd just built what made sense for the problem. And apparently, I'd accidentally implemented an architecture that research was actively validating.

Their findings matched my experience: centralized orchestration (one agent managing others) outperformed both self-organizing systems and flat hierarchies for complex tasks. My Control Agent was doing exactly what their research said would work best.

In Part 2, I'll break down:

• What the research actually says about multi-agent orchestration

• How my architecture matched (and diverged from) their findings

• The single point of failure problem and how I solved it

• What I'm building next with this system

What This Taught Me About Engineering

I didn't win the Kaggle capstone competition. But I learned something way more valuable: real engineering happens when there's no deadline and no grade.

The 5-day intensive taught me the tools. The capstone crunch taught me how to ship under pressure. The post-semester work taught me how to build something reliable.

And finding that research paper? That taught me I was thinking about the problem the right way, even without the formal framework.

The lessons that stuck:

Build for yourself first. The best motivation is solving your own problem. I use this system almost daily now because it genuinely makes my life easier.

Iteration beats perfection. The version I submitted was embarrassing. The version I use now is solid. The difference? Time to iterate without pressure.

Measure, don't assume. I was wrong about my bottleneck. Data corrected me. Observability isn't optional.

Research and practice inform each other. Reading papers gave me vocabulary and patterns. Building gave me constraints and trade-offs. Both perspectives matter.

These experiences shaped how I approach every technical problem now. I start with the real problem, build something that works, measure where it fails, and iterate. Not for grades. Not for résumés. Because solving problems well is its own reward.

And that's exactly the kind of work I want to do professionally is building systems that start as ideas, survive contact with reality, and end up as tools people depend on.

Let's Connect

I'm actively looking for full-time ML/AI Engineering roles starting May 2026. If your team values engineers who ship quickly and iterate obsessively, let's talk.

LinkedIn: https://www.linkedin.com/in/sai-pooja-s6102/

Question for you

Have you ever submitted something you knew could be better, then come back to it later and actually made it better? What drove you to keep building?

Or have you discovered research that validated something you built intuitively? That moment of "wait, I did that without knowing the theory"?

Drop a comment. I'd love to hear your stories.

Part 2 coming soon: "I Built a Multi-Agent System, Then Found the Research That Explained Why"

Where I'll dive into the architecture, the academic research that validated it, and what I'm building next.