Agent Mesh: γιατί τα retries των microservices δεν αρκούν για τους AI agents

Γιατί τα service-mesh assumptions σπάνε στους agents

Τα συνηθισμένα reliability εργαλεία βασίζονται σε τρεις πρακτικές παραδοχές: ένα request είναι idempotent ή μπορεί να αποκτήσει idempotency key, η μεγάλη καθυστέρηση είναι χρήσιμο σήμα αποτυχίας και ένα request που απορρίπτεται δεν έχει ουσιαστικό κόστος. Στους AI agents καμία από αυτές δεν είναι ασφαλής. Ο agent συνθέτει τις πράξεις του κατά το inference, άρα ο developer δεν γνωρίζει εκ των προτέρων όλα τα effectful operations ώστε να τους δώσει κλειδιά. Μπορεί να κάνει γρήγορα αλλά άκαρπα βήματα, επομένως το latency δεν αποκαλύπτει πάντα failure. Και τα tokens ξοδεύονται ακόμη κι όταν το αποτέλεσμα πεταχτεί.

Η διαφοροποίηση έχει πρακτική σημασία για κάθε εταιρεία που οργανώνει αυτοματισμούς επιχειρήσεων με AI πάνω από CRM, e-commerce, content operations ή development workflows. Ένα retry δεν είναι απλώς δεύτερη ανάγνωση. Μπορεί να ξαναστείλει email, να ξαναγράψει record, να ξανατρέξει πληρωμένη inference ή να ζητήσει από άλλον agent να «διορθώσει» κώδικα που ήταν ήδη σωστός. Το operational unit πρέπει λοιπόν να περιλαμβάνει identity, budget, effects, evidence και ownership της πλήρους delegation.

Η μελέτη και τα όρια των ισχυρισμών της

Τα incidents καταγράφονταν καθώς διαγιγνώσκονταν και συνδέονταν με durable records, event streams και workspaces. Όπου το paper χαρακτηρίζει μια αιτία ως επιβεβαιωμένη, η ομάδα είχε επαναφέρει το fix και είχε αναπαράγει την αποτυχία. Κάποια guards αφαιρέθηκαν όταν κανένα mutation δεν μπορούσε να αποδείξει ότι ενεργοποιούνται. Καταγράφηκαν επίσης διαγνώσεις που αποσύρθηκαν όταν τα δεδομένα τις διέψευσαν, στοιχείο που ενισχύει τη διαφάνεια της διαδικασίας.

Παράλληλα, το corpus αφορά ένα μόνο σύστημα, διαγνώστηκε από την ομάδα που το κατασκεύασε και υπερεκπροσωπεί τα περιστατικά που ήταν αρκετά ενδιαφέροντα ώστε να καταγραφούν. Γι’ αυτό οι συγγραφείς δεν δίνουν distribution των 147 incidents ούτε inferential statistics. Τα μεγέθη που αναφέρονται είναι περιγραφικά και ανήκουν στο συγκεκριμένο περιβάλλον. Η μελέτη μπορεί να χαρακτηρίσει failure classes, όχι να αποδείξει πόσο αποτελεσματικό είναι το Agent Mesh σε σύγκριση με baseline.

F1 και F2: η απουσία error δεν σημαίνει πρόοδο

Στο πιο καθαρό περιστατικό, ένας independent-verifier agent έκανε την ίδια tool call 54 φορές σε 11 λεπτά. Κάθε κλήση ήταν επιτυχής, άρα ένας error-rate breaker ήταν δομικά τυφλός. Το σύστημα χρειαζόταν σήμα σύγκλισης: αλλάζει το αποτέλεσμα, προστίθεται grounding, μεταβάλλεται το workspace ή επαναλαμβάνεται το ίδιο fingerprint χωρίς νέο evidence;

Όμως ακόμη και ένας progress breaker μπορεί να είναι λάθος. Σε άλλο περιστατικό, το fingerprint βασιζόταν στο όνομα του failing check, μια τιμή σταθερή από τον σχεδιασμό της recovery strategy. Ο detector ενεργοποιούνταν υποχρεωτικά στον τρίτο γύρο, παρότι τα tests είχαν κινηθεί από crash σε πέντε failures και μετά σε δύο. Ένα run έπεσε από έξι ολοκληρωμένα components σε τρία. Το μάθημα είναι αυστηρό: πριν αυτοματοποιηθεί μια απόφαση stop, πρέπει να αποδειχθεί ότι το σήμα μπορεί πραγματικά να αλλάξει και ότι διακρίνει τις καταστάσεις που υποτίθεται ότι μετρά.

F3: τα effects επιβιώνουν περισσότερο από τη delegation

Η πλατφόρμα χρησιμοποιούσε copy-on-write workspace ώστε μια αποτυχημένη προσπάθεια να μην αφήνει διπλές αλλαγές στα αρχεία. Η προστασία λειτουργούσε εντός αυτού του boundary. Ένα event log, όμως, είχε τοποθετηθεί εκτός workspace και εκτός κάθε cleanup. Συγκέντρωσε 21 events μέσα σε έξι invocations σε τέσσερις ώρες. Η εφαρμογή δημοσίευε σωστά τρία events ανά invocation, αλλά το test περίμενε ένα καθαρό ledger και έβλεπε leftovers από προηγούμενες προσπάθειες. Έτσι ένα idempotent component έγινε πρακτικά αδύνατο να περάσει.

Οι συγγραφείς εντόπισαν και άλλες effect classes εκτός transactional containment: package resolution και installation, per-service database writes, post-write hooks και model-provider calls. Η τελευταία κατηγορία είναι ιδιαίτερα ακριβή, επειδή retry στον provider καίει tokens χωρίς ενιαίο ledger του ήδη εκτελεσμένου έργου. Για μια επιχείρηση αυτό μεταφράζεται σε απαίτηση για effect inventory πέρα από τη βασική database transaction: notifications, webhooks, uploads, external APIs, paid inference και background jobs χρειάζονται δικό τους observability και deduplication boundary.

F4: όταν το λάθος failure routing καταστρέφει σωστή δουλειά

Σε ένα multi-agent σύστημα, η λανθασμένη απόδοση αιτίας δεν προκαλεί απλώς ακόμη ένα retry. Αναθέτει σε έναν σωστό agent να αλλάξει κάτι που δεν ευθύνεται. Η αρχική λογική του συστήματος χρησιμοποιούσε scenario coverage ως proxy για causality: αν πολλά components κάλυπταν το ίδιο scenario, μπορούσαν να ξυπνήσουν όλα για repair. Σε ένα περιστατικό, fault δύο components ενεργοποίησε πέντε και οι τρεις bystanders παλινδρόμησαν κώδικα που λειτουργούσε.

Το κόστος μπορεί να είναι και διαγνωστικό. Ένα repair window κατανάλωσε 943 tool turns μέσα σε 71 λεπτά, από τα οποία τα 451 ήταν reads ή searches, επειδή ο brief έδειχνε μόνο αρχεία που δεν μπορούσαν να τροποποιηθούν. Η πλατφόρμα είχε υπολογίσει causality αλλά δεν είχε μεταφέρει αρκετό evidence στον agent. Για operations teams, η αντιστοίχιση «ποιος βλέπει το failure» δεν πρέπει να συγχέεται με το «ποιος κατέχει την πρώτη transition που δεν αποδείχθηκε». Η διάκριση αυτή είναι κεντρική και στο runtime governance των AI agents, όπου η λογοδοσία πρέπει να ακολουθεί την πραγματική ενέργεια και όχι μόνο το εξωτερικό control plane.

F5: το enforcement layer μπορεί να γίνει η κύρια πηγή outage

Η πιο μεταφέρσιμη παρατήρηση του paper είναι ότι τα guardrails δεν αποτυγχάνουν μόνο όταν αφήνουν κάτι επικίνδυνο να περάσει. Αποτυγχάνουν επίσης όταν μπλοκάρουν σωστή δουλειά. Καταγράφηκαν 12 τέτοια incidents. Το ακριβότερο κόστισε 107 agent turns και μηδέν accepted writes, επειδή ένα repair clamp απαγόρευε ακόμη και την ανάγνωση του αρχείου που περιείχε το πραγματικό defect.

Άλλα gates απέρριπταν τεκμηριωμένο framework idiom, θεωρούσαν λάθος ένα generated dispatch seam ή επαλήθευαν citation μόνο απέναντι στο αρχείο που είχε κατονομάσει το μοντέλο. Ακόμη πιο επικίνδυνη μπορεί να είναι μια λανθασμένα permissive απόφαση: ένα appeal δέχθηκε σωστή διάγνωση απέναντι στο λάθος αρχείο και έκλεισε όλες τις υπόλοιπες repair routes. Η επιχειρηματική συνέπεια είναι ότι κάθε policy engine χρειάζεται tests όχι μόνο για απαγορευμένες πράξεις, αλλά και corpus αποδεδειγμένα σωστών πράξεων που πρέπει πάντα να γίνονται δεκτές.

F6 και F7: ολόκληρο το σύστημα και το ασταθές oracle

Ορισμένες αστοχίες εμφανίζονται μόνο όταν εκκινήσει η πλήρης εφαρμογή. Στη μελέτη, real servers και browser-like probes αποκάλυψαν design system χωρίς build pipeline και routes που υπήρχαν στο navigation αλλά δεν είχαν δημιουργηθεί. Όμως το νέο preview gate δημιούργησε αμέσως δικό του false failure: αναγνώριζε μόνο bearer tokens, ενώ τα services χρησιμοποιούσαν gateway-injected identity headers. Το app απαντούσε σωστά 401 και παρ’ όλα αυτά το repair loop επαναλήφθηκε έξι φορές για περίπου μία ώρα.

Επιπλέον, ο agent ξανασυνθέτει ενέργειες σε κάθε inference και μπορεί να έχει γράψει ο ίδιος το test suite που λειτουργεί ως oracle. Ίδια workspace κατάσταση δεν εγγυάται ίδιο verdict. Η πλατφόρμα κλειδώνει κάθε observation σε digest του workspace, του environment και του check contract. Αν δύο observations με το ίδιο τριπλό κλειδί διαφωνούν, το evidence μπαίνει σε quarantine αντί να προκαλέσει τυφλό retry. Αυτό είναι ουσιαστικό για marketing automations, customer-service agents και data pipelines: αν το evaluator είναι flaky, κάθε downstream metric παρουσιάζει θόρυβο ως βεβαιότητα. Η ίδια ανάγκη για παρατηρήσιμη κατάσταση εμφανίζεται στην πρόβλεψη επόμενου βήματος και αποτυχίας των AI agents.

Identity adequacy: όταν το identifier δεν διακρίνει αυτό που πρέπει

Πέντε φαινομενικά άσχετα subsystems απέτυχαν με το ίδιο μοτίβο. Το circuit breaker χρησιμοποιούσε check name αντί για μεταβαλλόμενο evidence. Ένα commit id περιλάμβανε transaction id, άρα ίδιο content από δύο transactions φαινόταν διαφορετικό και δεν μπορούσε να γίνει deduplicate. Ένας topology node ένωνε δύο διαφορετικές βάσεις επειδή είχαν το ίδιο logical name. Το scenario coverage αντιμετωπιζόταν ως causal identity. Και ο work planner μετρούσε coupling συνολικά αντί ανά component.

Οι συγγραφείς ονομάζουν το κριτήριο identity adequacy: η ταυτότητα πρέπει να διακρίνει δύο καταστάσεις που έχουν σημασία για την απόφαση. Δεν αρκεί να είναι μοναδική τεχνικά. Ένα UUID transaction είναι μοναδικό αλλά αποτυγχάνει ως content identity. Ένα scenario label είναι σταθερό αλλά δεν αποδεικνύει ownership. Πριν χρησιμοποιηθεί ένα identifier για deduplication, routing ή stopping, η ομάδα πρέπει να γράψει ρητά ποια ισοδυναμία εκπροσωπεί.

Evidence adequacy: όχι κάθε μετρήσιμο σήμα δικαιούται να αποφασίζει

Το dual του identity adequacy είναι το evidence adequacy. Ένα σήμα πρέπει να μπορεί να κινηθεί, να αποδίδεται στο αντικείμενο που μετρά και να είναι deterministic υπό ίδιες συνθήκες. Ένα fingerprint πάνω σε constant vocabulary δεν είναι συντηρητικό· είναι εγγυημένο false trip. Ένας router με αμφίσημο evidence πρέπει να απέχει αντί να αποκλείει με βεβαιότητα τον πραγματικό owner.

Το ίδιο ισχύει για τα automated quality checks. Ένα mutation kill μετρά μόνο αν μπορεί να αποδοθεί στον κανόνα που ελέγχεται. Ένα αποτέλεσμα αξιολόγησης δικαιούται να ενεργοποιήσει penalty ή retry μόνο αν αναπαράγεται στο ίδιο workspace και environment. Για business owners, αυτό είναι πιο γενικό από το software engineering: KPI, lead scores και moderation flags μπορούν να είναι διαθέσιμα σε dashboard χωρίς να είναι επαρκή για αυτόματη απόφαση.

Τα επτά primitives του Agent Mesh

Το πρώτο primitive είναι progress-based breaking με υποχρέωση signal adequacy. Το δεύτερο είναι effect contract: compiled declaration και μηχανική παρατήρηση των effects στα tool, sandbox και commit boundaries. Το τρίτο είναι effect ledger με content-addressed fingerprints για canonical tool calls, argument digests και external mutation IDs. Οι συγγραφείς τονίζουν ότι το ledger είναι specified αλλά δεν έχει υλοποιηθεί, άρα η αποτελεσματικότητά του δεν έχει αποδειχθεί.

Το τέταρτο primitive είναι budget attenuation σε πολλαπλά scopes, run, component, failure fingerprint, strategy και session, με degradation αντί για άμεσο kill. Το πέμπτο είναι failure routing μέσω typed topology και checkpoint ladder, με abstention όταν το evidence είναι αμφίσημο. Το έκτο είναι enforcement-layer exoneration: boot-time corpus σωστών artifacts, yielding όταν ένα clamp απορρίπτει επανειλημμένα owned file και διαγραφή guards που δεν μπορούν να αποδειχθούν ενεργά. Το έβδομο είναι quarantine για nondeterministic observations.

Τι έχει υλοποιηθεί και τι παραμένει υπόσχεση

Η πλατφόρμα έχει running μηχανισμούς για effect declaration, feasibility gate, progress breaker, budget lattice, failure routing, enforcement exoneration, nondeterminism quarantine και running-system verification. Μετά τις αλλαγές, το blast radius στο motivating routing case μειώθηκε από πέντε components σε δύο, ενώ clamp yielding ενεργοποιήθηκε πέντε φορές σε ένα run. Ένα πλήρως traced run διήρκεσε τέσσερις ώρες και 55 λεπτά, περιλάμβανε πέντε components και δέκα scheduler cycles, και τελικά έφτασε 21 στα 21 required checks.

Δεν έχουν χτιστεί όμως το content-addressed effect ledger, τα distinct refusal verdicts, το per-tenant partitioning, το persisted effect trace store και το per-delegation token/cost ledger. Δεν υπάρχει ακόμη sidecar boundary για να μετρηθεί p50/p99 overhead. Το paper διαχωρίζει καθαρά running, specified και designed components. Αυτή η διάκριση είναι σημαντική για procurement και strategy: μια ενδιαφέρουσα αρχιτεκτονική δεν πρέπει να παρουσιάζεται ως validated product outcome πριν υπάρξει το κατάλληλο experiment. Παρόμοια, το semantic rollback στους AI agents χρειάζεται δική του μέτρηση και όχι απλή αναλογία με rollback βάσης δεδομένων.

Το controlled experiment που χρειάζεται στη συνέχεια

Οι συγγραφείς προτείνουν δύο arms πάνω στο ίδιο workload και fault schedule. Το baseline θα εφαρμόζει naive service-mesh policies με απενεργοποιημένο transactional containment, ενώ το mesh arm θα ενεργοποιεί τα επτά primitives και distinct refusal verdicts. Οι co-primary metrics είναι duplicate-effect rate στα boundaries που δεν καλύπτει το containment και work destroyed per fault.

Υπάρχει μάλιστα kill criterion: αν κανένα από τα δύο primary metrics δεν είναι ουσιαστικό υπό ρεαλιστικό fault injection, η βασική υπόθεση θεωρείται αδύναμη και η δουλειά σταματά. Αυτή η στάση είναι χρήσιμη και για επιχειρηματικά AI pilots. Πριν επενδυθεί μεγάλος χρόνος σε governance layer, πρέπει να οριστεί ποια ζημιά μειώνει, ποιο baseline συγκρίνεται και ποιο αποτέλεσμα θα ακυρώσει την επένδυση.

Πρακτικό πλαίσιο για ομάδες που βάζουν agents σε παραγωγή

Το Agent Mesh δεν είναι έτοιμη συνταγή για κάθε οργανισμό. Προσφέρει όμως έναν συγκεκριμένο έλεγχο πριν ένας agent αποκτήσει πρόσβαση σε παραγωγικά συστήματα.

Τα verdicts πρέπει να ξεχωρίζουν duplicate suppression, stall, exhausted budget και policy rejection, επειδή απαιτούν διαφορετική απόκριση. Η ομάδα χρειάζεται επίσης τρόπο να θέτει αμφίσημο evidence σε quarantine αντί να το μετατρέπει σε βέβαιη απόφαση.

Τι σημαίνει για e-commerce, marketing και content operations

Σε e-commerce, ένας agent μπορεί να αλλάζει catalog fields, να ενεργοποιεί campaigns ή να χειρίζεται tickets. Αν ένα workflow ξανατρέξει, η ζημιά δεν είναι μόνο τεχνική: διπλό μήνυμα, λάθος έκπτωση, ασυνεπές inventory ή brand copy που τροποποιείται από λάθος sub-agent. Το effect ledger και το σωστό ownership γίνονται στοιχεία customer experience, όχι απλώς infrastructure.

Στο marketing, ένα «successful» tool call δεν λέει αν η καμπάνια πλησίασε τον στόχο. Χρειάζονται progress signals δεμένα με το παραδοτέο και όχι με την κινητικότητα του agent. Στο content pipeline, η επανάληψη μπορεί να είναι ασφαλής για το local draft αλλά όχι για uploads, CMS drafts ή email reports. Η ίδια αρχή βελτιώνει και τη μέτρηση του ROI των AI coding assistants: μετράμε αποδεκτό έργο και όχι απλώς activity. Η βασική αρχή του paper είναι συνεπής: η αξιοπιστία πρέπει να ακολουθεί τη delegation σε όλα τα boundaries όπου αφήνει αποτέλεσμα.