Five Builders, One AMD MI300X: How We Built Ani for the AMD Hackathon

At 1:07, the Pipeline Started Moving

At 1:07 in our demo video, we clicked Grade.

A photo of a vegetable harvest had already been uploaded. Ani identified the crop, estimated the visible volume, and accepted the farmer's location. Then the pipeline started moving: grade the produce, estimate its freshness window, match it to potential buyers, and prepare a dispatch recommendation.

That short sequence was the result of five builders trying to turn a Philippine agricultural problem into a working AI prototype during the AMD Developer Hackathon: ACT II.

Ani - Agentic Harvest Grading & Market-Matching on AMD MI300X

We joined Track 3, the Unicorn Track, where teams were judged on creativity, product potential, completeness, and meaningful use of AMD infrastructure. Our answer was Ani, the Filipino word for harvest.

This was not a failure of farming. It was a failure of coordination.

That line became the center of our pitch and the system we chose to build.

The Problem Was Not Another Generic AI Assistant

The Philippines already knows how to grow vegetables. The harder problem is getting perishable produce to the right buyer before oversupply, weak demand, and logistics delays erase its value.

The Department of Agriculture has estimated that 30% of the country's agricultural produce is wasted because of poor logistics. In April 2026, GMA reported that Benguet farmers were dumping unsold cabbage or turning it into fertilizer after oversupply and weak demand pushed prices below sustainable levels.

That gave us a more specific question than "How can farmers use AI?"

Could one photo become an early coordination signal?

Instead of asking a farmer to fill out a long form, Ani starts with the object already in front of them: the harvest. The prototype uses that photo to produce a grade and urgency signal, then carries the result into buyer matching and dispatch prioritization.

The idea was not to replace storage facilities, trading posts, or human crop graders. It was to test whether software could help those systems react earlier.

Five Builders, One Goal

Ani was built by:

• Angelo Sebaxtian Vasquez
• Andre Lacra
• JC Diamante
• Jan Añonuevo
• Jake Manahan

The week moved quickly. We had to turn the problem into a product story, design the experience, build the application, get the model running on AMD hardware, record a short presentation, and make the evidence understandable to judges.

There was no room for the usual "we will clean this up later" comfort. Every decision had to answer one of three questions:

1. Does this strengthen the farmer-to-buyer story?
2. Can we demonstrate it?
3. Can we prove which parts are real?

That third question became increasingly important as the prototype grew.

A Memorable Detour Through the Leaderboard

Two days before the hackathon ended, we were still deep in the build while some teams had already submitted their work.

I was browsing the leaderboard when I noticed something interesting. If I changed the URL and added a team's slug, I could open that team's public submission page. Doing that manually worked for one or two teams, but there were hundreds more.

My immediate thought was: I should scale this.

I wanted a workflow that could:

1. Fetch every team submission listed on the leaderboard.
2. Open each public submission page.
3. Collect its GitHub repository, slide presentation, and project description.
4. Turn the results into something we could study without opening hundreds of tabs.

I tried building it with the models I had access to: GLM 5.2, ChatGPT 5.5, and Sonnet 5. I could get pieces of the solution, but I could not get the complete workflow running reliably.

Then I remembered that Jake had access to Fable 5.

I asked him to give Fable 5 the same task. It worked. The crawler could move from the leaderboard to the public team pages and gather the submission artifacts we wanted to study.

That was already funny enough after my failed attempts, but we took it one step further. I asked Jake to have Fable 5 package the process as a reusable agent skill. He sent the skill back to me, I used it with the models already available on my side, and the workflow finally worked there too.

We were laughing about it in our Discord server while it happened.

The memorable part was not simply that one model succeeded where the others struggled. It was watching one model turn a working approach into a tool that made other models more capable. In the middle of a hackathon about AI agents, Jake and I had accidentally created our own tiny example of agents teaching agents how to use a repeatable workflow.

What Ani Does

The demonstrated flow is deliberately narrow:

1. Analyze the harvest photo. A multimodal model checks whether the image contains produce, identifies the crop, estimates visible volume, and assigns a quality grade.
2. Calculate urgency. The grader returns a freshness window, shelf-life estimate, and recommendation.
3. Match potential buyers. A demand component ranks localized buyer entries using crop, price, and demand context.
4. Prepare dispatch. The logistics component prioritizes the most perishable load and returns a destination, estimated travel window, and matched quantity.

The output is designed to be operational. A farmer should not need to interpret raw model text. Ani returns structured fields the interface can render as a grade card, buyer list, and dispatch flag.

The contracts also made the system easier to build under pressure. The web application did not need to know whether a result came from a deterministic fallback, a hosted model, or the MI300X endpoint. Each backend returned the same shapes.

Three Tiers, One AMD Card

Ani keeps the browser thin, moves orchestration behind FastAPI, and uses an authenticated model endpoint on the MI300X.

The architecture follows one request from left to right:

1. Tier 1, the web experience. A farmer or judge uploads a harvest photo and location through the Next.js interface. The browser never receives the model credentials. Server-side routes proxy the request to the inference service.
2. Tier 2, inference and orchestration. FastAPI validates the request and keeps a consistent contract across the available backends. LangGraph coordinates the harvest grader, demand oracle, and logistics router. The same layer can fall back to deterministic output if a remote dependency becomes unavailable during the demo.
3. Tier 3, model serving. FastAPI calls an OpenAI-compatible vLLM endpoint serving the LoRA-adapted Gemma 3 27B multimodal model through ROCm on one AMD Instinct MI300X in AMD Developer Cloud.
4. The result path. Gemma returns a structured crop grade and freshness assessment. The orchestration layer combines it with seeded market and buyer data, prepares the dispatch recommendation, and sends the final grade, buyer list, and route card back to the web interface.

Two environment variables keep the tiers loosely coupled. INFERENCEBASEURL points the web application to FastAPI, while ANIBASEURL points FastAPI to the private model endpoint. Changing a backend does not require rewriting the interface.

The MI300X mattered for more than the logo in the presentation. AMD lists the accelerator with 192 GB of HBM3 memory. Our configured Gemma service used 153.9 GiB during image inference, including the model, KV cache, and runtime overhead.

We served the model through vLLM on ROCm, kept the model endpoint behind an authenticated tunnel, and exposed only the FastAPI service to the web application. A production request successfully travelled from Vercel to FastAPI and returned a response tagged with the MI300X source.

That end-to-end path mattered more than a screenshot of GPU telemetry. It proved that the accelerator was load-bearing.

The Numbers We Can Actually Defend

We fine-tuned the grader with LoRA on a balanced produce dataset prepared from FruQ-DB:

• 300 total examples across fresh, mild, and rotten classes
• 240 training examples
• 60 examples reserved for evaluation
• One epoch on the MI300X
• A reported balanced slice of 30 held-out images, 10 per class

The committed run produced:

The most tempting number in that table is 100%.

It is also the number that needs the largest warning label.

Thirty examples and one seed are not enough to claim that the model is a perfect crop grader. The confidence interval is wide, the training loss fell quickly, and the result still needs more seeds, the full evaluation split, field images, different lighting conditions, and independent crop graders.

The honest result is simpler: on one small held-out slice, the adapter improved the point estimate from 86.7% to 100%, and we committed the receipts needed to inspect that claim.

We took the same approach to latency. The polished demo narration included an early speed figure, but the number we can defend is the final benchmark of roughly 1.4 seconds end to end across 20 sequential requests. A repeatable measurement is more useful than the fastest number observed during a demo.

What Broke During the Sprint

The clean diagram hides the messy parts.

Our original plan expected Gemma to be available through Fireworks AI. The model was not available in the account catalog, and the expected endpoints returned errors. We stopped treating Fireworks as a prerequisite and made the MI300X deployment the primary path.

Then the infrastructure started teaching us its own lessons:

• Distributed initialization initially selected the wrong network interface. Pinning the Gloo and NCCL interfaces fixed it.
• The first image request paid a large Triton compilation cost. Warmups and cached compilation made later requests steady.
• A first dataset split placed related image sequences across different labels. We discarded it, assigned sequences globally, and verified zero train-to-evaluation overlap.
• A startup diagnostic printed an API key. We rotated it, redacted the launcher, and checked the committed receipts for secrets.

None of those failures appeared in the two-minute demo. They were still part of the project.

The useful lesson was not "hackathons make you build fast." Everyone already knows that.

It was this:

Under a deadline, evidence is a feature.

A fallback path keeps the demo alive. A typed contract keeps the tiers interchangeable. A benchmark receipt turns a performance claim into something another engineer can challenge. A failure log prevents the final architecture diagram from becoming fiction.

What Was Still a Prototype

Ani is not a deployed agricultural marketplace, and we should not describe it like one.

The current photo-based volume is a rough model estimate, not a calibrated weight measurement. The buyer feed uses seeded and localized market entries, not a continuously updated production feed from every NCR buyer. The ROI calculator is a scenario model, not a measured farmer pilot. The router prepares a dispatch recommendation, but it does not control trucks or execute commercial contracts.

Those limitations do not erase the prototype. They tell us what the next validation work should be:

1. Compare photo grades against independent human graders.
2. Test volume estimates against actual weighing scales.
3. Connect dated Department of Agriculture price data and real buyer inventory.
4. Pilot with one cooperative and measure whether earlier signals change what gets sold.
5. Evaluate failure cases across crops, lighting, packaging, and partial spoilage.

The next milestone is not a larger model. It is better evidence from the field.

Submitted, Measured, and Waiting

We submitted Ani to the AMD Developer Hackathon with judging still underway.

Whatever the result, I am proud that our five-person team moved beyond a slide-deck idea. We built the interface, deployed the inference service, fine-tuned and served a multimodal model on AMD hardware, recorded the end-to-end flow, and published the code and benchmark receipts.

You can inspect the project in the Ani GitHub repository.

If you were validating Ani for a real cooperative, what would you test first: grading accuracy, buyer data quality, or whether the recommendation changes an actual dispatch decision?

That answer matters more than making the next demo look faster.