Most agent demos work because the data is clean and the question is the one the demo was built for. Real systems get messy schemas, contradictory terminology and users who ask what they actually want to know. That gap is what I work on.
Multi-step pipelines that plan, call tools, check their own output and fail visibly rather than quietly.
The APIs, data layers and infrastructure underneath — built to be run in production, not demoed once.
The part non-technical people touch, where an answer has to be readable and trustworthy to be used.
I take projects end to end: working out what the problem actually is, designing the architecture, writing the code, and putting it in front of the people who will use it.
I've done this alone as the only engineer on a product, and as the person coordinating scope and delivery with clients. Both sides matter — most systems fail on the misunderstood requirement, not the missing library.
Two things I insist on. Show the reasoning: a number an AI produced with no visible path behind it doesn't get trusted, and it shouldn't be. And learn the user's language: every organisation uses the same words differently, so the system has to pick that up instead of assuming a standard meaning.
I'm currently AI Engineer and Project Manager at Tecnovation in Pordenone, where I build Pandora AI. Degree in IoT, big data and machine learning. I work in English, Italian, Ukrainian and Russian.
A multi-agent platform that turns questions from non-technical staff into verified queries across operational databases, then returns tables, charts and the query it ran. Handles ambiguous terminology and keeps per-user context about what words mean to that person. Built and deployed as the sole engineer.
Python · FastAPI · PostgreSQL · MariaDB · Redis · ChromaDB · React · Docker
A Pandora module: automated intake for incoming supplier documents — extract the lines, match them against open records, write them in, and flag what doesn't reconcile instead of guessing. Replaces manual re-typing and the errors that surface weeks later.
Python · document extraction · ERP integration
Two products for the agricultural sector: a chat assistant that answers technical product questions for buyers, and a planning tool that models the economics of a crop season. Different audiences, same underlying problem — putting expert knowledge where the decision is made.
Python · LLM agents · React
Open-source terminal tooling for monitoring distributed task queues — built because the existing options showed everything except what I needed during an incident.
Python · Textual · Celery
Machine learning models that predict how traffic redistributes across European airspace after a closure, trained on historical flight data. BSc thesis, University of Udine, 2026.
Python · scikit-learn · time series
Two ways to extend an agent that look interchangeable in the docs and behave nothing alike in production.
Why the biggest model is usually the wrong tool for a narrow job, and what that means for the cost of running agents.
Open to consulting and contract work on AI systems, agents and the backends behind them.