Τέσσερις agents υπάρχουν τώρα εκεί όπου το Μέρος 4 άφησε έναν: ένας supervisor, ένας runbook agent και ένας cost agent προστίθενται στο incident-triage, συντονισμένοι όχι με κλήσεις συναρτήσεων Python μέσα σε μία διεργασία αλλά μέσω του ίδιου του InvokeAgentRuntime API του AgentCore Runtime, επειδή και οι τέσσερις εξακολουθούν να αναπτύσσονται ως ξεχωριστοί, απομονωμένοι πόροι Runtime, η ίδια απομόνωση για την οποία το Μέρος 3 επέλεξε εξαρχής το AgentCore Runtime. Ένας ακόμα πόρος AWS τους δένει μεταξύ τους: ένα μοναδικό instance AgentCore Memory, κοινόχρηστο και από τους τέσσερις ανά actor ID, ώστε μια διάγνωση που γράφει το triage στις 3 τα ξημερώματα να παραμένει αναγνώσιμη από τον runbook agent στον οποίο την παραδίδει δευτερόλεπτα αργότερα, και από όποιον agent κοιτάξει ξανά τον επόμενο μήνα ένα περιστατικό με παρόμοιο σχήμα.

Το Μέρος 1 επέλεξε AgentCore συν Strands και σκιαγράφησε τέσσερις agents πίσω από έναν supervisor ως το σχήμα-στόχο. Το Μέρος 2 έχτισε το όριο λογαριασμού και τον διαχωρισμό ops-readonly/ops-mutate που κάθε agent έκτοτε επαναχρησιμοποιεί. Το Μέρος 3 παρέδωσε τον πρώτο agent, δύο εργαλεία συνδεδεμένα απευθείας στη δική του διεργασία. Το Μέρος 4 μετακίνησε εκείνα τα εργαλεία, συν ένα δεύτερο εργαλείο ανάγνωσης και το μοναδικό εργαλείο μετάβασης κατάστασης της πλατφόρμας, πίσω από το AgentCore Gateway: τέσσερα Lambdas που ένας MCP client μπορεί να ανακαλύψει αντί για τέσσερα πράγματα προς σύνδεση με το χέρι ανά agent. Αυτό το μέρος είναι εκεί όπου εκείνη η επένδυση αρχίζει να αποδίδει για περισσότερους από έναν καλούντες: οι agents runbook και cost συνδέονται και οι δύο στο ίδιο Gateway και κληρονομούν και τα τέσσερα εργαλεία χωρίς να ξαναπαράγουν από πουθενά τον χειρισμό cross-account credentials. Ο συνοδευτικός κώδικας βρίσκεται στο github.com/flightlesstux/agents-on-call, στα agents/supervisor/, agents/runbook/, agents/cost_optimizer/ και στις προσθήκες αυτού του μέρους στο terraform/10-agent-runtime/· κάθε απόσπασμα παρακάτω είναι αντιγραμμένο από αυτά τα αρχεία, όχι απλοποιημένο για το άρθρο.

Όταν ένας agent παύει να αρκεί

Ο triage agent του Μέρους 3 είχε ένα system prompt, δύο εργαλεία, μία δουλειά. Αυτό κράτησε μια χαρά μέχρι και τα τέσσερα εργαλεία του Μέρους 4, γιατί και τα τέσσερα εξυπηρετούσαν ακόμα εκείνη τη μία δουλειά: διάγνωση, ποτέ αποκατάσταση. Η πίεση που πραγματικά επιβάλλει έναν δεύτερο agent δεν είναι ο αριθμός εργαλείων, είναι ο αριθμός δουλειών. Ένας runbook agent (μετέτρεψε μια διάγνωση σε προτεινόμενη εκτέλεση SSM Automation) και ένας cost agent (διάβασε το Cost Explorer μία φορά τη μέρα, χωρίς κανείς να το ζητήσει, και πρότεινε rightsizing) δεν είναι παραλλαγές της δουλειάς του triage, είναι διαφορετικές δουλειές, με διαφορετικά χρονοδιαγράμματα και, αν στριμωχτούν σε ένα system prompt, με αντιφατικές οδηγίες να ζουν στο ίδιο context window. Το «δεν κάνεις ποτέ ενέργεια μετάβασης κατάστασης, δεν έχεις εργαλείο που να μπορεί» (ο κανόνας του ίδιου του triage, αμετάβλητος από το Μέρος 3) και το «πρότεινε μια κλήση ssm_execute όταν ένα ταιριαστό κομμάτι runbook τη στηρίζει» (η πραγματική δουλειά του runbook agent) δεν είναι προτάσεις που ένα prompt διατυπώνει καθαρά μαζί· ένας agent από τον οποίο ζητείται να κάνει και τα δύο παρασύρει την πειθαρχία της μιας δουλειάς προς την προθυμία της άλλης να δράσει, ή χάνει τη λεπτότητα της δεύτερης δουλειάς κάτω από την επιφυλακτικότητα της πρώτης. Ο διαχωρισμός της δουλειάς σε διεργασίες, όχι απλώς σε ενότητες του prompt, είναι αυτό που κρατά την πειθαρχία του triage αναγνώσιμη δύο μέρη αργότερα: το system prompt του δεν έχει αλλάξει ούτε γραμμή από το Μέρος 3.

Το φούσκωμα του context είναι η πιο αθόρυβη εκδοχή της ίδιας πίεσης. Ένας triage agent που κουβαλά επίσης τις ιδιαιτερότητες του Cost Explorer και τη συμπεριφορά ανάκτησης του corpus των runbooks ξοδεύει tokens του system prompt και βάρος tool schema σε δουλειές που δεν κάνει σε οποιαδήποτε δεδομένη κλήση, τις περισσότερες φορές. Τέσσερις agents, καθένας κρατώντας μόνο ό,τι χρειάζεται η δική του δουλειά, είναι απόφαση αποδοτικότητας tokens όσο και οργανωτική.

Agents ως εργαλεία, το σχήμα που ταιριάζει σε τέσσερα ξεχωριστά Runtimes

Το Strands Agents 1.0 παρέδωσε τέσσερα νέα multi-agent primitives συν υποστήριξη του πρωτοκόλλου Agent-to-Agent στην έκδοση παραγωγής του, και το «agents ως εργαλεία» έχει περισσότερα από ένα πραγματικά σχήματα στο SDK. Το να περάσεις ένα θυγατρικό instance Agent απευθείας στη λίστα tools=[...] ενός γονέα, ή να τυλίξεις ένα σε decorator που το εκθέτει με ένα tool spec, δουλεύουν και τα δύο καλά και απαιτούν και τα δύο το ίδιο πράγμα: ο sub-agent να ζει στην ίδια διεργασία Python με τον καλούντα του. Αυτό δεν είναι το σχήμα αυτής της πλατφόρμας. Οι triage, runbook και cost αναπτύσσονται καθένας ως δικός του πόρος aws_bedrockagentcore_agent_runtime, με ανεξάρτητη έκδοση, με ανεξάρτητο πεδίο IAM, καθένας στην απομόνωση session για την οποία το Μέρος 3 επέλεξε συγκεκριμένα το AgentCore Runtime. Το να καταρρεύσουν τρία Runtimes σε μία διεργασία για να χρησιμοποιηθεί η in-process συντόμευση θα αναιρούσε εκείνη την απομόνωση για μια συντακτική ευκολία.

ΣχήμαΠώς δουλεύειΤαιριάζει σε αυτή την πλατφόρμα;
tools=[agent_instance]Περνάς ένα αντικείμενο Agent του Strands απευθείας στη λίστα εργαλείων ενός γονέαΌχι: χρειάζεται τον sub-agent στην ίδια διεργασία, καταρρέοντας την απομόνωση τριών ξεχωριστών Runtimes σε μία
.as_tool()Τυλίγεις μια in-process κλήση agent σε decorator που εκθέτει ένα tool specΌχι, για τον ίδιο λόγο: παραμένει μία διεργασία, μία ακτίνα έκρηξης αν καταρρεύσει
@tool που καλεί InvokeAgentRuntimeΜια απλή συνάρτηση εργαλείου Strands που καλεί το ήδη αναπτυγμένο Runtime ενός άλλου agent μέσω δικτύουΝαι: ταιριάζει στο σχήμα των τεσσάρων ξεχωριστών Runtimes στο οποίο έχει ήδη δεσμευτεί το Terraform του Μέρους 3

Έτσι ο supervisor χρησιμοποιεί το τρίτο σχήμα: συναρτήσεις με decorator @tool που καλούν τη λειτουργία data-plane InvokeAgentRuntime του bedrock-agentcore έναντι του runtime ARN κάθε ειδικού. Το αντάλλαγμα είναι πραγματικό και αξίζει να ονομαστεί αντί να κρυφτεί: μια in-process κλήση είναι κλήση συνάρτησης, αυτό εδώ είναι ένα άλμα δικτύου με τη δική του καθυστέρηση και τον δικό του τρόπο να αποτύχει στα μισά. Πληρωμένο σκόπιμα, όχι κατά λάθος, για την απομόνωση στην οποία το Μέρος 3 είχε ήδη δεσμευτεί:

def _invoke_specialist(agent_runtime_arn: str, actor_id: str, prompt: str) -> str:
    """Invoke one specialist's AgentCore Runtime and return its text result.
    ...
    """
    response = _agentcore.invoke_agent_runtime(
        agentRuntimeArn=agent_runtime_arn,
        runtimeSessionId=_session_id,
        contentType="application/json",
        payload=json.dumps({"prompt": prompt, "session_id": _session_id}).encode("utf-8"),
    )
    if response["statusCode"] != 200:
        raise RuntimeError(f"{actor_id} runtime invocation failed with status {response['statusCode']}")

    body = json.loads(response["response"].read())
    if "error" in body:
        raise RuntimeError(f"{actor_id} returned an error: {body['error']}")
    return body["result"]


@tool
def ask_triage_agent(alarm_context: str) -> str:
    """Ask the incident-triage specialist to diagnose a firing alarm.
    ...
    """
    result = _invoke_specialist(TRIAGE_AGENT_RUNTIME_ARN, "incident-triage", alarm_context)
    record_incident_event("supervisor", _session_id, {"delegated_to": "incident-triage", "result": result})
    return result

Δύο λεπτομέρειες αξίζουν στάση. Πρώτον, η _invoke_specialist σηκώνει εξαίρεση σε status εκτός 200 ή σε σώμα σφάλματος αντί να επιστρέφει ένα string που διαβάζεται σαν κανονικό εύρημα: ένας supervisor που δεν μπορεί να ξεχωρίσει το «ο runbook δεν βρήκε τίποτα» από το «η κλήση του runbook απέτυχε» θα συνθέσει ψευδή βεβαιότητα σε ό,τι πει σε έναν άνθρωπο. Δεύτερον, το _session_id κόβεται μία φορά ανά κλήση του supervisor, όχι μία φορά ανά κλήση ειδικού, και περνά σε κάθε ειδικό αμετάβλητο: είναι αυτό που επιτρέπει στο AgentCore Runtime να ομαδοποιεί τα traces και των τριών ειδικών κάτω από ένα περιστατικό, και αυτό που επιτρέπει στην κοινόχρηστη μνήμη παρακάτω να ξεχωρίζει τα γεγονότα ενός περιστατικού από ενός άλλου.

Ο runbook agent: Knowledge Base πάνω σε SSM documents, προτείνει, δεν εκτελεί ποτέ

Ολόκληρη η δουλειά του runbook agent είναι να μετατρέπει μια διάγνωση σε υποψήφια αποκατάσταση, αντλημένη από πραγματικό έγγραφο, όχι εφευρημένη. Φτάνει εκεί με δύο πηγές εργαλείων: ένα νέο εργαλείο kb_retrieve πάνω σε ένα Bedrock Knowledge Base χτισμένο στο corpus των runbooks, και κάθε εργαλείο που ήδη ευρετηριάζει το Gateway, ανακαλυμμένο τη στιγμή της σύνδεσης αντί να δηλώνεται με το χέρι:

@tool
def kb_retrieve(query: str, max_results: int = 5) -> str:
    """Search the runbook Knowledge Base for playbook chunks relevant to query.
    ...
    """
    response = _bedrock_agent_runtime.retrieve(
        knowledgeBaseId=RUNBOOK_KNOWLEDGE_BASE_ID,
        retrievalQuery={"text": query},
        retrievalConfiguration={"vectorSearchConfiguration": {"numberOfResults": max_results}},
    )
    ...
    return json.dumps({"query": query, "chunks": chunks})


_gateway = connect_gateway_tools()

agent = Agent(
    model=model,
    system_prompt=SYSTEM_PROMPT,
    tools=[kb_retrieve, *_gateway.list_tools_sync()],
    name="runbook",
    ...
)

Η connect_gateway_tools() υπογράφει κάθε αίτημα προς το MCP endpoint του Gateway με τα credentials του execution role του ίδιου του runtime container, SigV4, σε αντιστοιχία με την επιλογή authorizer_type = "AWS_IAM" του Μέρους 4 στον ίδιο τον πόρο Gateway, και επιστρέφει όποια εργαλεία μπορεί να φτάσει εκείνος ο ρόλος IAM: cloudwatch-read, logs-read, cost-read και ssm-execute, τα ίδια ακριβώς τέσσερα που έχτισε το Μέρος 4, χωρίς να απαριθμούνται ή να αναφέρονται πουθενά στον δικό του κώδικα αυτού του agent. Το αν το μοντέλο θα καλέσει πράγματι το ssm-execute είναι απόφαση system prompt και IAM, όχι απόφαση χρόνου κώδικα. Και το ssm-execute δεν έχει αλλάξει από το Μέρος 4: εξακολουθεί να απαιτεί diagnosis και blast_radius σε κάθε κλήση, εξακολουθεί μόνο να ξεκινά τη ροή έγκρισης Step Functions, ποτέ μια ενέργεια σε λογαριασμό spoke απευθείας. Το system prompt του runbook agent το κάνει σκληρό κανόνα αντί για υπονοούμενο: μια κλήση ssm_execute αναφέρεται στον supervisor ως «στάλθηκε σε άνθρωπο», ποτέ ως «έγινε», όσο σίγουρο κι αν ακούγεται το κείμενο του ίδιου του μοντέλου.

Ο cost agent: μια προγραμματισμένη σάρωση προς την ίδια πύλη

Ο cost agent είναι ο ένας ειδικός που δεν τον ξυπνά τίποτα: το EventBridge Scheduler τον καλεί μία φορά τη μέρα ανά spoke, χωρίς κανένα alarm να το προκαλεί, με το ίδιο το χρονοδιάγραμμα ορισμένο εξ ολοκλήρου σε Terraform αντί να μένει ως ισχυρισμός σε ένα docstring:

resource "aws_scheduler_schedule" "cost_agent_daily" {
  name                = "${var.platform_name}-cost-agent-daily"
  description         = "Daily trigger for the cost agent's Cost Explorer sweep across configured spoke accounts."
  schedule_expression = "cron(0 6 * * ? *)"

  flexible_time_window {
    mode = "OFF"
  }

  target {
    arn      = "arn:aws:scheduler:::aws-sdk:bedrockagentcore:invokeAgentRuntime"
    role_arn = aws_iam_role.cost_scheduler.arn

    ...
  }
}

Διαβάζει μέσα από την ίδια σύνδεση Gateway με τον runbook (cost-read, συν cloudwatch-read και logs-read για να διασταυρώσει μια ανωμαλία δαπάνης με πραγματικό φορτίο πριν την επισημάνει), και όταν μια ενέργεια rightsizing φαίνεται δικαιολογημένη, προτείνει μέσα από το πανομοιότυπο μονοπάτι ssm-execute που χρησιμοποιεί ο runbook. Ένα pipeline έγκρισης, δύο προτείνοντες: ένας άνθρωπος που εξετάζει το Slack δεν θα έπρεπε να χρειάζεται να ξέρει ή να νοιάζεται αν μια εκκρεμής πρόταση προήλθε από διάγνωση περιστατικού ή από νυχτερινή σάρωση.

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

prior_episodes = retrieve_incident_context("cost", prompt)
if prior_episodes:
    prompt = (
        f"{prompt}\n\nNote: {len(prior_episodes)} related past cost proposal(s) "
        "exist in memory; check whether any were denied before re-proposing."
    )

AgentCore Memory: ένα κοινό περιστατικό, τέσσερις συγγραφείς

Το AgentCore Memory χρεώνει τα βραχυπρόθεσμα γεγονότα με 0,25 $ ανά 1.000 κλήσεις CreateEvent και τη μακροπρόθεσμη ανάκτηση με 0,50 $ ανά 1.000 κλήσεις RetrieveMemoryRecords, αρκετά φθηνά ώστε τέσσερις agents που γράφουν από ένα γεγονός ανά κλήση να κοστίζουν ένα σφάλμα στρογγυλοποίησης δίπλα στην τιμή tokens μίας κλήσης μοντέλου. Η στρατηγική που κάνει τη δουλειά εδώ είναι η EPISODIC, ένας από τους ενσωματωμένους τύπους της AWS: αποτυπώνει κάθε session ως δομημένο επεισόδιο (πλαίσιο, συλλογισμός, ενέργειες, αποτελέσματα) και τρέχει το δικό της βήμα αναστοχασμού πάνω στα επεισόδια για να εξαγάγει ευρύτερα μοτίβα, χωρίς αυτή η πλατφόρμα να χρειάζεται να κάνει prompt-engineer εκείνη την εξαγωγή μόνη της. Η υποστήριξη Terraform για τον τύπο EPISODIC στο aws_bedrockagentcore_memory_strategy προσγειώθηκε στις 29 Απριλίου 2026, σχεδόν δύο μήνες πριν από την ημερομηνία αυτού του ίδιου του μέρους:

resource "aws_bedrockagentcore_memory" "incident" {
  name                  = "${replace(var.platform_name, "-", "_")}_incident_memory"
  description           = "Shared short-term event stream and long-term episodic memory for one incident's supervisor, triage, runbook, and cost agents."
  event_expiry_duration = var.memory_event_expiry_days

  # memory_execution_role_arn deliberately omitted: per the fact table, it
  # is required only when a memory uses a CUSTOM strategy with a
  # model-processing override block (SEMANTIC_OVERRIDE,
  # USER_PREFERENCE_OVERRIDE, and so on). EPISODIC below is a built-in
  # type, not CUSTOM, so AWS runs its own reflection step without this
  # platform needing to grant or manage a role for it.
  tags = merge(var.tags, { Component = "memory" })
}

...

resource "aws_bedrockagentcore_memory_strategy" "episodic" {
  name       = "incident-episodes"
  memory_id  = aws_bedrockagentcore_memory.incident.id
  type       = "EPISODIC"
  namespaces = ["/incidents/{actorId}"]
}

Κάθε agent γράφει σε εκείνη τη μία μνήμη μέσω των ίδιων δύο συναρτήσεων, που είναι αυτό που κρατά τέσσερα ανεξάρτητα αναπτυγμένα Runtimes από το να αποκλίνουν στον τρόπο που διαβάζουν και γράφουν κοινή κατάσταση:

def record_incident_event(actor_id: str, session_id: str, event: dict) -> str | None:
    """Write one short-term event to the shared incident memory.
    ...
    """
    if not MEMORY_ID:
        return None

    response = _agentcore.create_event(
        memoryId=MEMORY_ID,
        actorId=actor_id,
        sessionId=session_id,
        eventTimestamp=time.time(),
        payload=[
            {
                "conversational": {
                    "content": {"text": json.dumps(event, default=str)},
                    "role": "ASSISTANT",
                }
            }
        ],
    )
    return response["event"]["eventId"]

Δύο πράγματα που σκόπιμα δεν κάνει. Επιστρέφει None αντί να σηκώσει εξαίρεση όταν το memory ID δεν έχει οριστεί, ώστε ένας agent υπό τοπική δοκιμή χωρίς προμηθευμένο πόρο μνήμης να υποβαθμίζεται σε «χωρίς κοινή μνήμη» αντί να αποτυγχάνει μια διάγνωση εξαιτίας μιας μεταβλητής περιβάλλοντος που λείπει. Και το actor_id είναι ένα string που περνά ο agent, όχι μια τιμή που αυτή η συνάρτηση επικυρώνει έναντι οποιουδήποτε πράγματος, επίτηδες: η προσθήκη ενός πέμπτου agent αργότερα δεν χρειάζεται καμία αλλαγή schema εδώ, μόνο έναν νέο actor που γράφει στο ίδιο σχήμα namespace.

Ειλικρινά: πότε το multi-agent είναι υπερβολή

Τέσσερα AgentCore Runtimes συν έναν πόρο μνήμης συν δικτύωση μεταξύ runtimes είναι πραγματική υποδομή για κάτι που μια μικρότερη ομάδα ops θα μπορούσε να τρέξει ως έναν agent με επτά εργαλεία και ένα μακρύτερο system prompt. Το AgentCore Runtime χρεώνει 0,0895 $ ανά vCPU-ώρα και 0,00945 $ ανά GB-ώρα με τον αδρανή χρόνο δωρεάν, οπότε τέσσερα μικρά runtimes δεν είναι ακριβά σε απόλυτους όρους, αλλά είναι τέσσερα πράγματα προς ανάπτυξη, τέσσερις ρόλοι IAM προς έλεγχο, και η καθυστέρηση και η επιφάνεια αποτυχίας ενός άλματος InvokeAgentRuntime που μια μονή διεργασία δεν έχει ποτέ. Η ειλικρινής αφορμή για διαχωρισμό δεν είναι το «αυτή η πλατφόρμα μεγάλωσε», είναι η ίδια με την οποία άνοιξε αυτό το μέρος: διακριτές δουλειές των οποίων οι οδηγίες αντιφάσκουν μεταξύ τους σε ένα system prompt, ή διακριτά χρονοδιαγράμματα (ένας agent που πυροδοτείται από alarm και μια απρόκλητη ημερήσια σάρωση) που δεν μοιράζονται έναν φυσικό ενιαίο βρόχο. Μια πλατφόρμα ops με μία δουλειά, triage και τίποτα άλλο, δεν δέχεται καμία από αυτές τις πιέσεις και πρέπει να μείνει ένας agent με καλά εργαλεία: καμία κλήση μεταξύ runtimes για να συλλογιστείς πάνω της, κανένας πόρος μνήμης για να τον κρατάς φρέσκο, κανένα module Terraform με for_each να συντονίζει τρεις ρόλους που θα μπορούσαν κάλλιστα να είναι ένας. Ο πρόωρος διαχωρισμός, πριν υπάρξει δεύτερη πραγματική δουλειά, αγοράζει απομόνωση που κανείς δεν χρειάστηκε ακόμα με κόστος ένα άλμα δικτύου που κανείς δεν ήθελε ακόμα.

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

Τέσσερις αξίζουν ονομασία πριν αυτό τρέξει ενάντια σε πραγματικό περιστατικό. Το triage δεν γράφει ακόμα στην κοινή μνήμη: ο κώδικάς του από το Μέρος 3 προηγείται του πόρου μνήμης αυτού του μέρους, και τίποτα σε αυτό το μέρος δεν τον αναπροσαρμόζει, που σημαίνει ότι από τα επεισόδια της στρατηγικής αναστοχασμού λείπει ο ένας agent που τρέχει πρώτος σχεδόν σε κάθε περιστατικό, ένα πραγματικό κενό, όχι μια παράλειψη προς ωραιοποίηση. Μια κλήση μεταξύ runtimes που αποτυγχάνει στα μισά είναι διαφορετική αποτυχία από μια in-process: η _invoke_specialist που σηκώνει εξαίρεση στη μέση ενός περιστατικού αφήνει ό,τι ο supervisor έχει ήδη καταγράψει στη μνήμη να κάθεται εκεί ως μερικό χρονολόγιο, χρήσιμο για έναν άνθρωπο που αναλαμβάνει το περιστατικό με το χέρι αλλά εύκολο να παρερμηνευτεί ως πλήρες αν κανείς δεν ελέγξει. Το βήμα αναστοχασμού της EPISODIC τρέχει ασύγχρονα πάνω σε κλεισμένα sessions, οπότε μια retrieve_incident_context που επιστρέφει άδεια λίστα σημαίνει είτε «γνήσια καινούργιο» είτε «ο αναστοχασμός δεν έχει τρέξει ακόμα», και ούτε αυτός ο κώδικας ούτε το prompt του agent μπορούν προς το παρόν να τα ξεχωρίσουν. Και οι πολιτικές IAM των νέων agents έχουν πραγματική εξάρτηση σειράς: η πολιτική ρόλου του supervisor αναφέρεται στα ARNs των ίδιων των runtimes runbook και cost, οπότε ένα Terraform apply που διακόπτεται ανάμεσα στην προμήθεια εκείνων των runtimes και στην προμήθεια του ρόλου του supervisor αφήνει το επόμενο plan να δείχνει την πολιτική του supervisor ως μη-εφαρμοσμένη-ακόμα, όχι μόνιμη κακορύθμιση, αλλά λόγο να αφήσεις ένα apply να τελειώσει αντί να εμπιστευτείς ένα μερικό.

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

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