Τα AI agents επαναλαμβάνουν το λάθος των microservices

Τα AI agents επαναλαμβάνουν ένα γνώριμο λάθος από την εποχή των microservices: σπάζουν τις ροές εργασίας σε μικρότερα κομμάτια που φαίνονται να λειτουργούν σωστά, αλλά το συνολικό αποτέλεσμα χειροτερεύει. Το θέμα αναλύει η Shania Rasheed Nalagath, σε κείμενο της 9ης Νοεμβρίου 2026 για το Radar.

Τα microservices άλλαξαν τον τρόπο με τον οποίο χτίζεται το λογισμικό, χωρίζοντας μεγάλες εφαρμογές σε μικρότερες, ανεξάρτητα αναπτύξιμες υπηρεσίες. Αυτό έκανε τα συστήματα πιο εύκολα στην ανάπτυξη και στην κλιμάκωση, αλλά έφερε και νέο πρόβλημα: η συνολική συμπεριφορά έγινε δυσκολότερο να φανεί. Τα AI agents ακολουθούν τώρα παρόμοια πορεία, με μια ροή που κάποτε έμενε σε μία εφαρμογή να μοιράζεται σε πολλούς agents, ο καθένας με μία εργασία. Τα επιμέρους κομμάτια μπορεί να λειτουργούν όπως πρέπει, όμως η συνολική ροή παράγει σταδιακά χειρότερα αποτελέσματα.

Η συντάκτρια περιγράφει ότι το έμαθε αυτό με τον δύσκολο τρόπο. Το όνομά της βρισκόταν στο design doc και ο διαχωρισμός της ροής σε τρεις agents ήταν μια λογική επιλογή. Ωστόσο, εκείνο το απόγευμα δεν είχε απάντηση στο πώς θα εντοπιζόταν το πρόβλημα αν το σύστημα σταματούσε σιωπηλά να λειτουργεί.

Μήνες αργότερα, σε έλεγχο ποιότητας, ένας reviewer παρατήρησε ότι κάτι δεν πήγαινε καλά πριν το εντοπίσει η παρακολούθηση του συστήματος. Η καθυστέρηση έμοιαζε φυσιολογική, τα σφάλματα παρέμεναν σταθερά και κάθε υπηρεσία στην αλυσίδα επέστρεφε αυτό που όφειλε. Το πραγματικό πρόβλημα ήταν μια αργή πτώση στην ποιότητα του αποτελέσματος και χρειάστηκαν περίπου τρεις εβδομάδες για να εντοπιστεί.

Στο παράδειγμα που δίνει, ο πρώτος agent παρέδωσε έγγραφα στον επόμενο για σύνοψη. Ο summarizer αφαίρεσε ένα πεδίο που έκρινε χαμηλής σημασίας και ένας downstream agent προχώρησε σε βέβαιη σύσταση χωρίς αυτό το στοιχείο. Κάθε agent έκανε αυτό για το οποίο είχε σχεδιαστεί, αλλά το αποτέλεσμα παρέμενε λάθος.

Η κεντρική επισήμανση είναι ότι η αποσύνθεση των monoliths ήταν σωστή επιλογή για τις περισσότερες ομάδες, αλλά τα δύσκολα σημεία δεν εξαφανίστηκαν. Μεταφέρθηκαν στα κενά ανάμεσα στις υπηρεσίες, εκεί όπου όσοι είχαν ευθύνη για το συνολικό προϊόν δεν μπορούσαν πλέον να τα δουν. Το κόστος φάνηκε γύρω στο 2019, όχι ως συμβάν, αλλά ως καθυστέρηση στην παράδοση. Οι ομάδες διαχειρίζονταν εκατοντάδες υπηρεσίες με περιορισμένο tracing και χωρίς versioning συμβολαίων, και το βασικό σύμπτωμα ήταν η πιο αργή ανάπτυξη νέων λειτουργιών.

Για τα agents, το μοτίβο αυτό εμφανίζεται ταχύτερα, επειδή η δημιουργία ενός agent απαιτεί ελάχιστο χρόνο και κόστος. Έτσι, οι ομάδες προϊόντος μπορούν να φτιάχνουν agents χωρίς να ρωτούν άλλους και χωρίς να υπάρχει σαφής καταγραφή του τι είναι και τι κάνουν.

Το πρόβλημα δεν είναι μόνο προσωπική εμπειρία. Οι Cemri και οι συν-συγγραφείς τους ανέλυσαν περισσότερα από 1.600 execution traces σε επτά δημοφιλή multi-agent frameworks και κατέληξαν σε ταξινομία 14 επαναλαμβανόμενων μορφών αστοχίας, στο MAST, στο NeurIPS 2025. Όπως σημειώνεται, τα περισσότερα προβλήματα συνδέονται με τον τρόπο που ορίζεται το σύστημα και με τον συντονισμό των agents, όχι με τα ίδια τα μοντέλα.

Η καταγραφή του αποθέματος των agents δεν είναι τόσο απλή όσο ακούγεται. Στα microservices, η διάσπαση φαινόταν έστω και στα Kubernetes manifests. Οι agents όμως μπορεί να δημιουργούνται μέσα σε εργαλεία προϊόντος και ροών εργασίας ή σε αυτοματισμούς που στήνει κάποιος το Σαββατοκύριακο. Συχνά, κανείς δεν μαθαίνει τι υπάρχει, μέχρι να ρωτήσει ένας reviewer συμμόρφωσης ποιο αυτοματοποιημένο σύστημα άγγιξε μια συγκεκριμένη απόφαση.

Η έλλειψη ορατότητας κόστισε στην ίδια τρεις εβδομάδες. Όταν ένας agent καλεί έναν άλλον, που με τη σειρά του καλεί ένα retrieval layer και μετά έναν ακόμη agent, κάθε βήμα χρειάζεται trace context που να επιβιώνει σε όλη τη διαδρομή. Τα περισσότερα συστήματα κρατούν logs για prompts και completions ανά κλήση και σταματούν εκεί. Έτσι βλέπεις κάθε στάδιο ξεχωριστά, αλλά όχι την αλυσίδα που απέτυχε.

Η πιο ανησυχητική μορφή αστοχίας, σύμφωνα με το κείμενο, είναι η συσσώρευση εμπιστοσύνης. Τα κατανεμημένα συστήματα αποτυγχάνουν θορυβωδώς, κάτι που λειτουργεί υπέρ τους, καθώς ένα service που επιστρέφει 500 δίνει σαφές σήμα στον καλούντα να σταματήσει. Τα agents, αντίθετα, αποτυγχάνουν σιωπηλά και με άνεση στη γλώσσα τους. Αν ένας upstream agent παράγει μια σύνοψη που φαίνεται εύλογη αλλά είναι λάθος, ο downstream agent δεν παίρνει κάποιο σήμα κινδύνου και συνεχίζει να συλλογίζεται πάνω σε αυτό. Όταν το αποτέλεσμα φτάσει στον χρήστη, μεταφέρει επίπεδο βεβαιότητας που δεν στηρίζεται στα αρχικά στοιχεία.

Παρόμοια μετατόπιση συνέβη και στα API contracts. Όταν κάποιος άλλαζε το response format χωρίς versioning, η ομάδα έστηνε μηχανισμούς εντοπισμού στο build time. Στα agent contracts, όμως, η μεταβολή έρχεται όταν αλλάζει ένα system prompt. Δεν υπάρχει schema diff ούτε type check. Τίποτα δεν σπάει αμέσως, μέχρι να αρχίσει ένας downstream agent να λαμβάνει διαφορετική έξοδο και να προσαρμόζεται χωρίς να το αντιληφθεί κανείς.

Από τα microservices, το κείμενο κρατά πρώτα από όλα την ανάγκη για registry. Ένα service catalog με owner και scope ήταν το ελάχιστο που χρειαζόταν τότε και για τους agents χρειάζεται κάτι αντίστοιχο, μαζί με σαφή λίστα για το τι επιτρέπεται να καλεί ο καθένας.

Το tracing επίσης περνά σχεδόν αυτούσιο. Τα correlation IDs υπάρχουν γι’ αυτόν ακριβώς τον λόγο και τα OpenTelemetry GenAI semantic conventions δίνουν το λεξιλόγιο. Έτσι, μια εκτέλεση agent δεν καταλήγει σε άσχετες γραμμές log αλλά σε ένα span tree. Αν είχαν καταγράφει αυτά τα spans, το span του summarizer και το span του recommender θα φαίνονταν δίπλα δίπλα στην ίδια trace, και το χαμένο πεδίο θα εντοπιζόταν ως διαφορά και όχι μετά από τρεις εβδομάδες αναζήτησης.

Η συντάκτρια λέει επίσης ότι θα ήθελε ένα τεστ που να εντοπίζει την παράλειψη πριν φτάσει μια αλλαγή prompt στην παραγωγή. Σε αυτό θα εφάρμοζε τη λογική του contract testing από τα microservices: ορίζεις τι χρειάζεται ο downstream agent και ελέγχεις αν μια upstream αλλαγή το διατηρεί. Στο συγκεκριμένο workflow, η αξιολόγηση θα έπρεπε να ελέγχει αν το output του summarizer κρατά τις πληροφορίες που χρειάζεται ο recommender. Τα prompts θα έπρεπε να εκδόσεις και οι αλλαγές να περνούν από αυτές τις αξιολογήσεις πριν τη δημοσίευση. Υπάρχει, όπως αναφέρεται, και πρώιμη ένδειξη ότι αυτό αποδίδει: το SEMAP, μια μέθοδος σε επίπεδο πρωτοκόλλου που εφαρμόζει behavioral contract modeling και lifecycle verification στην υποδομή A2A της Google, ανέφερε έως και περίπου 70% λιγότερες αστοχίες σε function-level coding tasks σε σύγκριση με το MAST.

Σημαντικό σημείο παραμένει το trust boundary. Το 2019 έγινε σαφές ότι μια υπηρεσία δεν γίνεται αξιόπιστη μόνο και μόνο επειδή βρίσκεται εντός του perimeter, κάτι για το οποίο αναπτύχθηκαν σε μεγάλο βαθμό και τα service meshes. Στην εκδοχή των agents, το αντίστοιχο είναι ότι ένας agent δεν αποκτά ευρεία πρόσβαση σε εργαλεία μόνο και μόνο επειδή κατασκευάστηκε εσωτερικά. Το τι επιτρέπεται να κάνει πρέπει να ορίζεται σε policy layer που το μοντέλο δεν μπορεί να παρακάμψει, όχι σε system prompt που απλώς ζητάει ευγενικά.

Το κόστος είναι το σημείο όπου η αναλογία microservices και agents σταματά να είναι πλήρης. Ένα microservice που μπαίνει σε retry loop κοστίζει CPU και ένα alert στις 3 το πρωί. Ένας agent σε loop κοστίζει πραγματικά χρήματα σε κάθε γύρο και δεν δίνει σαφές σήμα μέχρι να φανεί στον προϋπολογισμό. Το βάρος πέφτει έτσι στον product owner, επειδή το πρόβλημα εμφανίζεται ως unit economics και όχι ως outage.

Πριν εγκρίνει έναν τέτοιο διαχωρισμό, η συντάκτρια λέει ότι θέτει τέσσερα ερωτήματα. Αν μπορείς να παρακολουθήσεις μία αίτηση μέχρι τέλους και να ανασυνθέσεις τι αποφάσισε κάθε agent και γιατί. Αν όχι, τότε χτίζεται κάτι που δεν θα μπορεί να γίνει debug. Τι συμβαίνει όταν ένας upstream agent κάνει λάθος, και όχι αν μπορεί να το κάνει. Αν η ειλικρινής απάντηση είναι ότι ο επόμενος agent συνεχίζει κανονικά, τότε δεν έχει σχεδιαστεί failure mode. Έχει σχεδιαστεί η αποτυχία και έχει αφεθεί να τρέχει.

Ρωτά επίσης ποιος έχει την ευθύνη για τον συγκεκριμένο agent και πού επιβάλλεται η πρόσβαση στα εργαλεία του. Ένα system prompt δεν αρκεί ως μηχανισμός επιβολής. Και τέλος, τι θα κοστίζει το σύστημα με δεκαπλάσιο όγκο και τι το σταματά όταν ο αριθμός ξεφύγει. Όπως λέει, αυτό είναι το ερώτημα που κανείς δεν προσφέρεται να θέσει πρώτος.

Η εμπειρία από τα microservices δείχνει, καταλήγει το κείμενο, ότι οι ομάδες που διαχειρίστηκαν καλύτερα τη διάσπαση ενσωμάτωσαν από νωρίς tracing και contract testing. Έτσι κατάλαβαν πώς αλληλεπιδρούν οι υπηρεσίες και έλεγχαν αν οι αλλαγές διατηρούσαν τη συμπεριφορά που περίμεναν. Στα agents, αυτό μπορεί να είναι υπόθεση ενός ή δύο sprints σήμερα, αλλά γίνεται πολύ πιο σύνθετο όταν το σύστημα φτάσει να έχει 40 agents και κάποιος χρειαστεί να εντοπίσει ποιος άγγιξε τα δεδομένα ενός πελάτη.

Πηγή: oreilly.com.