When we talk about artificial intelligence, it is easy to assume that building your own tool means training a model.
In many cases, it does not.
A significant number of useful systems being built today do not start with a model developed from scratch. Instead, they rely on an architecture that combines information sources, programming, automation, rules and structured data and, only where it adds value, general-purpose AI models.
The power does not lie in the model alone. It lies in the system.
Basic architecture
sources → capture → normalisation → rules → scoring → AI → visualisation → decision
From conversation to system
A model can summarise a job offer, analyse a description or classify a piece of text.
But a system becomes genuinely useful when that capability is integrated into a broader workflow. The domain may change — employment, music, scientific research, financial markets, sport or real estate — but the underlying architecture often follows the same principles.
First: acquiring the data
The first layer is not necessarily AI. It is data acquisition.
That data may come through APIs, feeds, open databases or directly from the web.
When no suitable API exists, one option is to use a scraper: a program that can visit a web page, identify specific elements and transform them into structured data.
event = {
"venue": "Example Club",
"date": "2026-10-30",
"artists": ["Artist A", "Artist B"],
"city": "Amsterdam"
}At this point, we are no longer working only with a web page.
We are working with data.
Python as the orchestration layer
In many of these systems, Python acts as the language connecting the different components. It is not “the AI”; it is the layer that brings processes and data together.
- make HTTP requests
- process HTML
- consume APIs
- clean and normalise data
- compare records
- apply rules
- calculate scores
- detect matches
- store results
- feed dashboards
Libraries such as requests, BeautifulSoup and pandas, together with visualisation tools such as Streamlit, make it possible to build functional prototypes with relatively modest infrastructure.
The model may be optional; the architecture is not.
From architecture to real-world cases
The usefulness of this approach becomes clearer when it is applied to concrete problems. The same architecture can be adapted to very different domains by changing the sources, criteria and the way information is represented.
At DeGalaLab, we are experimenting with this idea through projects applied to different contexts, ranging from a music intelligence system to a professional opportunity radar.
The objectives are different, but the logic is similar: collect dispersed information, structure it, apply criteria and turn it into useful signals for decision-making.
MIA: intelligence applied to a music ecosystem
MIA —Music Intelligence Agent— starts from a very specific problem: information relevant to a music project is scattered across clubs, event programmes, artists, promoters, platforms and agencies.
The challenge is not that the information does not exist. The challenge is to find it, structure it and connect it.
venues → scrapers → events → normalisation → scoring → opportunities
Connectors collect events from different sources. Python transforms different structures into a common model. Criteria and scores are then applied to reduce hundreds of events to a much smaller set of signals that deserve attention.
There is no model specifically trained to “understand” the music project.
There is a system designed to represent criteria, observe sources and detect signals.
A professional radar in evolution
The second project starts from a different problem: how to track professional opportunities, detect patterns and compare job offers without relying only on occasional searches or job portals.
For now, the system is built on a relatively simple but useful foundation: an automated spreadsheet that centralises job offers, skills, tools, sectors, fit criteria and scores.
This first version makes it possible to structure the information and establish a comparison logic before adding further automation.
The next step will be to evolve it into a system capable of collecting opportunities automatically through scrapers and other data sources, normalising them and continuously applying classification and scoring criteria.
The project is still evolving, but the direction is clear: moving from a data-assisted radar towards an intelligence agent specialised in Data Science opportunities.
job offers → capture → normalisation → skills → classification → scoring → review
A job radar: similar architecture, different domain
The Job Radar addresses a completely different problem, but it follows a similar logic.
A job offer may contain a professional profile, skills, tools, location, working hours, sector, required experience or working model.
job offers → extraction → skills → classification → scoring → review
This structure can reveal things that a conventional search might miss: a vacancy may not include “Data Steward” in the title but still require metadata, data governance and FAIR Data; another may have a very strong technical fit but poor logistical compatibility.
The system does not make the decision.
It builds an intelligence layer before the decision.
The same pattern in other fields
Scientific research
papers → abstracts → keywords → citations → classification → alerts
Tracking publications, identifying emerging research lines and detecting relevant work.
Sport
matches → statistics → players → metrics → patterns
Financial markets
markets → data → indicators → events → signals → dashboard
Real estate
listings → prices → area → location → features → scoring
The value does not necessarily come from “having AI”. It comes from turning a diffuse problem into an observable structure.
So where does AI fit in?
An AI model can be especially useful for classifying unstructured text, extracting concepts, summarising information, normalising language, detecting semantic relationships or generating explanations of results.
But it is important to distinguish the model from the system.
- An LLM can interpret a description.
- It does not necessarily collect the data.
- It does not necessarily store it.
- It does not necessarily run the process every day.
- It does not necessarily calculate every score.
Rules, scoring and hybrid models
Not everything needs to be solved by a probabilistic model. An explicit rule may be perfectly suited to determining that a 40-hour job does not meet a particular criterion. A numerical score can help rank opportunities. A regular expression can detect a pattern.
An AI model can interpret an ambiguous sentence.
This kind of hybrid architecture is often more transparent, controllable and easier to debug than delegating everything to a single model.
Did the scraper fail? The normalisation? The rule? The scoring? The classification? The model?
This traceability becomes essential when a tool stops being an experiment and starts becoming part of a real working process.
Full autonomy is not required
Talking about AI agents often leads us to imagine fully autonomous systems. But autonomy is not necessarily the goal.
- search
- update
- compare
- detect changes
- prioritise
- alert
And leave the final decision to a person.
In many contexts, the best agent is not the one that decides for us. It is the one that helps us see more clearly.
Building systems, not just prompts
Perhaps this is one of the most interesting shifts in the current stage of AI.
For some time, we have been learning how to ask better questions. Now we are beginning to learn something else: how to build architectures that work continuously on real-world problems.
With data. With code. With automation. With rules. With models where they are useful. And with human judgement at the centre.
You do not need to train your own model to get started.
Sometimes, the most intelligent part is not the model. It is how all the pieces are connected.
