Agenda
The full program of DevFest Milano 2026.
Welcome
Coding Gym
Coding Gym is an international format of programming labs open to any language. It is designed for continuous improvement, guided by the principles of the Coding Gym manifesto: "We help others practice programming, software development, and communication skills by making coding laboratories open to any programming language where cooperation is valued over competition, doing and sharing are valued over teaching, and where competing solutions come with discussing and understanding tradeoffs." How It Works: Coding Gym is NOT a contest! Participants ("gymmers") work in pairs on 2 self-contained problems using any programming language of their choice, all within a browser. After each exercise, a Coding Gym "trainer" moderates a retrospective session where gymmers present their solutions, discussing pros, cons, and tradeoffs. The trainer may also set new questions such as "What happens if the input size increases by 100 times?", or may introduce new solutions and concepts, potentially altering the problem on the spot to encourage discussion on changes and their impact. These variations can lead to discovering new ways of simplifying or complicating the problem. Philosophy: Coding Gym is not tied to any specific paradigm or programming language. It uses any tool, technique, or paradigm necessary to achieve its goals, promoting freedom in problem-solving. For each problem, Coding Gym encourages gymmers to explore, study, and experiment with alternative solutions and variations. This approach helps participants break free from their mental patterns, evolving and learning new concepts and techniques. Each new solution brings compromises, advantages, and disadvantages that must be identified and understood as part of the practice. A key aspect of Coding Gym is recognizing that technical skills alone are not sufficient. Professionals also need to master effective communication and collaboration. Coding Gym provides opportunities to practice these skills directly, enabling participants to collaborate with others and to explain their ideas and solutions in public. We eliminate stress, anxiety, and strict deadlines, replacing them with a fun and friendly atmosphere that fosters creativity and personal growth. More information on https://coding-gym.org --- Coding Gym has been conceived, developed, and directed by Marco Arena since 2016.
Beyond Text: Multimodal RAG with Gemini and Firestore
In this session, we'll make the leap from traditional RAGs to Multimodal RAGs. You'll learn how to use Gemini models to generate document embeds and index them natively in Firestore. Discover how to build applications that can simultaneously "see" and "read" your database, maintaining a 100% serverless architecture and without the complexity of managing external vector databases.
What's Left for Developers When Agents Write the Code
The short answer is that the job doesn't disappear, it moves. When AI compresses implementation, the bottleneck shifts upstream and downstream: requirements, architecture and verification stay human-paced, while a developer's value moves from typing the solution to defining goals, boundaries and acceptance criteria. The same raw model, inside different harnesses, produces very different results, so the useful question is no longer only which model, but which system runs it. In this talk (inspired by the latest SDLC paper by Addy Osmani & c) I will walk through the shift from implementor to conductor and orchestrator, and from vibe coding to agentic engineering, with the concrete pieces that make the difference: rule files and context engineering to give an agent the onboarding you'd give a new colleague, MCP to connect it to real tools, hooks and tests as a safety net, human review as a gate that changes shape but doesn't disappear. I show a demo using Antigravity (recorded probably or live) harness intercepting an error live, because the point isn't a perfect agent, it's a verifiable process. People leave with one operational question: how much of their project's standard is readable by an agent today, and where they can start without risking production.
We gave AI twelve weeks to build the perfect employee: We will never need to hire a senior again
There is a generation of bright, capable people knocking on the door of every knowledge industry right now, and almost nobody is opening it, because companies want senior hires, experienced hires, ready-made hires. Junior talent gets the polite rejection because nobody has time to train them, and the assumption is that without three to five years of someone else doing the work first, they will not be ready. That assumption is about to age very badly, because the gap between a smart, motivated junior and a productive professional used to be filled by years of slow apprenticeship, and now it can be filled by a structured curriculum, an AI tutor that knows the methodology cold and an assessment that pressure-tests the reasoning. The years were never the point, the knowledge transfer was, and AI just changed what knowledge transfer can look like. So we did something different when we scaled our own firm from zero to thirty people in a few short years, building it almost entirely from people the rest of the industry would have rejected as too junior. They were trained in twelve weeks, billing by week thirteen and running their own engagements by month six. The talent was always there, what was missing was a way to develop it that did not take half a decade and a senior mentor we could not spare. In this session we will go through the full design, the curriculum that compresses years into weeks, the role of AI as tutor, sparring partner and assessor, the skills map that defines what "ready" actually means across five levels and eighty-two competencies, the mistakes from the first cohort that taught us as much as they cost us and the honest answer to what the shortcomings of this approach are.
Minions AI che rispondono agli ordini!
VPS, install.sh, chiave del bot Telegram ed il nostro primo Minions AI è pronto. Due prompt e inizia a fare cose, vedere gente. Tutto bello, quasi magico. Aggiungiamo Minions, "workflowizziamo" sempre più cose, ma dopo un mese ci accorgiamo che passiamo più tempo a dare martellate per aggiustare cose, rispetto a crearne di nuove. Un distillato di tutto il sonno perso in questi mesi per ridurre al minimo il conto che il non deterministo degli LLM prima o poi ci presenta, tra skill design, pattern organizzativi e strumenti di supporto agli harness. Partendo dalla produttività personale con Hermes Agent in salsa self hosted, ma applicable a tutto il resto.
Coffe Break
The New Assembly Line: Designing AI Agents That Work Like Ford's Factory
After its debut at Coderful 2026 in Catania — where it was met with great enthusiasm and strong technical engagement — this talk now brings its mission to the GDG community: a full immersion into the world of AI Design Architecture applied to multi-agent systems. Ford didn't know it, but he was inventing the future of artificial intelligence. The idea that transformed industrial production — breaking a complex process into specialized stations, connected by precise handoffs — is today the most powerful paradigm for building AI systems that actually work in production. A single monolithic agent suffers from the same pathologies as an assembly line run by a single worker: context dilution, lack of specialization, inability to parallelize, confirmation bias. The result? A one-way ticket to the AI project graveyard — that silent cemetery of ambitious pilots that never made it to production. The answer is the digital assembly line: a multi-agent architecture where each station receives the output of its predecessor, applies its specific function, and passes the transformed artifact to the next station — with typed schemas, clean handoffs, and full technological heterogeneity across stations. In this talk we will explore the three pillars of the assembly line applied to AI: Structured workflow — Graph workflows and multi-agent orchestration with Google ADK: when to use a deterministic approach and when to leave room for autonomy. Technological heterogeneity — Sub-agents, Tools, MCP, and the A2A (Agent-to-Agent) protocol: how to equip agents with tools and enable them to interact with data sources or with each other. Structured handoffs — how to eliminate structural hallucinations and make the pipeline robust and self-corrective using input/output schemas with Pydantic. All of this through a concrete, narrative use case — built live, slide after slide, line of code after line of code with Google ADK — all the way to the complete final architecture.
The Meta-Harness: Scaling Agentic Development Beyond the CLI
Agentic development feels magical to some and overhyped to others. Harnesses like Claude Code or Codex have been built around the local loop: a single developer changing code before opening a PR. Inside organizations, agents hit walls: repo boundaries, a lack of memory and unresolved issues around trust. Fixing this requires a higher level of abstraction: the *meta-harness*. Just as meta-frameworks let React stay simple, a meta-harness keeps the agent CLI focused on its job while bringing the pieces teams need to ship. Big AI labs, open-source tools and startups are building tools and hoping to be the next platform that makes AI be a force-multiplier for teams. This talk is going to sample their approaches and make the case for the meta-harness as the next frontier for org-wide adoption.
AI On-Device: Cooking from your fridge with Gemini Nano, MobileCLIP and Gemma
What happens when you commit to running every piece of AI in your app on the phone itself — no cloud, no API keys, no server logs of your users' kitchens? We built AI Pantry, an Android app that scans your fridge with the camera, recognizes the ingredients and generates recipes — 100% on-device. Our first choice was the obvious platform one: Gemini Nano, Android's new built-in on-device model. One dependency, zero megabytes of weights in the APK — perfect, except it only runs on brand-new flagship phones (Pixel 9/10, Galaxy S25/S26), not on the devices most users actually own. So we pivoted to plan B: bundle a single multimodal LLM (Gemma 4 E2B) and use it for both vision and text. It worked. It also took 5–10 minutes per scan on a mid-range phone (Pixel 7). This session is the story of fixing that, with real code and real measurements: - Gemini Nano via ML Kit GenAI Prompt API: the model lives in AICore, an Android system service — not in your app. You get multimodal prompts (photo + text in, text out) against weights you never ship, download, or update: zero MB in your APK, hardware acceleration included. The integration is one dependency and one rule: availability is a runtime question, so gate every single call with checkStatus() — the same phone can answer differently over time (model not yet downloaded, or evicted). Used this way, Nano becomes a free accelerator on supported devices, with your own detector as the everywhere-fallback — never the foundation the app stands on. - One model to rule them all — and why it crawled: we bundled Gemma 4 E2B and asked it to look at the fridge photo and write the ingredient list as JSON. The catch is how multimodal LLMs work: first the photo becomes ~1,000 image tokens that must all be processed before a single word of output (the prefill), then the answer is generated one token at a time (the decode) — hundreds of sequential passes through a 2-billion-parameter model. On a mid-range phone, that arithmetic adds up to a 5-to-10-minute scan. Know this two-phase cost model before promising any multimodal UX. - Zero-shot ingredient detection with MobileCLIP-S2 on LiteRT: recognition doesn't need a model that writes — it needs one that compares. CLIP-family models use two small encoders that turn an image and a phrase into vectors in the same space, so "is this a watermelon?" becomes a cosine similarity instead of a generated sentence: one fixed forward pass of a ~140 MB encoder, no prefill, no word-by-word decode. To make it work we built the vocabulary ourselves — a curated list of hundreds of ingredient labels — embedded it offline on a laptop, and bundled just the vectors (~4.5 MB): the phone only runs the image encoder, and the "classifier" is an editable text file. Add an ingredient? Add a line. Result on the same phone: minutes → seconds. - Where the LLM earns its keep: recipes are creation, not recognition — the one job no closed vocabulary can do, so Gemma stays, via LiteRT-LM, and we make it feel fast: two-stage prompting (first a few-token list of recipe ideas, the full recipe only when you tap one — shorter prompts, less waiting), defensive JSON parsing with silent retries (small models may break format contracts, plan for it), and text-only generation streaming at 15–25 tok/s — on a phone, watching the recipe write itself is a feature, not a wait. - Shipping it: each model travels differently. Gemini Nano costs you zero megabytes — AICore owns it. MobileCLIP's ~140 MB encoder ships inside the APK like any asset. But Gemma's 2.6 GB of weights fit in no APK, and hand-rolling a downloader for multi-GB files (resume, integrity, metered connections) is a project in itself — so they travel as AI packs via Play for On-device AI, riding Google Play's own delivery pipeline. The user just installs the app; distribution stops being your problem. Key takeaways: 1. Match the model class to the task: perception ≠ generation. Recognizing what's in a photo is a comparison problem; writing text is a generation problem. Using a generative model for perception cost us minutes per scan — swapping in a discriminative one brought it down to seconds, on the same phone. 2. Platform AI is a capability, not a foundation. Gemini Nano/AICore gives you a free, zero-MB multimodal model — but only on recent flagships, and availability changes at runtime. Detect it with checkStatus() on every use, exploit it when present, and always have your own fallback underneath. 3. The cheapest ML you'll ever ship is a text file. With CLIP-family models, precomputing label embeddings offline turns zero-shot classification into "an editable list of ingredient names + ~4.5 MB of vectors" — no dataset, no training run, no ML infrastructure. Extending the classifier is adding a line. 4. Learn the two-phase cost model before promising any multimodal UX. A photo becomes hundreds of image tokens that must all be processed before the first output word (prefill), then the answer comes out one token at a time (decode). That arithmetic — not the model's quality — decides whether your feature takes seconds or minutes. 5. With small on-device models, defensive parsing IS the API contract. They will occasionally break your output format: plan for lenient JSON parsing and silent retries from day one, so the user sees results, not errors.
Become a Founding Engineering - you're already ready!
I took the leap of jumping from IC to Founding Engineer over the last year and it's been a huge learning curve. While trying to contribute meaningful code to realise an idea, I have learned a lot in terms of internal politics, culture, and management. You can't just sit back and code behind a screen, you have to become a people person and get your hands dirty in every pie. This is what it takes to build a $100M revenue business in health care over 12 months. This is not a place I thought I'd be but I wanted to share how important it is for people to take the leap to build new and cool things, with cool people - how meaningful and rewarding the work is, and how it's more important than ever in our current era where you can prototype anything with a single prompt.
L'IA che usa la tua app al posto tuo: Testing Agentico su Mobile
Scrivere test di UI su mobile spesso significa combattere con setup complessi, selettori fragili e manutenzione continua. E se, invece di scrivere codice di test, potessi semplicemente dire all'app cosa fare? Il Testing Agentico permette a un agente IA di collegarsi a un'app in esecuzione, esplorarla come farebbe un utente reale e verificarne il comportamento seguendo istruzioni in linguaggio naturale. Non si limita a osservare lo schermo: sa anche quali elementi dell'interfaccia sono presenti, quali sono interagibili e come usarli. In questo talk vedremo un agente all'opera su un'app mobile reale: eseguirà tap, scroll e input, interpreterà ciò che accade sullo schermo e controllerà che il risultato sia quello atteso, utilizzando strumenti open source come Marionette MCP. Parleremo anche dei limiti di questo approccio. Quando ha senso affidarsi a un agente? Cosa può fare meglio dei test tradizionali e cosa, invece, continuerà a richiedere assertion deterministiche e test scritti a mano? Attraverso una demo live costruiremo un flusso di testing agentico in pochi minuti e vedremo come questa nuova classe di strumenti possa affiancare, non sostituire, la strategia di testing di un'app mobile. Smetti di combattere con i test. Inizia a parlare con la tua app.
Lunch
From Prompts to Production: Building Android Apps with Skills and MCP Tools
In this session, we'll explore how to move beyond basic prompting by combining custom Skills and Model Context Protocol (MCP) tools to create a powerful Android-focused development environment. Through live demonstrations and real-world examples, you'll learn how Skills can encode architectural guidelines, coding standards, and project knowledge, while MCP tools provide secure access to external systems, documentation, APIs, and development workflows. Together, they enable AI agents to understand your codebase, automate repetitive tasks, and assist with complex Android development activities.
Before Delegating to Agents: ADRs and Spec-Driven Development as the Foundation for AI in the Team
SPARklE manages real users' energy data and provides guidance with direct financial impact. In this context human control isn't negotiable. But that doesn't mean giving up on AI: it means building the right foundations before delegating. The project started as a EU/PNRR-funded research initiative, with four companies involved and features explored freely. When WellD decided to turn it into a product, we found ourselves with a completely different backlog than expected, and an architecture that showed the marks of the research phase's pace. Two practices helped us rebuild solidity without slowing down development. First: a formal Architecture Decision Record system where developers and architects discuss a decision with AI, stress-test it with explicit alternatives and trade-offs, and submit it to adversarial review by the team before moving forward: decisions are more solid, shared, and traceable. Second: Spec-Driven Development, which forces us to refine requirements before writing code and which lets us delegate part of the development to dedicated agents, while keeping human supervision and quality verification on every step. This isn't a full multi-agent system yet. It's the infrastructure a multi-agent system needs to operate reliably in a domain where mistakes have a real cost. Key takeaways: In domains with sensitive data and financial impact, AI gets introduced by building control foundations, not bypassing them. ADRs with adversarial review make architectural decisions more solid and shared, with or without AI Spec-Driven Development is the practical prerequisite for delegating development to agents while keeping human oversight
Vibe Coding with AI & Antigravity
Learn how to build production-ready AI applications using Antigravity, from local development to deployment, while leveraging modern AI-assisted development workflows.
L'incidente non parla PromQL: un'interfaccia naturale sopra il tuo stack di osservabilità
Un alert scatta. Apri la dashboard e trovi due indizi che si contraddicono: un segnale punta in una direzione, un altro, nello stesso momento, punta in un'altra. Quale dei due segui? Nessun runbook scritto a priori copre il caso in cui due segnali indipendenti puntano altrove, ed è più o meno sempre così quando l'incidente è quello vero, non quello da manuale. Durante il talk presenterò un agente che fa esattamente questo mestiere: guarda log, trace e metriche di un incidente reale e sceglie tra più cause plausibili quando le prove non convergono: un'interfaccia che ti risparmia di ricordarti dove cercare e con quale sintassi interrogare ogni backend. Lo dimostro dal vivo con LangGraph, orchestrando query verso uno stack di osservabilità (OpenTelemetry, Loki, Tempo, Mimir). Racconto la costruzione di un approccio che sto mettendo alla prova, non ancora una soluzione pronta: come si dà al modello la libertà di scegliere quale fonte interrogare più a fondo per ogni ipotesi, quando fermarsi, e come argomenta una conclusione con un livello di confidenza anche quando restano cause aperte, invece di restituire un verdetto univoco e definitivo.
Agentic Commerce: Redefining E-Commerce across UCP, Web MCP, and Physical Retail
E-commerce is undergoing its most profound technological shift yet: moving from active user navigation to Agentic Commerce, where autonomous AI agents discover, configure, and purchase products on our behalf. But how do system architectures adapt when our primary counterpart is no longer a human browsing a screen, but a Large Language Model executing transactions? In this talk, we will explore the evolving geography of digital commerce by comparing key protocol paradigms: the native backend approach of the Universal Commerce Protocol (UCP) launched by Google and Shopify, the financial/transactional framework of OpenAI and Stripe's Agentic Commerce Protocol (ACP), and the client-side approach of Web MCP. We will demonstrate how this revolution extends far beyond traditional online storefronts to empower the physical retail space. Through a real-world storytelling lens focused on travel retail and high-traffic environments (railway stations, airports), we will examine how sharing real-time catalogs, inventory, and capabilities via APIs allows AI agents to manage context-aware orders and pickups in physical locations. Finally, we will dive into concrete architectural patterns for enabling this transition: designing a serverless middleware on Google Cloud (Cloud Run, Firestore, Vertex AI) to deliver low-lateny responses, "AI-Ready" data structures, and resilient fallback strategies when physical and digital workflows converge.
Coffee Break
When Agents Work for Different Companies
Inside one organization, agent governance is already difficult. Across organizations, it becomes a strategic coordination problem. If agents represent different companies, who can delegate work? Who can approve tool access? Who verifies completion? Who is accountable when something goes wrong? Froglet explores this emerging problem space: multi-agent workflows where participants do not share the same owner, objective, or trust boundary. This talk is a strategic look at the future of inter-company agent systems and the infrastructure needed to make them trustworthy: incentives, permissions, commitments, audit trails, and human escalation.
Video Production Is an Orchestration Problem: Lessons From a 34,000-Star Open-Source Agentic System
Most agentic AI aims at developers. This talk points it at work with no developers at all — producing video — and treats it as what it really is: an orchestration problem. OpenMontage is an open-source multi-agent system (12 pipelines, 52 tools, 34,000+ GitHub stars) that turns a single prompt into a finished, edited video. I'll go past the demo into the architecture that makes autonomy reliable: single-responsibility "stage director" agents coordinating through a durable artifact-and-checkpoint contract on disk instead of fragile conversation state. I'll be honest about what didn't work — the mega-prompt monolith, coordinating agents through chat history — and why each failed, then take a real run from prompt to finished video live on stage. You'll leave with a concrete, reusable blueprint for orchestrating multi-stage agentic work in your own domain, developer or not.
AI-Native Web Development, Hands-On
The way we build for the web just changed: AI no longer only autocompletes code — it builds a real page, runs it in the browser, tests it, and fixes its own mistakes. In this fully hands-on session you'll experience that shift firsthand, going from a blank screen to a modern web page you designed and shipped live, all in one sitting. Whether you're a student making your first real project or a professional modernising how you work, you'll leave with something real online and a way of building you can put to use the very next day.
Teaching Old Code New Tricks: Transforming Legacy Backends into AI Tools with Spring AI
Everyone is talking about AI Agents, but the reality for most enterprise developers is quite different: massive databases, monolithic APIs, and deeply layered business logic that cannot simply be rewritten from scratch. Yet, the true potential of Large Language Models isn't just in generating text—it's in executing actions. How can we allow an AI Agent to interact securely, deterministically, and efficiently with our legacy systems? In this talk, we will explore how to use the Spring AI ecosystem to build a robust bridge between generative models and existing infrastructure. We'll dive into the architectural patterns and design choices needed to transform legacy code into standardized "Tools" ready to be consumed by LLMs via Function Calling.
AURA: A Practical Risk Framework for Autonomous AI Agents
Autonomous AI agents are moving from experiments into systems that touch real customers, money and infrastructure, yet many teams still improvise their safety practices, with maturity and governance representing one of the major barriers to AI deployment. This session presents AURA, an open source Agent Autonomy Risk Assessment framework developed from research and production deployments at the University of Exeter. We turn diffuse concerns about “rogue agents” into concrete risk dimensions and a quantitative scoring model that engineers, product owners and risk stakeholders can use in a shared, repeatable way. Using realistic failure scenarios for tool using agents, we show how AURA helps you reason about autonomy levels, capability scope, tool access, oversight mechanisms and monitoring. The focus is on integrating risk thinking into your existing MLOps stack through checklists, scorecards and design templates, managing Governance and Compliance requirements. Attendees will leave with a reference risk scoring tool, example assessments and a set of practical steps for embedding agent risk reviews into their current development and deployment lifecycle.
Agents Speak Protocol: Why Standards Are the Real Infrastructure of AI
Every major computing revolution eventually standardized how things talk to each other. Before TCP/IP, networks spoke dialects. Before HTTP, every service invented its own wire format. Before REST, SOAP was the only "enterprise" answer. Each time, entropy was reduced not by building better applications, but by agreeing on how they connect. We are at exactly that inflection point with AI agents. Today's agent ecosystem is a tower of Babel: agents speak different frameworks, tools are wired with one-off integrations, UIs are bolted on as afterthoughts, and client communication is reinvented per product. This is not a feature. It is entropy, and it is expensive. This talk maps the emerging protocol stack that is finally bringing order: MCP for agent-to-tool context, A2A for peer-to-peer agent collaboration, A2UI and AG-UI/MCPUI for declarative and generative interfaces, and ACP for client-side orchestration. We will examine what each protocol solves, where its boundaries are, and — critically — how they complement rather than compete. You will see concrete architectures where MCP and A2A work side by side in the same system, each doing what it does best. Along the way, we will draw parallels from protocol wars past: CORBA vs REST, SOAP vs JSON, WebSockets vs polling. History teaches that winners are rarely the most feature-rich; they are the simplest protocols that reduce the most uncertainty. The same pattern is already playing out in agentic AI.
From Photo to Payout: A Gemini-Native Multi-Agent System for Real-Time Auto Claims
## Project Goal and Business Impact Imagine starting an auto insurance claim simply by photographing the damaged vehicle with your phone. Before the claim is analyzed, an AI agent verifies that the submitted image is clear, properly framed, sufficiently illuminated, and suitable for an accurate assessment. Within minutes, the system can then generate a structured damage evaluation, compare potential repair strategies, and identify relevant repair facilities. The primary objective of this project is to improve the speed, consistency, and transparency of the initial auto insurance claims process. Traditional assessments often depend on manual inspections, fragmented information, and time-consuming repair estimates. These steps can delay claim resolution, increase operational costs, and create inconsistencies between evaluations. This application introduces a Gemini-powered Multi-Agent System that transforms vehicle photographs into a comprehensive preliminary claims assessment. It is designed to support insurers, claims professionals, repair specialists, and customers by providing a rapid, data-driven starting point for claim triage and further investigation. The generated assessment is intended to support the initial evaluation process rather than replace a certified vehicle inspection, professional repair quotation, or final insurance decision. ## The Multi-Agent Architecture At the center of the application is an Orchestrator Agent that manages the complete claims-analysis workflow. It determines the order in which tasks must be performed, sends the appropriate information to each specialist agent, monitors their execution, handles dependencies, and combines their outputs into a coherent final report. The architecture includes several Gemini-powered agents, each responsible for a specific stage of the evaluation. ### Photo Quality Agent The Photo Quality Agent acts as the first validation layer in the workflow. Before any damage assessment begins, it determines whether the uploaded photograph contains enough reliable visual information for further analysis. The agent checks for issues such as excessive blur, poor lighting, reflections, unsuitable camera angles, low resolution, obstructions, excessive distance from the vehicle, and incomplete visibility of the damaged area. When the photograph is unsuitable, the agent explains the problem and provides practical instructions for taking a better image. This prevents low-quality visual evidence from propagating through the remaining agents and producing unreliable estimates. By introducing an explicit quality-control stage, the system improves the reliability of every subsequent decision. ### Vision and Damage Assessment Agent Once the photograph passes the quality check, the Vision Agent uses Gemini’s multimodal capabilities to examine the vehicle and identify visible damage. The agent determines which vehicle components appear to be affected, such as bumpers, body panels, doors, fenders, headlights, mirrors, windows, and wheels. It also classifies the visible damage according to categories such as scratches, dents, cracks, paint damage, deformation, broken components, and collision-related damage. The assessment includes an estimated severity level—minor, moderate, or severe—together with a technical explanation of the visual evidence supporting the classification. Where the available image does not provide enough information to reach a reliable conclusion, the agent records the limitation instead of presenting an unsupported diagnosis. ### OEM Cost Estimation Agent The OEM, or Original Equipment Manufacturer, Cost Estimation Agent evaluates a premium repair scenario. Its analysis prioritizes manufacturer-approved repair procedures, original replacement parts, authorized repair facilities, specialized labor, paint matching, calibration requirements, and other services that may be necessary to restore the vehicle according to manufacturer standards. The agent uses the damage assessment, the affected components, the estimated labor involved, and the available vehicle and market context to generate an indicative cost range. ### Aftermarket Cost Estimation Agent The Aftermarket Cost Estimation Agent evaluates a more cost-conscious repair strategy. It considers certified aftermarket parts, compatible replacement components, independent repair facilities, alternative labor rates, component repair instead of replacement, and other approaches that may reduce the total repair cost while maintaining acceptable quality and safety standards. Running the OEM and Aftermarket agents separately allows the system to present two clearly differentiated repair scenarios rather than producing a single unexplained estimate. ### Shop Finder Agent The Shop Finder Agent identifies repair facilities that may be relevant to the user’s location and the type of damage detected. It can organize available information such as shop names, areas of specialization, contact details, ratings, proximity, and other useful selection criteria. Its search strategy can adapt according to the vehicle components involved and the repair approach being considered. For example, a severe collision assessment may prioritize body shops with structural repair and calibration capabilities, while a minor scratch may require only a paint and cosmetic repair specialist. ## Gemini-Native Technical Architecture The new application is built entirely around Gemini and the Google AI ecosystem. Google AI Studio provides the development environment for designing, testing, and refining the application and its agent workflows. Gemini supplies the multimodal understanding and reasoning capabilities used throughout the system, including image-quality evaluation, vehicle-damage analysis, repair-scenario generation, information synthesis, and final report creation. Rather than relying on different model providers for individual tasks, the application uses a unified Gemini-based architecture. This simplifies communication between agents, reduces integration complexity, and creates a more consistent data flow across the complete pipeline. The application is deployed on Google Cloud Run, providing a managed environment for running the web application and its backend services. This deployment model enables the system to be made available as an online application while supporting scalable, production-oriented execution. ## State Management and Agent Coordination The system maintains a shared claim state containing the information produced during each stage of the workflow. This state may include the uploaded photograph, photo-quality results, detected vehicle components, damage classifications, severity levels, confidence indicators, repair assumptions, cost scenarios, location information, shop results, warnings, and unresolved questions. Each agent receives only the context required for its task and returns a structured result to the Orchestrator Agent. The orchestrator then verifies that the required stages have been completed and combines the individual outputs into a unified claims-assessment report. Confidence indicators help distinguish between strong visual evidence and uncertain conclusions. When an agent has insufficient information, the system can communicate that uncertainty, request another photograph, or recommend professional inspection. ## Agent Execution and Transparency Each agent follows a ReAct-inspired execution pattern based on planning, action, observation, and refinement. The agent first evaluates its assigned objective and the available claim context. It then selects an appropriate action, processes the relevant information, observes the result, and determines whether further analysis is necessary. Instead of exposing private model reasoning, the application can provide a structured activity log containing the task assigned to each agent, the action performed, the evidence considered, the resulting observation, the confidence level, and the final output. This creates an auditable execution trace that allows users to understand how the assessment progressed from image validation to damage analysis, cost estimation, repair-shop identification, and final report generation. ## Generative AI Compared with Traditional Tools Traditional automated vehicle-inspection systems often depend on fixed computer-vision models, predefined rules, static repair databases, or monolithic processing pipelines. These solutions can be effective for narrowly defined tasks, but they may struggle to interpret incomplete evidence, adapt their workflow, explain uncertainty, or combine multiple types of information. The Gemini-powered Multi-Agent System introduces a modular reasoning and coordination layer between the original photograph and the final assessment. Each specialist agent has a clearly defined responsibility, input, output, and confidence level. This makes the workflow easier to inspect, test, extend, and improve than a single large prompt or an opaque end-to-end script. The modular structure also supports the future development of a hybrid architecture. Individual agents could be replaced or supplemented by deterministic computer-vision models, manufacturer repair databases, parts catalogues, pricing APIs, mapping services, fraud-detection systems, or human-review checkpoints without redesigning the entire application. Generative AI therefore operates as the coordination and interpretation layer, while specialized conventional systems can provide additional precision for individual tasks. ## The Future of Insurance Claims This application demonstrates how Gemini-powered agents can collaborate to automate complex, multimodal business workflows. The architecture goes beyond basic vehicle-damage recognition. It validates the quality of the submitted evidence, analyzes visible damage, compares different repair approaches, identifies potentially relevant repair providers, manages uncertainty, and combines the results into a transparent preliminary assessment. The same architecture could eventually support additional agents for vehicle identification, document analysis, policy verification, fraud indicators, repair authorization, parts availability, claims-history analysis, payment recommendations, and mandatory human approval. Built with Gemini in Google AI Studio and deployed on Google Cloud Run, the project provides a scalable blueprint for developing intelligent, modular, and explainable insurance applications. It shows how a coordinated team of specialized AI agents can transform a single vehicle photograph into actionable claims information, reducing initial processing time while keeping uncertainty, traceability, and professional oversight at the center of the workflow. link to the web app: https://multi-agent-car-damage-evaluation.ai.studio