Context Engineering: Γιατί ο agent σας γίνεται πιο χαζός στο turn 40

Η Anthropic τράβηξε τη γραμμή τον Σεπτέμβριο του 2025 και οι δύο προτάσεις πρέπει να στέκονται δίπλα δίπλα. Prompt engineering είναι «μέθοδοι για τη συγγραφή και την οργάνωση οδηγιών LLM για βέλτιστα αποτελέσματα». Context engineering είναι «το σύνολο στρατηγικών για την επιμέλεια και τη διατήρηση του βέλτιστου συνόλου tokens (πληροφορίας) κατά το LLM inference, συμπεριλαμβανομένης όλης της άλλης πληροφορίας που μπορεί να καταλήξει εκεί εκτός των prompts».¹

Η λειτουργική διαφορά είναι πότε, και από ποιον. Ένα prompt γράφεται μία φορά, από άνθρωπο, και ελέγχεται. Ένα context συναρμολογείται σε κάθε κλήση, από κώδικα που δεν κοιτάζει κανείς, από υλικό που κανείς δεν έγραψε με το χέρι: σαράντα turns ιστορικού, έξι αποτελέσματα εργαλείων, τέσσερα retrieved αποσπάσματα, ένα προφίλ χρήστη, δώδεκα JSON schemas. Το Κεφάλαιο 15 μέτρησε τι αγοράζουν οι καλύτερες οδηγίες. Αυτό το κεφάλαιο αφορά το άλλο ενενήντα τοις εκατό των tokens, που φτάνει μόνο του.

Το ίδιο έγγραφο ονομάζει τον πόρο που ξοδεύουν όλα αυτά: τα μοντέλα «έχουν ένα 'attention budget' από το οποίο αντλούν όταν αναλύουν μεγάλους όγκους context. Κάθε νέο token που εισάγεται εξαντλεί αυτό το budget κατά κάποιο ποσό». Και ονομάζει το σύμπτωμα: «καθώς ο αριθμός των tokens στο context window αυξάνεται, η ικανότητα του μοντέλου να ανακαλεί με ακρίβεια πληροφορίες από αυτό το context μειώνεται» — context rot.¹

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

Σαράντα γραμμές προς το τοπικό endpoint από το Κεφάλαιο 22 — ένας μικρός Python server που κρατά το Qwen2.5-0.5B-Instruct στη CPU και μιλά στο σχήμα chat-completions, ώστε το loop να μένει TypeScript και τα tensors να μένουν στην άλλη πλευρά του port.

const DEPTHS = [0, 0.125, 0.25, 0.375, 0.5, 0.625, 0.75, 0.875, 1];

for (const d of DEPTHS) {
  const slot = Math.round(d * (N - 1));
  let hits = 0, other = 0;
  for (let t = 0; t < TRIALS; t++) {
    const recs = buildRecords(N, 1000 + t);          // 25 unique tickets
    const gold = recs[Math.floor(rng(7 + t)() * N)]; // a different one each trial
    const rest = recs.filter((x) => x.ticket !== gold.ticket).slice(0, N - 1);
    const lines = [...rest.slice(0, slot).map((x) => x.line),   
                   gold.line,                                   
                   ...rest.slice(slot).map((x) => x.line)];     
    const r = await complete(prompt(lines, ask(gold.owner)), { maxTokens: 12 });
    const said = /\d{4}/.exec(r.text)?.[0];
    if (said === String(gold.ext)) hits++;
    else if (said && recs.some((x) => String(x.ext) === said)) other++;
  }
}

Ο μετρητής other είναι αυτό που μετατρέπει ένα απογοητευτικό αποτέλεσμα σε χρήσιμο: όταν το μοντέλο κάνει λάθος, είναι χαμένο ή είναι σίγουρο;

Η απάντηση είναι σίγουρο. Στις οκτώ μη πρώτες θέσεις, 136 από τις 205 λανθασμένες απαντήσεις ήταν το εσωτερικό κάποιου άλλου ticket — ένας πραγματικός τετραψήφιος αριθμός, σωστά μορφοποιημένος, διαβασμένος από τη λάθος γραμμή. Στη θέση 1 μόνο μία από τις πέντε αστοχίες ήταν τέτοια· στη θέση 7, είκοσι μία από τις είκοσι έξι ήταν.

Αυτή η διάκριση είναι που έχει σημασία στην παραγωγή. Ένα μοντέλο που λέει δεν μπορώ να το βρω είναι bug που θα παρατηρήσετε· ένα μοντέλο που επιστρέφει τον αριθμό της γειτονικής γραμμής είναι bug που θα κάνετε ship, επειδή στην οθόνη τα δύο μοιάζουν ίδια. Είναι η αστοχία απέναντι στην οποία το Κεφάλαιο 19 έφτιαξε επαληθεύσιμες παραπομπές, μόνο που τώρα έρχεται μέσα από το prompt αντί από το index.

Η θέση είναι ένας άξονας. Το μήκος είναι ο άλλος, και πιο εύκολος να ελεγχθεί: κρατήστε την απάντηση στη μέση και μεγαλώστε τη λίστα.

Μία εγγραφή και 97 tokens: 90 %. Τρεις εγγραφές και 159 tokens: 55 %. Οκτώ εγγραφές και 315 tokens: 15 %, και από εκεί επίπεδα και χαμηλά μέχρι τις 140 εγγραφές και τα 4.477 tokens. Ολόκληρη η κατάρρευση συμβαίνει ανάμεσα στην πρώτη και την όγδοη γραμμή μιας λίστας.

Η τελευταία στήλη είναι ό,τι δεν είναι ούτε το σωστό εσωτερικό ούτε το εσωτερικό άλλης εγγραφής, που με μία μόνο εγγραφή στη σελίδα είναι το μόνο μέρος όπου μπορεί να προσγειωθεί μια λάθος απάντηση. Οι δύο αστοχίες στη μία εγγραφή αξίζει να αναφερθούν αντί να στρογγυλοποιηθούν μακριά, επειδή καμία δεν ήταν άρνηση: η μία απάντησε 5806 σε μητρώο του οποίου η μόνη γραμμή λέει 5805. Στα 97 tokens με έναν μόνο υποψήφιο, αυτό το μοντέλο εξακολουθεί να αντιγράφει λάθος ένα ψηφίο δύο φορές στις είκοσι, και αυτό είναι το πάτωμα πάνω στο οποίο μετριούνται όλα τα υπόλοιπα.

Ακολουθούν δύο πράγματα. Ένα μεγαλύτερο context αγοράζει το δικαίωμα να στείλετε περισσότερα, όχι τη βεβαιότητα ότι θα διαβαστούν: αυτό το μοντέλο έχει παράθυρο 32.768-token και working range, σε αυτή την εργασία, λίγων εκατοντάδων tokens. Και δεν υπάρχει threshold, δεν υπάρχει γκρεμός, δεν υπάρχει κατάσταση «context full» — η υποβάθμιση έχει ξεκινήσει στην τρίτη εγγραφή και ολοκληρώνεται στην όγδοη, στο ένα τοις εκατό του παραθύρου. Ό,τι κι αν είναι ένα όριο context, δεν είναι αυτό που το κυβερνά.

Συνήθως προσφέρονται δύο μηχανισμοί. Ο πρώτος είναι η αριθμητική από το Κεφάλαιο 9, που η Anthropic διατυπώνει με τους ίδιους όρους που χρησιμοποιεί αυτό το μάθημα: τα μοντέλα «βασίζονται στην transformer architecture, η οποία επιτρέπει σε κάθε token να attend σε κάθε άλλο token σε ολόκληρο το context. Αυτό έχει ως αποτέλεσμα n² ζευγαρωτές σχέσεις για n tokens».¹ Το attention σε μεγαλύτερη ακολουθία δεν είναι η ίδια πράξη εφαρμοσμένη σε περισσότερο υλικό· είναι ένα σταθερό budget probability mass απλωμένο σε περισσότερους ανταγωνιστές. Ο δεύτερος είναι η εκπαίδευση: τα μοντέλα βλέπουν πολύ περισσότερες σύντομες ακολουθίες από ό,τι μακρές, άρα τα μακρινής εμβέλειας positional patterns είναι το λιγότερο εξασκημένο μέρος του δικτύου. Αυτό είναι επιχείρημα, όχι μέτρηση, και αυτό το κεφάλαιο δεν μπορεί να το λύσει.

Αυτό που έχει λυθεί είναι το σχήμα, και έχει λυθεί από το 2023. Οι Liu et al. εξέτασαν multi-document question answering και key-value retrieval σε οικογένειες και μεγέθη μοντέλων και βρήκαν ότι «η απόδοση είναι συχνά υψηλότερη όταν η σχετική πληροφορία εμφανίζεται στην αρχή ή στο τέλος του input context, και υποβαθμίζεται σημαντικά όταν τα μοντέλα πρέπει να προσπελάσουν σχετική πληροφορία στη μέση μακρών contexts, ακόμη και για ρητά long-context μοντέλα».² Το Κεφάλαιο 15 πήρε τον κανόνα θέσης του από αυτό το paper· το Κεφάλαιο 19 πήρε από αυτό τον λόγο που είκοσι retrieved chunks μπορούν να σκοράρουν χειρότερα από τέσσερα. Η πρακτική μορφή του γεγονότος είναι η μόνη πρόταση εδώ πάνω στην οποία πρέπει να δράσετε: χρειάζονται πέντε λεπτά για να το μετρήσετε στο δικό σας μοντέλο με τα δικά σας δεδομένα, και καμία δημοσιευμένη καμπύλη δεν υποκαθιστά τη δική σας.

Ρωτήστε μια ομάδα τι γεμίζει το context του agent της και θα πάρετε μια εκτίμηση, επειδή κανένα API δεν επιστρέφει την απάντηση: η απόκριση σάς δίνει prompt_tokens, έναν αριθμό για όλα μαζί.

Μπορείτε να ανακτήσετε την ανάλυση με τέσσερις μετρήσεις και τρεις αφαιρέσεις — το ολόκληρο rendered prompt, το ίδιο χωρίς ορισμούς εργαλείων, μόνο το system message με και χωρίς αυτούς, και τα πάντα με τα αποτελέσματα εργαλείων αφαιρεμένα:

async function buckets(messages: Msg[]) {
  const sys = messages.slice(0, 1);
  const withoutResults = messages.filter((m) => m.role !== "tool");
  const [total, sysWithTools, sysNoTools, noResults] = await Promise.all([
    countPrompt(messages, CATALOGUE),        // everything
    countPrompt(sys, CATALOGUE),             // system + scaffolding + schemas
    countPrompt(sys),                        // system + scaffolding
    countPrompt(withoutResults, CATALOGUE),  // everything but tool output
  ]);
  return {
    system: sysNoTools,
    tools: sysWithTools - sysNoTools,                                  
    toolResults: total - noResults,                                    
    conversation: total - sysWithTools - (total - noResults),          
    total,
  };
}

Το countPrompt εφαρμόζει το ίδιο chat template του μοντέλου πριν το tokenizing, πράγμα που έχει μεγαλύτερη σημασία από όσο ακούγεται: το κείμενό σας δεν είναι αυτό που μετριέται. Role markers, το tool-calling preamble και το schema rendering είναι όλα tokens που πληρώνετε και δεν πληκτρολογήσατε ποτέ. Το Κεφάλαιο 7 έφτιαξε έναν tokenizer και το Κεφάλαιο 16 μέτρησε με το js-tiktoken· εδώ η μέτρηση έρχεται από το ίδιο μοντέλο που θα διαβάσει το prompt, που είναι η μόνη μέτρηση που είναι ακριβώς σωστή.

Τώρα περάστε έναν πραγματικό agent μέσα από αυτό: σαράντα turns μιας διερεύνησης incident, δώδεκα εργαλεία, ένα ψεύτικο περιβάλλον operations που επιστρέφει ρεαλιστικά log dumps και σειρές metrics.

Διαβάστε την πρώτη σειρά απέναντι στην τελευταία.

Στο turn 1 το prompt είναι 2.547 tokens και το 71 % του είναι ορισμοί εργαλείων. Το system prompt είναι 3 %. Αυτό που πληκτρολόγησε ο χρήστης είναι 6 %. Ο agent δεν έχει κάνει ακόμα τίποτα και ήδη κουβαλά 1.817 tokens JSON schema.

Μέχρι το turn 40 το prompt είναι 10.632 tokens και τα μερίδια έχουν αντιστραφεί: ορισμοί 17 %, συνομιλία 29 %, αποτελέσματα εργαλείων 53 %. Το output εργαλείων ξεπέρασε τους ορισμούς στο turn 5· η συνομιλία δεν τους ξεπέρασε μέχρι το turn 25, άρα για το πρώτο εξήντα τοις εκατό της συνεδρίας ο κατάλογος εργαλείων ήταν μεγαλύτερος από όλα όσα είχαν ειπωθεί.

Μετά το σύνολο. Σε 57 κλήσεις μοντέλου, το run χρέωσε 370.291 input tokens για τελικό context 10.632 — το τελευταίο prompt πληρώθηκε περίπου τριάντα πέντε φορές, δηλαδή το τετραγωνικό του Κεφαλαίου 16 με τον πολλαπλασιαστή ενός agent από πάνω. Από αυτά τα 370.291, 103.569, ή 28 % όλων όσων χρεώθηκαν, ήταν οι δώδεκα ορισμοί εργαλείων, που ξαναστάλθηκαν byte-identical σε κάθε κλήση.

Ο κατάλογος εργαλείων είναι το μεγαλύτερο σταθερό κόστος σε έναν agent και είναι αόρατος, επειδή δεν τον βλέπετε ποτέ: περνάτε ένα array αντικειμένων και ο provider το αποδίδει στο prompt για εσάς. Μετρημένο, στα ίδια δώδεκα εργαλεία:

system prompt + chat scaffolding, no tools:        85 tokens
all twelve definitions:                          1,817 tokens
  of which fixed tool-calling scaffolding:         126 tokens
three tools instead of twelve:                     605 tokens
same twelve, one-sentence descriptions,
  no parameter prose:                            1,291 tokens  (-29 %)

Ανά εργαλείο, το marginal κόστος τρέχει από 80 tokens για το get_current_time, που παίρνει ένα string, έως 263 για το search_tickets, που παίρνει τέσσερις παραμέτρους με enum και μία πρόταση καθοδήγησης η καθεμία. Αυτή είναι η ισοτιμία πίσω από την κεντρική συμβουλή του Κεφαλαίου 18 ότι η περιγραφή είναι το API: μια καλή περιγραφή κοστίζει περίπου εκατό tokens σε κάθε request για το υπόλοιπο της ζωής του agent. Τρεις συνέπειες.

Ένα εργαλείο που δεν χρησιμοποιείτε εξακολουθεί να χρεώνεται. Ο agent κάλεσε επτά από τα δώδεκα. Τα άλλα πέντε κόστισαν 697 tokens σε καθεμία από τις 57 requests — 39.729 συνολικά, πάνω από το ένα δέκατο όλων όσων χρεώθηκε το run, για δυνατότητες που δεν άγγιξε ποτέ. Ένα από τα πέντε κουβαλά την πιο αιχμηρή λεπτομέρεια στο trace: το μοντέλο προσπάθησε τρεις φορές να καλέσει το read_log, που δεν υπάρχει. Το εργαλείο που ήθελε ήταν το search_logs, ο δεύτερος ακριβότερος ορισμός στον κατάλογο στα 237 tokens. Πλήρωσε για αυτόν τον ορισμό 57 φορές, δεν τον χρησιμοποίησε ποτέ και δεν βρήκε ποτέ το όνομά του.

Το κόψιμο της πρόζας είναι η φθηνότερη βελτιστοποίηση διαθέσιμη, και είναι trade. Το να κοπούν οι περιγραφές σε μία πρόταση και να αφαιρεθεί η τεκμηρίωση παραμέτρων εξοικονόμησε 526 tokens ανά κλήση, 29 τοις εκατό, χωρίς να αγγιχτεί ούτε γραμμή λογικής — και έκανε το μοντέλο να καλεί τα εργαλεία χειρότερα, όπως μέτρησε το Κεφάλαιο 18. Το νόημα είναι ότι και οι δύο πλευρές αυτού του trade είναι τώρα στην ίδια μονάδα.

Σε κάποια κλίμακα, το να στέλνετε ορισμούς καθόλου παύει να έχει νόημα. Η Anthropic έβαλε αριθμό σε αυτό τον Νοέμβριο του 2025: ένα μεγάλο σύνολο συνδεδεμένων servers σημαίνει επεξεργασία «εκατοντάδων χιλιάδων tokens» ορισμών πριν διαβαστεί το request, και η αντικατάστασή του με code execution — ο agent να ανακαλύπτει και να φορτώνει μόνο τους ορισμούς που χρειάζεται — «μειώνει τη χρήση token από 150.000 tokens σε 2.000 tokens, εξοικονόμηση χρόνου και κόστους 98,7%».³ Ίδια ιδέα με το υπόλοιπο αυτού του κεφαλαίου, εφαρμοσμένη σε schemas αντί για ιστορικό: κρατήστε το index, επιλύστε την εγγραφή on demand.

Δύο πράγματα φυτεύτηκαν σε εκείνο το transcript σαράντα turns. Στο turn 2, πριν από οποιαδήποτε πραγματική δουλειά, ο χρήστης δηλώνει έναν standing rule: κάθε ticket που ανοίγεις πρέπει να καταχωρείται κάτω από τον αριθμό υπαλλήλου μου, 4417. Στο turn 19, στη μέση του incident, ένα γεγονός: το affected shard είναι pay-shard-7, επιβεβαιωμένο από την ομάδα payments. Στο turn 40 ο χρήστης ζητά από τον agent να ανοίξει το incident ticket, που χρειάζεται και τα δύο. Κάθε probe τίθεται σε έξι διαφορετικές διατυπώσεις και βαθμολογείται στα έξι — το greedy decoding είναι ντετερμινιστικό, άρα μία κλήση δίνει ένα μη επαναλήψιμο ναι ή όχι και έξι δίνουν ποσοστό.

Το transcript αναπαράγεται έπειτα κάτω από επτά πολιτικές context. Αναπαράγεται αντί να ξανατρέξει, σκόπιμα: τα μηνύματα, οι tool calls και τα αποτελέσματα εργαλείων είναι byte-identical και στα επτά, άρα η μόνη μεταβλητή είναι τι επέλεξε να κρατήσει κάθε πολιτική. Το Κεφάλαιο 16 έδειξε γιατί ένα sliding window είναι κακή οικονομική κίνηση, επειδή καταστρέφει το cacheable prefix. Να τι κάνει στη συμπεριφορά:

Οι σειρές compaction περιλαμβάνουν το κόστος του compacting: 18.581 input tokens για επτά summaries και 3.392 ακόμη για τον note-taker. Η σειρά control υπάρχει ώστε ένα μηδέν να μπορεί να διαβαστεί ως μηδέν — με τα δύο μηνύματα μόνα τους σε prompt 1.981-token, αυτό το μοντέλο απαντά και στα δύο probes τέλεια, άρα καμία σειρά δεν είναι η εργασία που είναι υπερβολικά δύσκολη.

Το πλήρες ιστορικό θυμάται, και είναι το ακριβότερο πράγμα στον πίνακα: 370.291 input tokens για μια συνεδρία της οποίας το durable content είναι δύο προτάσεις.

Αυτό απαντά σε μια ερώτηση που άφησε ανοιχτή η αρχή. Γιατί ένα transcript 10.632-token κρατά ένα γεγονός που ένα μητρώο 853-token χάνει; Επειδή το μήκος είναι η λάθος μεταβλητή. Το μητρώο κρατά είκοσι πέντε τετραψήφια εσωτερικά σε είκοσι πέντε πανομοιότυπες προτάσεις — είκοσι τέσσερα σχεδόν τέλεια decoys για το ένα που θέλετε. Το transcript κρατά ακριβώς έναν αριθμό υπαλλήλου και ένα όνομα shard. Το context rot είναι interference πριν γίνει όγκος, γι’ αυτό 136 από τις 205 λανθασμένες απαντήσεις εκεί πάνω ήταν η τιμή ενός γείτονα. Η χρήσιμη ερώτηση για ένα παράθυρο δεν είναι πόσο μακρύ είναι· είναι πόσα πράγματα μέσα του μοιάζουν με την απάντηση.

Το sliding window είναι 57 % φθηνότερο και έχει χάσει το incident. Ο αριθμός υπαλλήλου επιβιώνει μόνο επειδή ο agent τον είχε επαναλάβει στα πρόσφατα turns. Το shard, δηλωμένο μία φορά στο turn 19, δεν βρίσκεται στα τελευταία δώδεκα μηνύματα — και το μοντέλο δεν το λέει. Όταν ρωτήθηκε έξι φορές απάντησε «το affected payment shard είναι shard 4417», πιάνοντας τον αριθμό υπαλλήλου, το μόνο άλλο identifier που είχε μείνει στο παράθυρό του, και δύο φορές «pool», σηκωμένο από το string pool_exhausted σε μια γραμμή log.

Το compaction είναι φθηνό και έχασε το ίδιο γεγονός. Επτά summaries, γραμμένα από το μοντέλο με ρητή οδηγία να κρατήσει identifiers, αριθμούς, standing instructions και ανοιχτές ερωτήσεις, και το pay-shard-7 δεν βρίσκεται σε κανένα από τα summaries που είχαν σημασία· οι έξι μαντεψιές ήταν shard 1, pay_shard_1 και pool. Το compaction δεν αποτυγχάνει θορυβωδώς. Παράγει μια ρέουσα, εύλογη, πολύ συντομότερη συνεδρία που έχει αθόρυβα ρίξει μία γραμμή.

Τρεις σειρές σκόραραν 0/6 στο γεγονός του turn 19 — το sliding window, το compaction και το compaction με notes. Δεκαοκτώ λάθος απαντήσεις ανάμεσά τους, και ούτε μία δεν ήταν «δεν ξέρω».

Μετά η σειρά που θα έπρεπε να είναι ντροπιαστική. Το να κρατήσετε verbatim τα σαράντα μηνύματα του χρήστη, συν τα τελευταία τέσσερα turns πλήρως και τίποτε άλλο, κοστίζει 168.550 tokens — 54 % λιγότερο από το πλήρες ιστορικό — και απαντά και στα δύο probes εξίσου καλά με το πλήρες ιστορικό ή καλύτερα. Κανένας summariser, κανένας note-taker, κανένα δεύτερο μοντέλο: ένα filter στο role === "user". Τα λόγια του χρήστη είναι τα φθηνότερα tokens υψηλής αξίας στο παράθυρο ενός agent, και οι περισσότερες σχεδιάσεις τα πετούν μαζί με όλα τα άλλα.

Οι τελευταίες δύο σειρές είναι ξανά ο αρχικός πίνακας, μέσα στον agent. Το ίδιο pinned block, μετακινημένο από το system message στο τέλος του prompt: το 5/6 γίνεται 6/6. Σε έξι δοκιμές αυτό δεν είναι σημαντική διαφορά και δεν προσφέρεται ως τέτοια — προσφέρεται ως υπενθύμιση ότι το πού είναι παράμετρος που ρυθμίζετε είτε το ξέρετε είτε όχι.

Οι τέσσερις στρατηγικές παρακάτω είναι της Anthropic, με τη σειρά της, αν και μόνο οι τελευταίες τρεις είναι η long-horizon λίστα της.¹ Και οι τέσσερις είναι παραλλαγές μίας οδηγίας: μην κουβαλάτε ό,τι μπορείτε να φέρετε όταν χρειαστεί, και μην κουβαλάτε raw ό,τι μπορείτε να κουβαλήσετε συμπιεσμένο.

const elide: Policy = (h) => [SYSTEM, ...h.flatMap((turn, ti) =>
  turn.map((m) => (ti < h.length - 4 && m.role === "tool"
    ? { role: "tool", name: m.name,
        content: `[${m.name} result from turn ${ti + 1}, ${m.content.length} chars, ` +
                 `elided; call ${m.name} again with the same arguments to re-read it]` }
    : m)))];

const r = await complete([
  { role: "system", content:
      "You keep a durable note file for a support session. Given one user message, " +
      "output one short note ONLY if it states a standing rule, an identifier or a fact " +
      "that must survive the rest of the session. Otherwise output exactly NONE." },
  { role: "user", content: `Turn ${i + 1}: ${user}` },
], { maxTokens: 40 });
if (!/^none\b/i.test(r.text.trim())) notes.push(`turn ${i + 1}: ${r.text.trim()}`);

Ο sub-agent δεν βρίσκεται στον παραπάνω πίνακα επειδή δεν τρέχει για σαράντα turns: τρέχει μία φορά, σε ένα παράθυρο που κάποιος scoped για αυτόν. Με δεδομένο το system prompt, τα turns 17 έως 19 και τίποτε άλλο — 2.737 tokens — απάντησε στο shard probe 6/6, καλύτερα από κάθε πολιτική στον πίνακα, και στο employee probe 0/6, επειδή αυτός ο αριθμός δεν βρίσκεται στα τρία turns που του δόθηκαν.

Αυτό είναι οι sub-agents σε δύο αριθμούς: ένα καθαρό παράθυρο δεν είναι ευφυΐα, είναι scope, και το scoping γίνεται εκ των προτέρων από κώδικα που ήδη πρέπει να ξέρει ποια turns έχουν σημασία. Αξίζει να κρατήσουμε ακόμη ένα πράγμα σε αυτές τις απαντήσεις. Αυτή ήταν η μόνη πολιτική που απάντησε «None available» αντί να επινοήσει κάτι. Ένα μοντέλο με μικρό, coherent context ξέρει τι του λείπει· ένα μοντέλο με μεγάλο, θορυβώδες context δεν το ξέρει.

Σχεδόν κάθε μπερδεμένη συζήτηση για agent memory είναι τρεις μηχανισμοί που φορούν την ίδια λέξη. Έχουν διαφορετικές διάρκειες ζωής, owners και failure modes, και ένα σύστημα που τα κρατά στο ίδιο μέρος έχει ένα πρόβλημα που δεν έχει ακόμη παρατηρήσει.

Το ακαδημαϊκό πλαίσιο είναι του CoALA, που οργανώνει language agents γύρω από «modular memory components» και διαχωρίζει τη working memory από episodic, semantic και procedural stores.⁴ Το MemGPT παίρνει την ίδια ιδέα κυριολεκτικά, δανειζόμενο virtual memory από λειτουργικά συστήματα: ένα γρήγορο tier μέσα στο παράθυρο, ένα αργό tier έξω από αυτό, και το ίδιο το μοντέλο να μετακινεί δεδομένα ανάμεσά τους με function calls.⁵ Και τα δύο επιβάλλουν την ερώτηση που ένα product πρέπει ούτως ή άλλως να απαντήσει — όχι πόσα μπορώ να κρατήσω, αλλά σε ποιο store ανήκει αυτό, και πότε λήγει.

Η πρακτική δοκιμή είναι μία ερώτηση ανά γεγονός: τι πρέπει να εξακολουθεί να ισχύει αύριο; Ένα αποτέλεσμα εργαλείου από το turn 12, τίποτα. Ένα summary της συνεδρίας, μέχρι να τελειώσει η συνεδρία. Ότι ο αριθμός υπαλλήλου του χρήστη είναι 4417, μέχρι να αλλάξει δουλειά. Τρεις απαντήσεις, τρία stores.

Μπορείτε τώρα να μετρήσετε τι υπάρχει σε ένα παράθυρο, να αποφασίσετε τι μένει σε αυτό, και να ξεχωρίσετε έναν agent που ξέχασε κάτι από έναν που το κουβαλούσε και δεν κοίταξε.

Η τελευταία από τις τέσσερις στρατηγικές είναι αυτή που δεν χωρά εδώ. Ένας sub-agent δεν είναι πολιτική context, είναι δεύτερος agent, και τη στιγμή που υπάρχουν δύο πρέπει να αποφασίσετε τι περνά ανάμεσά τους και ποιος έχει την ευθύνη. Το Κεφάλαιο 25 είναι αυτό: τα πέντε orchestration patterns και από πού προέρχεται πραγματικά το κάθε όνομά τους, οι δύο τοπολογίες που μπερδεύονται — να ρωτάς έναν sub-agent και να παίρνεις απάντηση πίσω, σε αντίθεση με το να του παραδίνεις τη συνομιλία και να μην την παίρνεις πίσω — και το μετρημένο εύρημα ότι στην εργασία που κοστολογεί, η απλούστερη διάταξη κερδίζει — ακολουθούμενο από το τεστ για το πότε σταματά να κερδίζει.

Κληρονομεί επίσης ακριβώς αυτό που μόλις μέτρησε αυτό το κεφάλαιο. Ένας sub-agent επιστρέφει ένα summary. Ένα summary είναι compaction που δεν γράψατε, παραγόμενο από μοντέλο του οποίου το παράθυρο δεν μπορείτε να δείτε, και ο γονέας δεν έχει τρόπο να ξεχωρίσει ένα καλό από ένα σίγουρο λάθος — την ίδια διάκριση που χώρισε το 84 % από το 19 % στην κορυφή αυτής της σελίδας, και που μετέτρεψε δεκαοκτώ missing facts σε δεκαοκτώ επινοημένα. Άρα: όταν ο sub-agent κάνει λάθος, τι ακριβώς μπορεί να κοιτάξει ο γονέας;

Κάθε αριθμός εδώ παράχθηκε σε αυτό το μηχάνημα και κανένας δεν εκτιμήθηκε. Το μοντέλο είναι Qwen2.5-0.5B-Instruct σε float32 στη CPU με greedy decoding, σερβιρισμένο πάνω από loopback από ένα μικρό Python endpoint που μιλά στο σχήμα chat-completions και εκθέτει route token-count — ξανά το seam του Κεφαλαίου 14, tensors στην πλευρά της Python και το loop στην πλευρά της TypeScript — άρα κάθε μέτρηση είναι ο ίδιος tokenizer του μοντέλου εφαρμοσμένος στο ίδιο του το chat template. Ο πίνακας θέσης είναι 288 κλήσεις, εννέα θέσεις επί τριάντα δύο δοκιμές με διαφορετικό ticket σε κάθε δοκιμή· ο πίνακας μήκους είναι 140 κλήσεις· το agent run είναι 57 κλήσεις μοντέλου σε 43 λεπτά wall clock· ο πίνακας πολιτικών είναι εκείνο το ένα transcript αναπαραγμένο κάτω από επτά πολιτικές. Τα διαστήματα είναι του Wilson, από το Κεφάλαιο 4. Δεν κλήθηκε paid API, γι’ αυτό και δεν υπάρχει ούτε μία τιμή στο κεφάλαιο: τα token counts είναι ακριβή και τα rates με τα οποία θα τα πολλαπλασιάζατε είναι του Κεφαλαίου 16.