Η ιδέα ενός «team από AI agents» ακούγεται ελκυστική: ένας agent σχεδιάζει, άλλοι ερευνούν και ένας τελευταίος ελέγχει. Στην πράξη, κάθε επιπλέον agent προσθέτει context, latency, κόστος και νέα σημεία αποτυχίας. Ένα multi-agent system αξίζει όταν η εργασία μπορεί πραγματικά να διασπαστεί σε ανεξάρτητα ή εξειδικευμένα μέρη και όταν ο συντονισμός δίνει μετρήσιμο όφελος.
Για πολλές εφαρμογές, ένας agent με καλά εργαλεία και σαφές workflow είναι απλούστερος και καλύτερος. Το ζητούμενο δεν είναι ο αριθμός των agents, αλλά η κατανομή ευθύνης.
Το orchestrator-worker pattern
Ένα συνηθισμένο μοντέλο έχει lead agent ή orchestrator που αναλύει το αίτημα, δημιουργεί subtasks και τα αναθέτει σε workers. Οι subagents εκτελούν περιορισμένη εργασία και επιστρέφουν structured findings. Ο orchestrator συνθέτει, εντοπίζει κενά και αποφασίζει αν χρειάζεται νέο βήμα.
Η Anthropic περιγράφει αυτό το pattern στο multi-agent research system της: lead agent συντονίζει εξειδικευμένους subagents που εξερευνούν διαφορετικές πλευρές παράλληλα και επιστρέφουν ευρήματα για σύνθεση. Στην ίδια τεκμηρίωση αναφέρονται failure modes όπως υπερβολικός αριθμός subagents, διπλή έρευνα και ατελείωτη αναζήτηση.
Πότε το parallel work έχει νόημα
Η παραλληλία βοηθά όταν τα subtasks είναι αρκετά ανεξάρτητα. Παραδείγματα:
- έρευνα διαφορετικών αγορών ή πηγών
- έλεγχος πολλών ανεξάρτητων εγγράφων
- ανάλυση security, UX και data model από ξεχωριστές οπτικές
- συλλογή δεδομένων από διαφορετικά εργαλεία
- παραγωγή candidates και ανεξάρτητη αξιολόγηση
Δεν βοηθά όταν κάθε βήμα εξαρτάται από το αμέσως προηγούμενο. Αν ο δεύτερος agent χρειάζεται το αποτέλεσμα του πρώτου, η «παραλληλία» γίνεται σειριακή ροή με επιπλέον handoff. Σε αυτή την περίπτωση ένα explicit workflow είναι συχνά καθαρότερο.
Το delegation χρειάζεται πλήρες task contract
Η οδηγία «ερεύνησε τον ανταγωνισμό» είναι πολύ ασαφής. Κάθε subtask πρέπει να περιλαμβάνει:
- συγκεκριμένο objective
- scope και τι δεν πρέπει να εξεταστεί
- διαθέσιμα εργαλεία και permissions
- απαιτούμενες πηγές ή χρονικό εύρος
- output schema
- success και stop criteria
- budget χρόνου, tokens ή tool calls
Χωρίς αυτά, δύο subagents μπορεί να κάνουν την ίδια δουλειά ή να επιστρέψουν αποτελέσματα που δεν μπορούν να συγκριθούν. Ο orchestrator πρέπει να αναθέτει συμπληρωματικές εργασίες και να κρατά χάρτη κάλυψης.
Structured outputs αντί για ελεύθερες εκθέσεις
Ο subagent δεν χρειάζεται να επιστρέφει όλο το reasoning ή τεράστιο transcript. Ένα μικρό structured payload μπορεί να περιέχει findings, evidence references, confidence, gaps και recommended next step.
{
"topic": "technical_seo",
"findings": [],
"sources": [],
"confidence": "medium",
"openQuestions": []
}
Το schema επικυρώνεται πριν ενσωματωθεί στο main state. Αν λείπει υποχρεωτικό evidence, το αποτέλεσμα απορρίπτεται ή ζητείται διόρθωση. Έτσι ο orchestrator δεν χρειάζεται να ερμηνεύσει διαφορετικό format από κάθε worker.
Context isolation και ελάχιστα permissions
Ένα πλεονέκτημα των subagents είναι η απομόνωση context. Ο worker βλέπει μόνο ό,τι χρειάζεται για το task του και δεν γεμίζει το main context με κάθε raw tool result. Αυτό βελτιώνει εστίαση και μειώνει έκθεση δεδομένων.
Τα permissions δεν πρέπει να κληρονομούνται όλα μηχανικά. Research subagent μπορεί να έχει read-only web access, ενώ execution agent μπορεί να χρησιμοποιεί συγκεκριμένο CRM tool. Ευαίσθητες ενέργειες παραμένουν πίσω από server-side authorization και approval. Ο orchestrator δεν αποκτά έμμεσα περισσότερη εξουσία επειδή μπορεί να δημιουργήσει worker.
Budgets και stop conditions
Χωρίς όρια, ένα σύστημα μπορεί να δημιουργεί νέους agents επειδή κάθε αποτέλεσμα αποκαλύπτει άλλη ερώτηση. Ορίζονται maximum subagents, συνολικά tool calls, token budget και deadline. Ο orchestrator μαθαίνει πότε η κάλυψη είναι αρκετή και πότε πρέπει να επιστρέψει αβεβαιότητα.
Το budget μπορεί να είναι δυναμικό: απλό αίτημα εκτελείται από έναν agent, ενώ σύνθετο research task επιτρέπεται να διασπαστεί. Η πολυπλοκότητα ταξινομείται πριν το fan-out.
Αποτυχίες και partial results
Αν ένας από πέντε workers αποτύχει, δεν είναι πάντα σωστό να ακυρωθεί όλη η εργασία. Ο orchestrator μπορεί να συνεχίσει με partial results, να επαναλάβει μόνο το συγκεκριμένο subtask ή να δηλώσει το κενό.
Κάθε task έχει stable ID και idempotent execution. Τα retries δεν πρέπει να δημιουργούν διπλά writes. Για parallel branches χρειάζεται join policy: περιμένουμε όλους, quorum ή deadline με όσα αποτελέσματα υπάρχουν.
Evaluation πέρα από την τελική απάντηση
Ένα καλό τελικό κείμενο μπορεί να κρύβει σπατάλη ή επικίνδυνη διαδικασία. Τα evals εξετάζουν:
- αν η διάσπαση κάλυψε τα σωστά subtasks
- duplication μεταξύ workers
- ποιότητα και προέλευση evidence
- αριθμό agents και κόστος
- latency μέχρι το πρώτο και τελικό αποτέλεσμα
- permission violations ή unnecessary tool calls
- αν η σύνθεση διατήρησε τις διαφωνίες και την αβεβαιότητα
Συγκρίνεται πάντα με single-agent baseline. Αν το multi-agent workflow δεν βελτιώνει task success ή χρόνο αρκετά ώστε να δικαιολογεί την πολυπλοκότητα, δεν χρειάζεται.
Πότε να προτιμήσετε deterministic workflow
Για διαδικασίες με γνωστά βήματα, όπως validation αίτησης, έγκριση και ενημέρωση ERP, ένα state machine είναι συχνά καταλληλότερο. Το model μπορεί να χρησιμοποιείται σε επιλεγμένα βήματα, αλλά η διαδρομή δεν χρειάζεται να αποφασίζεται από agent κάθε φορά.
Multi-agent orchestration ταιριάζει περισσότερο σε ανοιχτές εργασίες όπου η στρατηγική προσαρμόζεται στα ευρήματα. Οι συναλλαγές, τα permissions και τα business rules παραμένουν deterministic.
Πώς το υλοποιεί η Ai Foundry
Στην Ai Foundry ξεκινάμε με το απλούστερο architecture που πετυχαίνει τον στόχο. Δημιουργούμε single-agent και deterministic baselines πριν προσθέσουμε subagents. Όταν η εργασία ωφελείται από παραλληλία ή εξειδίκευση, σχεδιάζουμε orchestrator με σαφή task contracts, περιορισμένα tools, structured outputs και budgets.
Καταγράφουμε κάθε delegation, tool call και κόστος, διατηρούμε durable state και ορίζουμε recovery για partial failures. Δημιουργούμε evals που συγκρίνουν ποιότητα, latency και κόστος με απλούστερη λύση. Έτσι η Ai Foundry χρησιμοποιεί multi-agent συστήματα όπου δίνουν πραγματικό επιχειρηματικό όφελος, όχι ως διακοσμητικό επίπεδο πολυπλοκότητας.
Συμπέρασμα
Τα multi-agent systems είναι χρήσιμα για σύνθετες, διασπάσιμες εργασίες με parallel exploration. Χρειάζονται όμως αυστηρό delegation, contracts, permissions και budgets. Όταν η ροή είναι γνωστή ή σειριακή, ένας agent μέσα σε καλά σχεδιασμένο workflow είναι συχνά η καλύτερη επιλογή.