Multi-Agent Orchestration: πέντε μοτίβα και πότε κερδίζει το ένα

Μια πορτογαλική εταιρεία γράφει για το τιμολόγιο FT-2026-0918. Το email λέει ότι ο ΦΠΑ φαίνεται λάθος, και επισυνάπτει το τιμολόγιο: καθαρή αξία EUR 248,00, ΦΠΑ χρεωμένος με 21 %, EUR 52,08, σύνολο EUR 300,08.

Τα γεγονότα που χρειάζονται για να απαντηθεί το ζήτημα βρίσκονται σε τρία μέρη, και μόνο ένα από αυτά είναι στο email:

Βάλτε τα τρία μαζί και το τιμολόγιο είναι λάθος: εφαρμόζεται reverse charge, ο ΦΠΑ θα έπρεπε να είναι μηδενικός, οφείλεται πιστωτικό σημείωμα για EUR 52,08. Κοιτάξτε μόνο το τιμολόγιο και είναι αριθμητικά άψογο — 248,00 συν 52,08 είναι 300,08 — και αυτό θα πείτε.

Το email όντως αναφέρει «είμαστε πορτογαλική εταιρεία». Αυτό είναι ισχυρισμός, όχι εγγραφή, και κανένα σύστημα τιμολόγησης δεν εκδίδει πιστωτικό σημείωμα πάνω σε έναν ισχυρισμό. Η παγίδα δεν είναι τρικ: είναι η συνηθισμένη μορφή της επιχειρησιακής εργασίας, όπου η απόφαση χρειάζεται ένα γεγονός που κανείς δεν σκέφτηκε να φέρει.

Όλα τα παραπάνω τρέχουν απέναντι σε scripted provider στο στιλ του Κεφαλαίου 23, με ακριβώς έναν κανόνα:

Μια απάντηση μπορεί να χρησιμοποιήσει μόνο γεγονός που βρίσκεται στο prompt της.

Το «μοντέλο» ζητά κάθε εργαλείο που έχει, μία φορά, με σειρά καταλόγου, και μετά εφαρμόζει έναν σταθερό κανόνα στο κείμενο που μπορεί να δει. Τίποτα δεν είναι scripted ανά διάταξη, άρα οι διαφορές στον αρχικό πίνακα δεν είναι ισχυρισμοί για την ευφυΐα του μοντέλου: είναι δρομολόγηση πληροφορίας, μετρημένη. Ένα πραγματικό μοντέλο προσθέτει τις δικές του αστοχίες από πάνω· δεν τις αφαιρεί.

Τα πέντε ονόματα παρακάτω είναι της Anthropic, από το Building effective agents, όπου και παγιώθηκε αυτό το λεξιλόγιο.¹ Καμία από τις πέντε ιδέες δεν είναι νέα, και το να ξέρετε ποιο σπίτι ονόμασε τι — και ποια ιδέα είναι παλαιότερη — είναι η μισή αξία του να τις γνωρίζετε.

/* 1. Prompt chaining: a fixed pipeline. The control flow is yours. */
export async function chain(steps: Step[], first: string) {
  let carry = first, all = first;
  for (const s of steps) {
    const r = await step(s.role, s.system, s.accumulate ? all : carry);   
    carry = r.text;
    all = `${all}\n${r.text}`;
  }
  return carry;
}

/* 2. Routing: one cheap call picks the branch. The fallback is not a model. */
export async function route<T>(input: string, classify: Classifier,
                               routes: Record<string, Branch<T>>, fallback: Branch<T>) {
  let label: string | undefined;
  try { label = await classify(input); } catch { label = undefined; }
  return ((label && routes[label]) || fallback)(input);                    
}

/* 3. Parallelisation. The pattern IS this line. */
export const parallel = <T>(workers: Branch<T>[], input: string) =>
  Promise.all(workers.map((w) => w(input)));                              

/* 4. Orchestrator-workers: an agent behind a tool. Chapter 18's interface, unchanged. */
export function agentTool(o: WorkerSpec): Tool {
  return {
    name: o.name, description: o.description, readOnly: true,
    parameters: { type: "object", properties: { question: { type: "string" } } },
    async run(args: { question: string }) {
      const child = newRun(o.system, args.question);          // its own window
      await runTracked(child, o.tools, o.usage);              // its own limits
      const conclusion = child.output ?? "no result";
      if (!o.carryFindings) return conclusion;                             
      return `${conclusion}\nFINDINGS ${evidence(child)}`;                 
    },
  };
}

/* 5. Evaluator-optimiser: make, judge, remake. Rounds are calls. */
export async function refine(make: Make, judge: Judge, maxRounds: number) {
  let draft = "", feedback: string | undefined;
  for (let r = 1; r <= maxRounds; r++) {
    draft = (await make(feedback)).text;
    const j = await judge(draft);
    if (j.ok) return { draft, rounds: r };
    feedback = j.note;
  }
  return { draft, rounds: maxRounds };
}

Αυτό είναι όλο το toolkit: πέντε συναρτήσεις, κανένα framework, και η παράλληλη είναι μία μόνο γραμμή — που είναι και ο λόγος να τη γράψουμε αντί να τη σχεδιάσουμε. Τώρα καθεμία με τη σειρά της, με την καταγωγή της, την τιμή της και την περίπτωση όπου κάνει λάθος.

Το prompt chaining «διασπά μια εργασία σε μια ακολουθία βημάτων, όπου κάθε κλήση LLM επεξεργάζεται το output της προηγούμενης».¹ Η ιδέα προηγείται των γλωσσικών μοντέλων: είναι ένα pipeline, με το παζάρι του pipeline — σαφήνεια με αντάλλαγμα control flow σταθερό πριν φτάσουν τα δεδομένα.

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

--- relay: each step sees only the previous step's output
extract: FIELDS invoice_id=FT-2026-0918 net=248.00 vat_rate_applied=21 vat_amount=52.08 ...
check:   ARITHMETIC ok 248.00+52.08=300.08
decide:  VERDICT=unknown reason=no_invoice_in_context
draft:   "we are looking into invoice FT-2026-0918 and will come back to you."

--- accumulating: each step sees the email and everything produced so far
extract: FIELDS invoice_id=FT-2026-0918 net=248.00 vat_rate_applied=21 ...
check:   ARITHMETIC ok 248.00+52.08=300.08
decide:  VERDICT=invoice_correct reason=net_248.00_plus_21pct_vat_52.08_equals_300.08
draft:   "we have checked FT-2026-0918 and it is correct... Nothing is owed back."

Η αλυσίδα relay κόστισε $0.001940 και έχασε τα πεδία του τιμολογίου μεταξύ του δεύτερου και του τρίτου βήματος, επειδή στο τρίτο βήμα δόθηκε μια πρόταση για αριθμητική και τίποτε άλλο. Παρήγαγε ένα μήνυμα αναμονής: άχρηστο, και εμφανώς άχρηστο.

Η συσσωρευτική αλυσίδα — η γραμμή στον αρχικό πίνακα — κόστισε $0.003780, δηλαδή 95 % περισσότερο για τέσσερις ίδιες κλήσεις, επειδή κάθε βήμα τώρα κουβαλά όλα όσα προηγήθηκαν. Παρήγαγε το επικίνδυνο output. Ρευστό, επικαλούμενο την αριθμητική του, σωστό σε κάθε αριθμό που αναφέρει, και λέγοντας σε έναν πελάτη ότι δεν οφείλεται τίποτα ενώ οφείλονται EUR 52,08.

Η διαφορά ανάμεσα στα δύο είναι ένα ternary. Μια αλυσίδα που κουβαλά λιγότερα παράγει απαντήσεις που είναι προφανώς ελλιπείς· μια αλυσίδα που κουβαλά τα πάντα παράγει απαντήσεις που είναι με αυτοπεποίθηση λάθος — και μόνο το δεύτερο είδος αποστέλλεται.

Ούτε το ένα ούτε το άλλο είναι η πραγματική αποτυχία. Η πραγματική αποτυχία είναι ότι το pipeline αποφάσισε, πριν διαβάσει οτιδήποτε, ότι αυτή η εργασία είναι τέσσερα βήματα πάνω στα περιεχόμενα ενός email. Πουθενά σε αυτή τη δομή δεν υπάρχει χώρος για να πει «η χώρα εγγραφής δεν είναι σε αυτό το email· πήγαινε και φέρ’ την». Το chaining είναι σωστό όταν η διάσπαση είναι γνωστή εκ των προτέρων και σταθερή. Εδώ ήταν εικασία, και η εικασία στάλθηκε.

Το routing «ταξινομεί ένα input και το κατευθύνει σε μια εξειδικευμένη επόμενη εργασία».¹ Το όνομα είναι νέο· ο μηχανισμός είναι ο dispatcher, παλαιότερος από σχεδόν όλα τα υπόλοιπα σε αυτό το βιβλίο. Το νέο είναι ότι ο classifier μπορεί να είναι μοντέλο — και αυτό είναι που τον κάνει να αποτυγχάνει με τρόπους που ένα switch δεν έκανε ποτέ.

const answer = await route(email,
  (q) => classifyWithSmallModel(q),          // cheap model, one call
  { billing: billingAgent, tax: taxAgent, dunning: dunningAgent },
  taxAgent,                                  // deterministic, chosen in advance
);

Δύο πράγματα για αυτό το τελευταίο όρισμα. Δεν είναι error handling· είναι το μοτίβο. Ένας model-based router έχει failure mode που δεν έχει ένας dispatcher: μπορεί να επιστρέψει label που δεν υπάρχει, να λήξει χρονικά ή — το ακριβό — να επιστρέψει ένα πειστικό λάθος label χωρίς σήμα ότι είναι λάθος. Και τα τρία πρέπει να καταλήγουν κάπου, και αυτό το κάπου δεν μπορεί να είναι άλλη κλήση μοντέλου, επειδή βρίσκεστε ήδη στον κλάδο όπου οι κλήσεις μοντέλου απέτυχαν.

Το δεύτερο είναι ότι το prompt του ίδιου του router δεν είναι δωρεάν. Για να επιλέξει μοντέλο, ένας router χρειάζεται έναν κατάλογο μοντέλων από τον οποίο να επιλέξει, και κάθε εγγραφή του είναι input που πληρώνει ο router πριν διαβάσει την ερώτηση του χρήστη. Με την τιμή input με την οποία κοστολογεί αυτό το μάθημα, ένας κατάλογος περίπου 3.800 tokens κοστίζει ήδη όσο ολόκληρο το run του agent με τις πέντε κλήσεις στον αρχικό πίνακα. Στην πράξη η κλήση routing τρέχει σε φθηνό μοντέλο, και αυτός είναι όλος ο λόγος που το routing αποσβένει το κόστος του· αλλά αξίζει να κάνετε την αριθμητική προς αυτή την κατεύθυνση αντί να το υποθέτετε. Το routing είναι λάθος ακριβώς όταν η δρομολογημένη εργασία είναι φθηνότερη από την απόφαση routing.

Η Anthropic το χωρίζει στα δύο: sectioning — «διάσπαση μιας εργασίας σε ανεξάρτητες υποεργασίες που τρέχουν παράλληλα» — και voting — «εκτέλεση της ίδιας εργασίας πολλές φορές για λήψη διαφορετικών outputs».¹ Μοιράζονται ένα διάγραμμα και σχεδόν τίποτε άλλο.

Το sectioning είναι η φθηνή νίκη, και είναι η γραμμή από το patterns.ts: τρεις ειδικοί — billing, tax, policy — ο καθένας με το δικό του παράθυρο και εργαλεία, πάνω στο ίδιο email, μία κλήση σύνθεσης στο τέλος. Ίδια εργασία, διατεταγμένη με δύο τρόπους:

Ίδιο token προς token, 1,8 φορές ταχύτερο. Γι’ αυτό το μοτίβο κερδίζει δικό του όνομα: είναι το μόνο από τα πέντε που βελτιώνει κάτι χωρίς να κοστίζει τίποτα. Η παγίδα είναι ότι οι ενότητες πρέπει να είναι πραγματικά ανεξάρτητες — δώστε στην ενότητα B ένα γεγονός που παράγει η ενότητα A και το Promise.all τις τρέχει και τις δύο απέναντι σε state που δεν υπάρχει ακόμα. Το loop for έκρυβε αυτό το bug· η one-liner το εκθέτει.

Το voting είναι άλλο ζώο που φορά την ίδια εικόνα. Το να τρέχετε την ίδια ερώτηση k φορές και να παίρνετε την πλειοψηφία είναι self-consistency, δημοσιευμένο από τους Wang et al. τον Μάρτιο του 2022 ως decoding strategy, σχεδόν τρία χρόνια πριν το αποκαλέσει κανείς μοτίβο orchestration. Η περίληψή του είναι ακριβής για τον μηχανισμό — «πρώτα δειγματοληπτεί ένα ποικίλο σύνολο διαδρομών συλλογισμού αντί να παίρνει μόνο την greedy, και έπειτα επιλέγει την πιο συνεπή απάντηση περιθωριοποιώντας τις δειγματοληπτημένες διαδρομές συλλογισμού» — και για το κέρδος: +17,9 μονάδες στο GSM8K.²

Ακολουθούν δύο πράγματα που κρύβει η εικόνα. Πρώτον, το voting απαιτεί το sampling του Κεφαλαίου 17: σε temperature μηδέν, όλα τα k samples είναι το ίδιο sample, και η πλειοψηφία είναι μία απάντηση πληρωμένη k φορές. Δεύτερον, λειτουργεί μόνο εκεί όπου η πλειοψηφία έχει νόημα — στην παραπάνω απάντηση τιμολογίου δεν υπάρχει τίποτα να μετρηθεί, επειδή πέντε drafts είναι πέντε διαφορετικές προτάσεις. Το voting είναι για εργασίες με σύντομη, συγκρίσιμη απάντηση, που είναι ακριβώς τα benchmarks του Wang και σχεδόν τίποτα από όσα κάνει ένας customer-facing agent.

Μετρημένο εδώ σε 20 προβλήματα λέξεων τριών βημάτων, των οποίων οι απαντήσεις υπολογίζονται αντί να κρίνονται, με το τοπικό μοντέλο του Κεφαλαίου 23 να συλλογίζεται βήμα προς βήμα:

Πέντε φορές οι κλήσεις, πέντε φορές τα tokens, ακριβώς πέντε φορές ο λογαριασμός, και ούτε μία επιπλέον σωστή απάντηση. Το voting είναι στοίχημα, όχι βελτίωση, και αυτό το run το έχασε.

Δύο επιφυλάξεις, πριν το παραθέσει κανείς ως διάψευση του Wang. Είκοσι δοκιμές δεν μπορούν να ξεχωρίσουν το 45 % από το 60 % — το διάστημα έχει το πλάτος του ισχυρισμού, δηλαδή η πειθαρχία του Κεφαλαίου 4 στραμμένη στο δικό μου αποτέλεσμα. Και τα δημοσιευμένα κέρδη προέρχονται από μοντέλα τάξεις μεγέθους μεγαλύτερα, όπου οι διαφορετικές διαδρομές συλλογισμού πάνω στις οποίες περιθωριοποιεί το voting είναι όντως διαφορετικές. Αυτό που μεταφέρεται δεν είναι ο αριθμός: είναι ότι ο πολλαπλασιαστής είναι ακριβής και γνωστός εκ των προτέρων, ενώ το κέρδος δεν είναι κανένα από τα δύο.

Στο workflow orchestrator-workers «ένα κεντρικό LLM διασπά δυναμικά εργασίες, τις αναθέτει σε worker LLMs και συνθέτει τα αποτελέσματά τους», και η διαφορά από το sectioning είναι ότι «οι υποεργασίες δεν είναι προκαθορισμένες, αλλά καθορίζονται από τον orchestrator».¹ Η καταγωγή εδώ δεν είναι καθόλου από γλωσσικά μοντέλα: αυτό είναι master-worker, και η έκδοση όπου οι workers γράφουν ευρήματα σε έναν κοινό χώρο που διαβάζει ένας controller είναι η blackboard architecture, από την έρευνα κατανόησης ομιλίας της δεκαετίας του 1970. Το νέο το 2026 είναι ότι ο controller είναι μοντέλο και άρα η διάσπαση μπορεί να αποφασίζεται ανά input — που είναι η ευελιξία, και το κόστος, σε μία πρόταση.

Κόστισε 12 κλήσεις μοντέλου έναντι των 5 του single agent, και έφτασε στην ίδια ετυμηγορία. Μετά έκανε κάτι που αξίζει να κοιτάξουμε προσεκτικά:

orchestrator final: VERDICT=credit_note_due amount=52.08 source=worker_unverified
                  | PO_MISMATCH=yes source=worker_unverified
single agent:       VERDICT=credit_note_due amount=52.08 reason=reverse_charge_should_have_applied
                  | PO_MISMATCH=yes invoice_says=PO-4417 order_says=PO-4471

Και τα δύο είναι σωστά. Μόνο το ένα ξέρει γιατί. Ο tax worker είχε το τιμολόγιο, την παραγγελία και τον φορολογικό πίνακα στο δικό του παράθυρο, έφτασε στο συμπέρασμα, και επίσης παρατήρησε — κανείς δεν το ζήτησε — ότι ο αριθμός purchase order στο τιμολόγιο δεν ταιριάζει με της παραγγελίας. Μετά επέστρεψε μια σύνοψη. Ο orchestrator μπορεί να επαναλάβει και τις δύο δηλώσεις και να ελέγξει καμία, επειδή τα αποδεικτικά στοιχεία έμειναν σε ένα παράθυρο που δεν είδε ποτέ. Αυτή είναι η τελική ερώτηση του Κεφαλαίου 24, απαντημένη: ο parent μπορεί να δει ό,τι επέλεξε το child να γράψει.

Η λύση είναι ένα flag, και έχει τιμή:

Δώδεκα τοις εκατό περισσότερα input tokens, 8,3 % περισσότερα χρήματα, και η φράση source=worker_unverified εξαφανίζεται από την απάντηση. Αυτό είναι το trade σε κάθε multi-agent system και σχεδόν ποτέ δεν δηλώνεται: το καθαρό παράθυρο του child αξίζει να υπάρχει, η δυνατότητα του parent να το auditάρει αξίζει να πληρωθεί, και δεν μπορείτε να έχετε και τα δύο δωρεάν.

Άρα πότε είναι λάθος το orchestrator-workers; Εδώ, σε αυτή την εργασία. Αγόρασε μια σωστή απάντηση στην οποία έφτασε επίσης ένας agent με τα ίδια τέσσερα εργαλεία, για 1,66 φορές το κόστος και 2,3 φορές το wall clock, και έκανε αυτή την απάντηση πιο δύσκολη να υπερασπιστεί. Η ίδια η καθοδήγηση της Anthropic λέει το ίδιο πριν ξεκινήσουν τα μοτίβα: βρείτε «την απλούστερη δυνατή λύση, και αυξήστε την πολυπλοκότητα μόνο όταν χρειάζεται», επειδή «τα agentic systems συχνά ανταλλάσσουν latency και κόστος με καλύτερη απόδοση εργασίας».¹ Οι παραπάνω πίνακες είναι εκείνη η πρόταση με αριθμούς από κάτω.

Μία κλήση παράγει, άλλη αξιολογεί, και το loop επαναλαμβάνεται μέχρι να περάσει η αξιολόγηση.¹ Οι δημοσιευμένοι πρόγονοι είναι το Self-Refine — το ίδιο μοντέλο ως «generator, refiner, and feedback provider», αναφέροντας περίπου 20 μονάδες απόλυτης βελτίωσης κατά μέσο όρο σε επτά εργασίες³ — και το Reflexion, που αποθηκεύει την κριτική σε episodic buffer μεταξύ προσπαθειών και αναφέρει 91 % pass@1 στο HumanEval όπου το baseline έφτασε 80 %.⁴

Το cost model είναι το απλούστερο από τα πέντε: δύο κλήσεις ανά γύρο, και ο αριθμός γύρων δεν είναι δικός σας. Τρεις γύροι refinement σε εργασία που πήρε μία κλήση είναι έξι κλήσεις, άρα το κατώφλι του μοτίβου είναι 6× και η οροφή του είναι όποιο cap ορίσετε — πράγμα που κάνει το budget exit του Κεφαλαίου 23 υποχρεωτικό και όχι απλώς τακτοποιημένο.

Η οροφή είναι πιο λεπτή, και είναι μετρήσιμη. Στα ίδια 20 προβλήματα το τοπικό μοντέλο απάντησε σωστά σε 9. Μετά του δείξαμε καθεμία από αυτές τις απαντήσεις και το ρωτήσαμε αν ήταν σωστή — χωρίς να του πούμε ότι η απάντηση ήταν δική του, πράγμα που αφαιρεί το flattery confound και αφήνει το capability one:

Αυτός είναι καλύτερος κριτής απ’ ό,τι υπονοεί ο τίτλος της ενότητας, και το να το λέμε είναι ο σκοπός της μέτρησης αντί του ισχυρισμού: δεν μπλόκαρε τίποτα σωστό και έπιασε 8 από τα 11 λάθη. Ως φίλτρο, αξίζει τις κλήσεις του.

Ως κανόνας διακοπής, που είναι αυτό για το οποίο τον χρησιμοποιεί στην πραγματικότητα ένα evaluator-optimiser loop, αυτές οι τρεις εγκρίσεις είναι όλη η ιστορία: τερματίζουν το loop με λάθος απάντηση στα χέρια, και κανένας αριθμός επιπλέον γύρων δεν τις φτάνει ποτέ. Ένα refinement loop δεν μπορεί να γίνει πιο σωστό από τον κριτή του. Η αγορά περισσότερων γύρων αγοράζει προσπάθειες πάνω στα λάθη που μπορεί να δει ο κριτής, σε πλήρη τιμή, και απολύτως τίποτα απέναντι σε εκείνα που δεν μπορεί.

Εξ ου και ο κανόνας: ένας evaluator κερδίζει τις κλήσεις του μόνο όταν έχει κάτι που δεν έχει ο generator. Έναν compiler, ένα test suite, έναν schema validator, διαφορετικό μοντέλο, άνθρωπο. Τα ίδια τα αποτελέσματα του Self-Refine μετρώνται απέναντι σε ανθρώπινη προτίμηση και task metrics, ποτέ απέναντι στη γνώμη του μοντέλου για τον εαυτό του. Αν το μόνο πλεονέκτημα του evaluator σας είναι διαφορετικό prompt, πληρώνετε διπλά για συμφωνία. Το Κεφάλαιο 29 χτίζει την έκδοση με πραγματικό πλεονέκτημα: ένα golden set με τις απαντήσεις γραμμένες εκ των προτέρων.

Τα πέντε παραπάνω είναι σχήματα για τον δικό σας κώδικα. Κάτω από αυτά κάθεται μια δεύτερη οικογένεια που συχνά απαριθμείται μαζί τους και δεν θα έπρεπε: ReAct, Reflexion, plan-and-execute και tree of thoughts είναι reasoning loops, και το κόστος τους είναι σε requests.

Το Κεφάλαιο 12 αφορούσε το reasoning μέσα στο μοντέλο, για το οποίο πληρώνετε σε output tokens σε μία κλήση. Αυτό είναι το άλλο είδος. Η διαφορά μετρά όταν έρχεται ο λογαριασμός: ένα μεγαλύτερο chain of thought κάνει μία κλήση ακριβότερη, και ένα reasoning loop κάνει μία εργασία πολλές κλήσεις, καθεμία από τις οποίες ξαναστέλνει όλα όσα προηγήθηκαν — το τετραγωνικό που μέτρησε το Κεφάλαιο 23 στον πίνακα runaway.

Το paper του tree-of-thoughts δημοσιεύει τον δικό του πίνακα κόστους, κάτι πιο σπάνιο απ’ όσο θα έπρεπε. Στο Game of 24 με GPT-4: το input/output prompting best-of-100 έλυσε 33 % με $0.13 ανά περίπτωση, το chain of thought best-of-100 έλυσε 49 % με $0.47, και το tree of thoughts έλυσε 74 % με $0.74, με τους συγγραφείς να σημειώνουν ότι «θα μπορούσε να απαιτεί 5-100 φορές περισσότερα generated tokens από το CoT».⁷

Σχεδόν έξι φορές η τιμή της φθηνής μεθόδου για λίγο περισσότερο από διπλάσιο ποσοστό επιτυχίας. Το αν αυτό είναι ευκαιρία εξαρτάται από το τι σας κοστίζει μια αποτυχημένη περίπτωση — η ερώτηση που πρέπει να κάνετε πριν υιοθετήσετε οποιοδήποτε από αυτά τα τέσσερα.

Αυτό το μάθημα δεν τα υλοποιεί ξανά. Και τα τέσσερα έχουν reference implementations από τους ίδιους τους συγγραφείς τους, σε Python, και η αξία τους είναι ότι είναι η πηγή αντί για μετάφραση: ysymyth/ReAct, noahshinn/reflexion, princeton-nlp/tree-of-thought-llm και AGI-Edgerunners/Plan-and-Solve-Prompting. Διαβάστε τα prompts σε αυτά τα repositories· τα prompts είναι τα papers.

Τώρα το κανονικό multi-agent, όπου ζει το μεγαλύτερο μέρος της σύγχυσης. Υπάρχουν δύο τρόποι για έναν agent να εμπλέξει άλλον, δεν είναι παραλλαγές, και η διαφορά είναι ποιος έχει τον έλεγχο μετά.

Agent ως εργαλείο. Ο parent τον καλεί, παίρνει απάντηση και συνεχίζει. Είναι η διεπαφή εργαλείου του Κεφαλαίου 18 με έναν ολόκληρο agent πίσω της, και ο parent δεν χάνει ποτέ τον έλεγχο. Αυτό κάνει ο orchestrator παραπάνω.

Handoff. Ο parent μεταφέρει τη συζήτηση και δεν την παίρνει πίσω. Ο οδηγός της OpenAI είναι η καθαρότερη δημοσιευμένη διατύπωση: τα handoffs είναι «μια μονόδρομη μεταφορά που επιτρέπει σε έναν agent να αναθέσει σε άλλον agent... Αν ένας agent καλέσει μια handoff function, ξεκινάμε αμέσως την εκτέλεση στον νέο agent στον οποίο έγινε το handoff, μεταφέροντας επίσης το τελευταίο conversation state.»⁸

Προειδοποίηση λεξιλογίου, επειδή αυτό μπερδεύει διαρκώς τον κόσμο: το «handoff» είναι λέξη ενός SDK, όχι πρότυπο. Είναι ορολογία από το OpenAI Agents SDK και εκείνον τον οδηγό, που ονομάζει επίσης τις δύο διατάξεις «manager» και «decentralized» και σημειώνει ότι στο manager pattern «οι ακμές αντιπροσωπεύουν tool calls, ενώ στο decentralized pattern οι ακμές αντιπροσωπεύουν handoffs».⁸ Υπάρχει όντως ανοικτό πρότυπο σε αυτόν τον χώρο — το A2A, στην έκδοση 1.0.0, υπό copyright του Linux Foundation, με versioned release history και τεκμηριωμένη λίστα breaking changes, του οποίου η δηλωμένη αρχή είναι opaque execution: οι agents «συνεργάζονται με βάση δηλωμένες δυνατότητες και ανταλλασσόμενη πληροφορία, χωρίς να χρειάζεται να μοιράζονται τις εσωτερικές σκέψεις, τα plans ή τις υλοποιήσεις εργαλείων τους».⁹ Αυτό δεν είναι handoff, και η σύγκριση ανήκει στο Κεφάλαιο 26. Αυτό που έχει σημασία εδώ είναι ότι η μία από τις δύο λέξεις είναι API μιας βιβλιοθήκης και η άλλη είναι specification με governance.

Η διάκριση είναι data structure, όχι διάγραμμα:

export type EdgeKind = "tool" | "handoff";
export interface AgentEdge { from: string; to: string; kind: EdgeKind }
export interface AgentGraph { root: string; agents: Record<string, AgentSpec>; edges: AgentEdge[] }

/** One agent may not be both a tool of X and a handoff target of X. */
export function conflicts(g: AgentGraph): AgentEdge[] {
  const seen = new Map<string, EdgeKind>();
  const bad: AgentEdge[] = [];
  for (const e of g.edges) {
    const key = `${e.from}->${e.to}`;
    const other = seen.get(key);
    if (other && other !== e.kind) bad.push(e);                            
    else seen.set(key, e.kind);
  }
  return bad;
}

/** Every agent reachable from the root, and at what depth. */
export function reachable(g: AgentGraph): Map<string, number> {
  const depth = new Map([[g.root, 0]]);
  const queue = [g.root];
  while (queue.length) {
    const id = queue.shift()!;
    for (const e of g.edges.filter((x) => x.from === id)) {
      if (depth.has(e.to)) continue;
      depth.set(e.to, depth.get(id)! + 1);
      queue.push(e.to);
    }
  }
  return depth;
}

Είκοσι γραμμές, δύο bugs που αλλιώς θα βρίσκατε στην παραγωγή. Το reachable βρίσκει τον agent στον οποίο κανείς δεν μπορεί να φτάσει — configured, πληρωμένος, ποτέ καλούμενος. Το conflicts αρνείται την ακμή που είναι και τα δύο είδη ταυτόχρονα, κάτι που ακούγεται σχολαστικό μέχρι να το διαβάσετε δυνατά: ο parent και κρατά τον έλεγχο και τον παραδίδει. Τρέξτε το σε ένα σύστημα πέντε agents με ένα orphan και μία διπλή ακμή:

reachable: lead@0 billing@1 tax@1 dunning@1
orphans:   ghost
conflicts: lead->tax

Τώρα η μέτρηση για την οποία υπάρχει αυτή η ενότητα, και η μόνη στο κεφάλαιο που έγινε απέναντι σε πραγματικό μοντέλο αντί για scripted.

Ένας πελάτης δηλώνει έναν περιορισμό στο πρώτο του μήνυμα — ο λογαριασμός μας είναι εγγεγραμμένος στην Πορτογαλία, όχι στην Ισπανία· ό,τι σχετίζεται με φόρους πρέπει να χρησιμοποιεί την Πορτογαλία — συνομιλεί για κάτι άλλο, μετά κάνει μια ερώτηση που πρέπει να απαντήσει το billing. Η υπόθεση μεταφέρεται. Είκοσι τέσσερις δοκιμές, διαφορετική χώρα και εταιρεία κάθε φορά, τέσσερα payloads μεταφοράς, και ο receiving agent ερωτάται μετά μία ερώτηση: σε ποια χώρα είναι εγγεγραμμένος ο λογαριασμός αυτού του πελάτη;

Η τρίτη γραμμή είναι control και συμπεριφέρεται σαν τέτοιο: το γεγονός δεν είναι εκεί, άρα δεν μπορεί να ανακληθεί. Οι άλλες τρεις είναι το εύρημα.

Το πλήρες transcript είναι 173 tokens και λειτουργεί στο 83 % των περιπτώσεων, με τις τέσσερις αποτυχίες του να είναι θέμα του Κεφαλαίου 24 και όχι αυτού. Το typed record είναι 69 tokens — επτά περισσότερα από τη σύνοψη — και λειτουργεί κάθε φορά, επειδή ο περιορισμός κάθεται σε named field αντί σε πρόταση.

Και η σύνοψη είναι η γραμμή που πρέπει να κοιτάξετε. Απέτυχε 24 φορές στις 24, και ο λόγος δεν είναι ότι ο αναγνώστης δεν την πρόσεξε. Ο περιορισμός εμφανίστηκε μόνο σε 1 από τις 24 συνόψεις συνολικά. Ο receiving agent δεν ήταν απρόσεκτος· του παραδόθηκε κείμενο που δεν περιείχε την απάντηση. Μια σύνοψη είναι συμπίεση που δεν γράψατε εσείς, παραγόμενη από μοντέλο του οποίου το παράθυρο δεν μπορείτε να δείτε, βελτιστοποιημένη ώστε να διαβάζεται σαν σύνοψη — και το «ο πελάτης λέει ότι τα records μας έχουν λάθος χώρα» είναι ακριβώς το είδος πρότασης που ένας summariser πετά ως διαδικαστικό θόρυβο.

Ένα έντιμο όριο σε αυτόν τον αριθμό: ο summariser είναι μοντέλο μισού δισεκατομμυρίου παραμέτρων και ένα μεγαλύτερο θα κρατούσε περισσότερα. Αυτό που δεν βελτιώνεται με το μέγεθος είναι το σχήμα του κινδύνου — ο sending agent αποφασίζει, ανά handoff, ανά διατύπωση, μη παρατηρήσιμα, ποια γεγονότα επιβιώνουν. Το typed record δεν εξαρτάται καθόλου από αυτή την κρίση, και γι’ αυτό κερδίζει by construction αντί by intelligence. Ό,τι πρέπει να επιβιώσει από μια μεταφορά πρέπει να είναι πεδίο, όχι πρόταση.

Το ίδιο reasoning ισχύει και προς την άλλη κατεύθυνση, στην τοπολογία agent-as-tool, και ο προηγούμενος πίνακας το έχει ήδη κοστολογήσει: αυτό που επιστρέφει από έναν worker είναι επίσης σύνοψη, και το να πληρώσετε 8,3 % περισσότερο για να λάβετε τα evidence μαζί της είναι η ίδια λύση ιδωμένη από την πλευρά του parent.

Τρία τελικά γεγονότα, όλα από τους παραπάνω πίνακες.

Ένα multi-agent system πολλαπλασιάζει τις κλήσεις, και οι κλήσεις είναι τετραγωνικές στο context. Ο orchestrator έκανε 12 κλήσεις μοντέλου εκεί όπου ένας agent έκανε 5, και καθεμία κουβαλά το δικό της αυξανόμενο transcript — 3.628 input tokens έναντι 2.697, ένα χάσμα που πλαταίνει με το μήκος της εργασίας.

Κάθε όριο είναι κανάλι με απώλειες. Δύο agents σημαίνει μία σύνοψη. Τέσσερις agents σε αλυσίδα σημαίνουν τρεις, σύνθετες, καθεμία γραμμένη από μοντέλο που βελτιστοποιεί για κάτι άλλο από τη δική σας απόφαση.

Ο single agent βρήκε κάτι που κανείς δεν ζήτησε. Η ασυμφωνία purchase-order εμφανίστηκε επειδή ένα παράθυρο είχε ταυτόχρονα το τιμολόγιο και την παραγγελία. Η διάσπαση της εργασίας σε specialists διασπά και την ικανότητα να παρατηρήσετε ότι δύο γεγονότα διαφωνούν.

Τίποτα από αυτά δεν επιχειρηματολογεί κατά των δημοσιευμένων multi-agent frameworks, που αξίζει να διαβάζονται ως πρωτογενείς πηγές αντί μέσω tutorials.¹⁰ Επιχειρηματολογεί υπέρ του να κάνετε τον δεύτερο agent να κερδίσει τη θέση του.

Άρα, ένα τεστ και όχι μια προτίμηση. Προσθέστε δεύτερο agent όταν ισχύει τουλάχιστον ένα από τα εξής: η υποεργασία χρειάζεται καθαρό παράθυρο που ο parent δεν πρέπει να κληρονομήσει (Κεφάλαιο 24)· οι υποεργασίες είναι πραγματικά ανεξάρτητες και το wall clock έχει σημασία, που είναι το παραπάνω 1,8×· η υποεργασία χρειάζεται διαφορετικά permissions ή διαφορετικό μοντέλο, κάτι που το Κεφάλαιο 30 μετατρέπει σε επιχείρημα ασφάλειας· ή η υποεργασία ανήκει σε κάποιον άλλο, όπου αρχίζει να έχει σημασία ένα πραγματικό πρωτόκολλο. Αν η απάντηση είναι «ώστε κάθε agent να έχει πιο καθαρό prompt», δώστε στον έναν agent πιο καθαρό prompt. Είναι δωρεάν.

Μπορείτε τώρα να ονομάσετε τα πέντε μοτίβα, να τα κοστολογήσετε μεταξύ τους σε μία εργασία, να ξεχωρίσετε έναν orchestrator από έναν sectioner και ένα tool call από ένα handoff, και να υπερασπιστείτε έναν single agent με πίνακα αντί με προτίμηση.

Κάθε διάταξη εδώ μοιραζόταν μία ευκολία που δεν θα επιβιώσει από την επαφή με οτιδήποτε πραγματικό: όλα τα εργαλεία ήταν δικά μας. Τιμολόγιο, παραγγελία, φορολογικός πίνακας, οι workers πίσω από τον orchestrator — ίδιο repository, ίδιο deploy, ίδιοι τύποι, ίδιοι άνθρωποι.

Τώρα βάλτε ένα από αυτά στην άλλη πλευρά ενός εταιρικού ορίου. Ο φορολογικός πίνακας ανήκει σε vendor λογιστικής, το record της παραγγελίας σε σύστημα αποθήκης, και κανένα από τα δύο δεν έχει διαβάσει τη διεπαφή Tool σας. Χρειάζεστε τρόπο ώστε ένα μοντέλο που δεν γράψατε να ανακαλύπτει, να περιγράφει και να καλεί μια δυνατότητα που λειτουργεί κάποιος άλλος — με authentication (που είναι το μισό του Κεφαλαίου 27), versioning, και την εγγύηση ότι ένας server δεν μπορεί να διαβάσει την υπόλοιπη συζήτησή σας. Αυτό είναι πρόβλημα πρωτοκόλλου, έχει specification με normative schema, και σχεδόν όλα όσα έχουν ευρετηριαστεί γι’ αυτό περιγράφουν αναθεώρηση που δεν υπάρχει πλέον.

Το Κεφάλαιο 26 διαβάζει εκείνο το specification αντί να το συνοψίζει, και ξεκινά πληκτρολογώντας JSON-RPC σε terminal με το χέρι.

Κάθε κόστος και μέτρηση token παραπάνω προήλθε από τον scripted provider που περιγράφεται στη δεύτερη ενότητα, σε Node 22 πάνω από loopback interface, μετρώντας με το encoding o200k_base και κοστολογημένο με τις τιμές που διάβασε το Κεφάλαιο 16 στις 6 Σεπτεμβρίου 2026 — $2.00 ανά εκατομμύριο input tokens και $12.00 ανά εκατομμύριο output. Τα wall-clock figures είναι από τα ίδια runs με το latency του provider ορισμένο στα 400 ms ανά κλήση και των εργαλείων στα 50 ms, άρα μετρούν τη διάταξη αντί για οποιονδήποτε provider. Οι δύο μετρήσεις πραγματικού μοντέλου — ο πίνακας handoff και ο πίνακας voting-and-judging — χρησιμοποίησαν Qwen/Qwen2.5-0.5B-Instruct σε float32 στην CPU πίσω από endpoint του ίδιου σχήματος, greedy εκτός όπου δηλώνεται temperature, με διαστήματα υπολογισμένα με τη μέθοδο Wilson από το Κεφάλαιο 4. Κανένα request σε αυτό το κεφάλαιο δεν πήγε σε paid endpoint, και κανένας αριθμός σε αυτό δεν εκτιμήθηκε.