Agents on Call, Μέρος 1. Το σενάριο: Γιατί μια ομάδα Ops προσλαμβάνει agents

Μια μεσαίου μεγέθους B2B SaaS εταιρεία με περίπου 50 μηχανικούς σε γύρω στους 30 λογαριασμούς AWS ειδοποιεί κάποιον on-call περίπου 40 φορές την εβδομάδα, και η ειδοποίηση παίρνει πραγματική απάντηση μόνο μετά από 25 έως 35 λεπτά χειρωνακτικής συλλογής πλαισίου: ποιος λογαριασμός, ποιο dashboard, ποιο runbook, αν αυτό το runbook είναι έστω ακόμα ακριβές. Αυτό συμβαίνει πριν ξεκινήσει η διάγνωση, όχι αντί για αυτήν. Αυτή η σειρά χτίζει τη λύση: μια μικρή πλατφόρμα από AI agents που κάνει αυτό το πρώτο πέρασμα αυτόματα, διαβάζει ό,τι της επιτρέπεται να διαβάσει, δεν αλλάζει τίποτα χωρίς την έγκριση ενός ανθρώπου, και σταματά να είναι χρήσιμη τη στιγμή που σταματά να είναι τόσο πειθαρχημένη.

Η εταιρεία, και τι πραγματικά πληρώνει σε χειρωνακτική δουλειά

Ας πούμε την εταιρεία αυτό που είναι: ένα μεσαίου μεγέθους B2B SaaS shop, περίπου 50 μηχανικούς, γύρω στους 30 λογαριασμούς AWS κατανεμημένους σε μια χούφτα product lines, καθεμία με τη δική της τριάδα dev, staging και production. Κανείς δεν ξεκίνησε με στόχο να καταλήξει με 30 λογαριασμούς. Συνέβη με τον συνηθισμένο τρόπο, μία ομάδα τη φορά ζητώντας απομόνωση, μέχρι που το AWS Organizations να αντικατοπτρίζει περισσότερο το οργανόγραμμα παρά την αρχιτεκτονική.

Η χειρωνακτική δουλειά δεν είναι δραματική. Είναι συσσωρευτική, και τέσσερις αριθμοί από τρεις μήνες δεδομένων on-call και ένα άβολο retro δείχνουν καθαρά το σχήμα της:

• Περίπου 40 ειδοποιήσεις την εβδομάδα καταλήγουν σε όποιον είναι στη βάρδια, κατανεμημένες άνισα στους 30 λογαριασμούς.
• 25 έως 35 λεπτά από κάθε ειδοποίηση ξοδεύονται στη συλλογή πλαισίου πριν καν ξεκινήσει η διάγνωση: ο σωστός λογαριασμός, το σωστό dashboard, το σωστό runbook, και αν αυτό το runbook ταιριάζει ακόμα με την πραγματικότητα.
• Η μηνιαία επισκόπηση FinOps τρέχει περίπου τρεις εβδομάδες πίσω από την πραγματική δαπάνη, οπότε ένα λανθασμένα ρυθμισμένο autoscaling group ή ένα αδρανές GPU instance καίει χρήματα για το μεγαλύτερο μέρος ενός μήνα πριν εμφανιστεί σε μια αναφορά που κάποιος διαβάζει.
• Ένας πρόσφατος έλεγχος runbooks βρήκε ότι περίπου ένα στα τρία runbooks έδειχναν σε έναν πόρο, ένα ARN, ή ένα console path που δεν υπήρχε πια.

Κανένα από αυτά τα τέσσερα δεν είναι από μόνο του επείγον. Μαζί όμως αποτελούν έναν μόνιμο φόρο στην ομάδα: κάπου γύρω στις 30 έως 40 ώρες μηχανικού την εβδομάδα ξοδεύονται στο μηχανιστικό κομμάτι των operations, στη συλλογή πλαισίου και στην επανεπαλήθευση ξεπερασμένων οδηγιών, πληρωμένες από ανθρώπους που προσλήφθηκαν για να χτίζουν προϊόν, όχι για να είναι ανθρώπινοι συλλέκτες πλαισίου.

Γιατί agents, και γιατί τώρα

Η ειλικρινής απάντηση στο «γιατί τώρα» είναι ότι τα κομμάτια επιτέλους υπάρχουν ως managed services αντί για εσωτερικά frameworks που κάποιος πρέπει να συντηρεί συνεχώς. Το Bedrock προσφέρει managed υπηρεσία ενορχήστρωσης agents, το Agents for Amazon Bedrock, από τότε που έφτασε σε γενική διαθεσιμότητα τον Νοέμβριο του 2023, με βελτιωμένο έλεγχο ενορχήστρωσης και ορατότητα στο reasoning trace. Αυτό που άλλαξε είναι το επίπεδο πάνω από αυτό. Το Amazon Bedrock AgentCore έγινε γενικά διαθέσιμο στις 2025-10-13, σε εννέα περιοχές, πακετάροντας επτά υπηρεσίες συστατικών (Runtime, Memory, Identity, Gateway, Code Interpreter, Browser, Observability) που παλιότερα σήμαιναν να χτίσεις ένα session store, έναν credential broker και ένα tracing pipeline από το μηδέν. Παράλληλα, η AWS έκανε open source το Strands Agents SDK τον Μάιο του 2025 υπό άδεια Apache 2.0 και κυκλοφόρησε μια production έκδοση 1.0 για Python στις 2026-05-21, μια εβδομάδα πριν ξεκινήσει το δικό του timeline αυτό το άρθρο. Τόσο η managed υποδομή όσο και το ανοιχτό επίπεδο ενορχήστρωσης πέρασαν το όριο ετοιμότητας για production μέσα στους ίδιους λίγους μήνες. Αυτό το παράθυρο είναι όταν χτίζεται αυτή η πλατφόρμα.

Να το χτίσουμε ή να το αγοράσουμε

Η ομάδα κοίταξε πρώτα την αγορά λύσης, όπως θα έπρεπε. Ένα έτοιμο προϊόν AIOps ή incident-copilot θα είχε κυκλοφορήσει πιο γρήγορα και δεν θα χρειαζόταν καθόλου Terraform. Έχασε για τρεις λόγους που αφορούν συγκεκριμένα αυτή την εταιρεία, όχι τους agents γενικά.

• Το όριο των mutations δεν είναι διαπραγματεύσιμο. Όποιος εκτελεί μια διόρθωση πρέπει να αναλάβει έναν στενά καθορισμένο ρόλο IAM στον επηρεαζόμενο λογαριασμό, φραγμένο από ένα εσωτερικό βήμα έγκρισης. Ένα προϊόν SaaS σου ζητά είτε να του δώσεις ευρεία πρόσβαση cross-account είτε να κολλήσεις τη δική του ροή έγκρισης πάνω στη δική σου εκ των υστέρων. Η ιδιοκτησία της πλατφόρμας σημαίνει ότι η πύλη έγκρισης είναι εγγενής από την πρώτη μέρα, όχι ενσωματωμένη αργότερα.
• Η γνώση των τριάντα λογαριασμών ζει σε νήματα Slack και στο μυαλό των μηχανικών, όχι σε μορφή που καταλαβαίνει το ingestion pipeline ενός προμηθευτή. Ένα Bedrock Knowledge Base πάνω στο υπάρχον σώμα runbooks, με την ομάδα να ελέγχει άμεσα το chunking και την ποιότητα του retrieval, είναι πιο διαχειρίσιμο από το να εξάγεις αυτή τη γνώση σε τρίτο μέρος ελπίζοντας ότι το retrieval του θα είναι αρκετά καλό.
• Η εταιρεία ήδη λειτουργεί AWS σε αυτή την κλίμακα. Το Terraform, το CI, η βάρδια on-call, η δομή λογαριασμών, όλα υπάρχουν ήδη σήμερα. Το οριακό κόστος του να χτίσεις πάνω σε AWS-native primitives είναι χαμηλότερο από το κόστος μιας δεύτερης σχέσης με προμηθευτή, μιας δεύτερης γραμμής χρέωσης, και μιας δεύτερης επιθεώρησης ασφάλειας.

Το αντεπιχείρημα είναι πραγματικό: η αγορά είναι πιο γρήγορη, και η ταχύτητα έχει αξία όταν η χειρωνακτική δουλειά συσσωρεύεται εβδομαδιαία. Η απάντηση της ομάδας ήταν να ορίσει στενά το πεδίο του build (τέσσερις agents, ένα μοτίβο έγκρισης, on-demand inference για αρχή, δείτε τα μαθηματικά του sizing σε επόμενο μέρος) αντί να το αντιμετωπίσει ως το αιώνιο project μιας ομάδας πλατφόρμας. Ο συνοδευτικός κώδικας για ολόκληρη τη σειρά βρίσκεται στο github.com/flightlesstux/agents-on-call· εδώ ξεκινά το δικό του docs/architecture.md.

Η απόφαση για το stack: τρεις τρόποι να τρέξεις έναν agent στο Bedrock

Μόλις η ομάδα αποφάσισε να χτίσει, η επόμενη απόφαση ήταν σε ποιο επίπεδο θα χτίσει. Υπήρχαν τρεις πραγματικές επιλογές, και το trade-off δεν είναι καν κοντά στο τόσο απλό όσο «χρησιμοποίησε το πιο καινούργιο πράγμα»:

Η ομάδα διάλεξε AgentCore σε συνδυασμό με Strands. Τα managed κομμάτια που δεν ήθελαν να έχουν στην ιδιοκτησία τους (απομόνωση session, credential brokering, ένα cross-account gateway) ήρθαν συνδυασμένα με ένα επίπεδο ενορχήστρωσης που μπορούσαν να διαβάσουν και να κάνουν debug, αντί για ένα που έπρεπε να αντιστρέψουν από ένα console. Το AgentCore Runtime στη γενική διαθεσιμότητα δίνει σε κάθε session agent πλήρη απομόνωση και ένα παράθυρο εκτέλεσης οκτώ ωρών, με υποστήριξη πρωτοκόλλου Agent2Agent αν οι agents αυτής της πλατφόρμας χρειαστεί ποτέ να μιλήσουν με agents εκτός αυτής. Το CLI @aws/agentcore, που κυκλοφόρησε στις 22 Απριλίου 2026, πρόσθεσε μια ροή εργασίας create, dev, deploy, invoke, logs και traces που υποστηρίζει απευθείας το Strands (επίσης LangGraph, LangChain, Google ADK, OpenAI Agents, ή bring-your-own), κάτι που μέτρησε για το onboarding: κανείς δεν χρειάστηκε να μάθει ένα ολοκαίνουργιο εργαλείο deployment στη μέση του project.

Το κλασικό Bedrock Agents παρέμεινε γνησίως ελκυστικό από μόνο του: δυόμισι χρόνια ιστορικού σε production, λιγότερος προσαρμοσμένος κώδικας στην ιδιοκτησία σου, και ένα απλούστερο νοητικό μοντέλο όταν ένα action group είναι το μόνο που χρειάζεται μια περίπτωση χρήσης. Έχασε εδώ επειδή τέσσερις agents που μοιράζονται ένα μοτίβο supervisor πάνω σε ένα σκληρό όριο IAM πολλαπλών λογαριασμών χρειάζονταν περισσότερο έλεγχο πάνω στον βρόχο από όσο εκθέτουν τα action groups. Το αυτο-χτισμένο πάνω στο ακατέργαστο Converse API απορρίφθηκε για τον αντίθετο λόγο: το να γράψεις ένα session store, έναν credential broker και ένα tracing pipeline από το μηδέν, για κάτι που η AWS ήδη προσφέρει ως AgentCore Runtime, Memory, Identity και Observability, θα είχε ξοδέψει τους πρώτους δύο μήνες του project επανεφευρίσκοντας υποδομή αντί να γράφει agents.

Στοχευόμενη αρχιτεκτονική: hub-and-spoke σε όλο τον οργανισμό

Η πλατφόρμα είναι multi-account, hub-and-spoke, και σκόπιμα προσθετική. Αν πέσει, ο οργανισμός υποβαθμίζεται ακριβώς στο status quo: οι άνθρωποι ειδοποιούνται όπως πάντα. Δεν βρίσκεται ποτέ στο κρίσιμο μονοπάτι ειδοποίησης.

graph TD
  MGMT["management account
org root, SCPs, no workloads"]
  SEC["security account
org CloudTrail, GuardDuty,
Security Hub delegated admin"]
  OPS["ops-tooling account
the agent platform"]
  W1["workload account 1"]
  W2["workload account 2"]
  WN["workload account N
~30 total"]

  MGMT -. SCPs .-> SEC
  MGMT -. SCPs .-> OPS
  MGMT -. SCPs .-> W1
  MGMT -. SCPs .-> W2
  MGMT -. SCPs .-> WN

  W1 -- alarm events --> OPS
  W2 -- alarm events --> OPS
  WN -- alarm events --> OPS

  OPS -- "assume ops-readonly, read-only tools" --> W1
  OPS -- "assume ops-readonly, read-only tools" --> W2
  OPS -- "assume ops-readonly, read-only tools" --> WN
  OPS -. "assume ops-mutate, approved executor only" .-> W1

Κάθε λογαριασμός workload εκθέτει ακριβώς δύο ρόλους στο ops-tooling: τον ops-readonly, τον οποίο μπορεί να αναλάβει κάθε Lambda εργαλείου, χτισμένο από read-only managed policies της AWS με ρητές απαγορεύσεις από πάνω· και τον ops-mutate, τον οποίο μπορεί να αναλάβει ακριβώς μία Lambda, αυτή που τρέχει αφότου ένας άνθρωπος εγκρίνει μια προτεινόμενη ενέργεια, περιορισμένη σε μια allowlist συγκεκριμένων εγγράφων SSM Automation. Κανένας agent, καμία άλλη Lambda, κανένα code path εκτός από αυτόν τον μοναδικό post-approval executor δεν μπορεί ποτέ να αναλάβει τον ops-mutate. Αυτός ο διαχωρισμός, όχι μια οδηγία prompt, είναι αυτό που κάνει το read-only την προεπιλογή: επιβάλλεται από το IAM, όχι ζητώντας ευγενικά από ένα μοντέλο.

Μέσα στο ops-tooling

Ας εστιάσουμε στον έναν λογαριασμό όπου ζει η υπόλοιπη σειρά:

graph LR
  subgraph entry["Entry"]
    EB["EventBridge bus
cross-account alarms"]
    SLACK["Slack app
API Gateway + verifier Lambda"]
    SCHED["EventBridge Scheduler
daily cost sweep"]
  end
  subgraph agents["Agent layer"]
    SUP["supervisor"]
    TRI["incident-triage"]
    RUN["runbook"]
    COST["cost"]
    MEM["AgentCore Memory"]
    ID["AgentCore Identity"]
  end
  subgraph models["Model layer"]
    BR["Bedrock, cross-region
inference profiles"]
    GR["Bedrock Guardrails"]
    KB["Knowledge Base
runbook corpus"]
  end
  subgraph tools["Tool layer"]
    GW["AgentCore Gateway"]
    T1["cloudwatch-read"]
    T2["logs-read"]
    T3["cost-read"]
    T4["ssm-execute"]
  end
  subgraph gate["Approval gate"]
    SF["Step Functions
waitForTaskToken"]
    EXEC["post-approval executor"]
  end
  subgraph obs["Observability"]
    OTEL["OTEL traces to CloudWatch
GenAI observability"]
    LOG["invocation logs to S3"]
    BUD["Budgets + Cost
Anomaly Detection"]
  end

  EB --> SUP
  SLACK --> SUP
  SCHED --> COST
  SUP --> TRI
  SUP --> RUN
  SUP --> COST
  TRI --> MEM
  RUN --> MEM
  COST --> MEM
  SUP --> ID
  TRI --> BR
  RUN --> BR
  COST --> BR
  BR --> GR
  TRI --> KB
  RUN --> KB
  SUP --> GW
  GW --> T1
  GW --> T2
  GW --> T3
  GW --> T4
  T4 --> SF
  SF -- "context + Slack approval" --> SLACK
  SF -- approved --> EXEC
  BR --> OTEL
  GW --> LOG
  COST --> BUD

Τέσσερις agents Strands τρέχουν πάνω στο AgentCore Runtime πίσω από έναν supervisor: incident triage, εκτέλεση runbook, και βελτιστοποίηση κόστους. Το AgentCore Memory κρατά την κατάσταση session και μακροπρόθεσμη κατάσταση ώστε ο supervisor να μην ξαναεξηγεί το πλαίσιο σε έναν specialist σε κάθε hop, και το AgentCore Identity διαμεσολαβεί τα εξερχόμενα credentials ώστε κανένας κώδικας agent να μην κουβαλά ένα μακρόβιο μυστικό. Κάθε κλήση μοντέλου περνά από cross-region inference profiles για αξιοπιστία και περιθώριο burst, με τα Bedrock Guardrails συνδεδεμένα σε κάθε invocation και ένα Knowledge Base πάνω στο σώμα runbooks να υποστηρίζει τους agents triage και runbook. Το επίπεδο εργαλείων είναι εξ ολοκλήρου το AgentCore Gateway: Lambdas ελάχιστου προνομίου πίσω από MCP, τρεις από αυτές read-only και αναλαμβάνοντας τον ops-readonly σε ένα spoke, μία από αυτές, η ssm-execute, το μόνο εργαλείο που κάνει mutation, και δεν μπορεί να φτάσει απευθείας σε λογαριασμό spoke. Μπορεί μόνο να παραδώσει μια πρόταση στο Step Functions, το οποίο σταματά στο waitForTaskToken, δημοσιεύει το πλήρες πλαίσιο (διάγνωση, ακτίνα έκρηξης, ακριβές έγγραφο SSM και παραμέτρους) στο Slack, και συνεχίζει μόνο όταν ένας άνθρωπος εγκρίνει. Κάθε hop από το EventBridge μέχρι το Gateway κουβαλά OTEL tracing προς το CloudWatch generative AI observability, τα logs invocation του Bedrock καταλήγουν στο S3, και τα Budgets μαζί με το Cost Anomaly Detection παρακολουθούν τη δική τους δαπάνη της πλατφόρμας με ετικέτες κατανομής κόστους ανά agent.

Το read-only είναι η πρωταρχική εντολή

Κάθε agent σε αυτή την πλατφόρμα μπορεί να κοιτάξει οτιδήποτε σχετικό και να μην αλλάξει τίποτα, εκτός αν ένας άνθρωπος έχει ήδη πει ναι. Αυτή είναι η μία πρόταση στην οποία πρέπει να παραμείνει πιστή η υπόλοιπη σειρά. Εμφανίζεται ως τρεις ξεχωριστές, μη εντυπωσιακές αποφάσεις IAM αντί για έναν έξυπνο μηχανισμό: οι Lambdas εργαλείων αναλαμβάνουν έναν ρόλο read-only χτισμένο από managed policies της AWS με ρητές απαγορεύσεις στοιβαγμένες από πάνω· το μόνο εργαλείο που κάνει mutation δεν μπορεί να αναλάβει τίποτα σε λογαριασμό spoke απευθείας· και το μοναδικό μονοπάτι από «ο agent πρότεινε μια διόρθωση» σε «η διόρθωση εκτελέστηκε» περνά μέσα από μια κατάσταση αναμονής του Step Functions που μόνο ένα κλικ ανθρώπου στο Slack μπορεί να συνεχίσει.

Το read-only δεν είναι μια οδηγία prompt που λέει σε ένα μοντέλο να είναι προσεκτικό. Μοντέλα που τους ζητάνε ευγενικά εξακολουθούν περιστασιακά να μην είναι προσεκτικά. Το read-only εδώ είναι ένα όριο IAM που ένα παραβιασμένο prompt, μια hallucinated κλήση εργαλείου, ή ένα απλό bug δεν μπορούν να διασχίσουν, επειδή τα credentials για να το διασχίσουν δεν υπάρχουν πουθενά όπου να μπορεί να φτάσει ο agent.

Πώς μοιάζει το «έτοιμο»

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

• Ο διάμεσος χρόνος από την ειδοποίηση μέχρι μια εμπλουτισμένη περίληψη στο Slack (logs, dashboards, πιθανή αιτία) κάτω από 5 λεπτά, μειωμένος από τα σημερινά 25 έως 35 λεπτά χειρωνακτικής συλλογής.
• Μηδέν ενέργειες mutation εκτελούνται χωρίς μια έγκριση ανθρώπου καταγεγραμμένη από το Step Functions, επαληθευμένη έναντι του CloudTrail κάθε εβδομάδα.
• Η μηνιαία καθυστέρηση FinOps πέφτει από περίπου τρεις εβδομάδες σε αυθημερόν, μέσω της ημερήσιας σάρωσης κόστους που αναδεικνύει ανωμαλίες πριν κλείσει ο επόμενος κύκλος χρέωσης.
• Η απαρχαίωση των runbooks (σπασμένα ARNs, νεκρά console paths) πέφτει από περίπου ένα στα τρία σε κάτω από ένα στα είκοσι, εντοπισμένη συνεχώς αντί σε έναν ετήσιο έλεγχο.
• Μια τριμηνιαία game day απενεργοποιεί εντελώς το ops-tooling και επιβεβαιώνει ότι η ειδοποίηση και η χειρωνακτική εκτέλεση runbook εξακολουθούν να λειτουργούν ακριβώς όπως πριν αυτό υπάρξει, χωρίς να δημιουργείται καμία σιωπηλή εξάρτηση.
• Η διάγνωση incident-triage ταιριάζει με την τελική βασική αιτία αρκετά συχνά, μετρημένη έναντι ενός αριθμητικού ορίου που θα ορίσει το eval harness σε επόμενο μέρος, ώστε το on-call σταματά να την επαληθεύει ξανά με το χέρι πριν ενεργήσει βάσει αυτής.

Τρόποι αποτυχίας που πρέπει να προσέχεις από την πρώτη μέρα

Τρία πράγματα πρέπει να προσέξεις πριν αγγίξει κανείς το Terraform, γιατί το στήσιμο του σεναρίου είναι το λάθος σημείο για να τα ανακαλύψεις σε production. Αν ένα εργαλείο ανάγνωσης δεν μπορεί να φτάσει σε λογαριασμό spoke, είτε επειδή απορρίφθηκε η ανάληψη ρόλου είτε επειδή μια υπηρεσία είναι υποβαθμισμένη, ο agent πρέπει να το πει και να επιστρέψει σε άνθρωπο, όχι να μαντέψει: μια λάθος διάγνωση δηλωμένη με σιγουριά είναι χειρότερη από καμία διάγνωση. Αν η ίδια η πύλη έγκρισης κολλήσει, τόσο η κατάσταση αναμονής όσο και η γύρω state machine χρειάζονται ρητά timeouts, αλλιώς μια κολλημένη πρόταση γερνά σιωπηλά αντί να αποτυγχάνει με θόρυβο. Και αν το ops-tooling πέσει εντελώς, η πλατφόρμα πρέπει να υποβαθμιστεί ακριβώς στη σημερινή διαδικασία, κάτι που ισχύει μόνο αν τίποτα εκτός του ops-tooling δεν αρχίσει να εξαρτάται σιωπηλά από την ύπαρξή του.

Διάβασε επίσης

• Μέρος 2, Το θεμέλιο: Terraform πριν τα tokens, όπου η παραπάνω διάταξη λογαριασμών γίνεται πραγματικό HCL: IAM baseline, πρόσβαση σε μοντέλα Bedrock, και η απόφαση on-demand έναντι provisioned έναντι cross-region inference.
• AWS Multi-party Approval for Organizations στο ercan.cloud, το ίδιο μοτίβο «φράξε την επικίνδυνη ενέργεια πίσω από απαρτία ανθρώπων», από την πλευρά του ακατέργαστου AWS Organizations αντί από την πλευρά του agent.

Τα δύο παραπάνω διαγράμματα, καθώς και η διάταξη λογαριασμών και IAM που περιγράφουν, ζουν επίσης ως Markdown στο συνοδευτικό repository στο github.com/flightlesstux/agents-on-call, μαζί με το Terraform και το Python που χτίζει αυτή η σειρά μέρος-μέρος. Για την πλευρά βάσεων δεδομένων και υποδομής της λειτουργίας αυτού του είδους πλατφόρμας σε κλίμακα, οι σημειώσεις πεδίου είναι στο ercan.cloud, και ο κόμβος είναι στο ercanermis.com.