Agents on Call, Parte 1. Lo Scenario: Perché un Team Ops Assume degli Agenti

Una azienda SaaS B2B di media grandezza, circa 50 ingegneri su una trentina di account AWS, riceve una chiamata on-call circa 40 volte a settimana, e la chiamata ottiene una risposta vera solo dopo 25-35 minuti passati a raccogliere manualmente il contesto: quale account, quale dashboard, quale runbook, e se quel runbook è ancora affidabile. Questo avviene prima che la diagnosi inizi, non al posto suo. Questa serie costruisce la soluzione: una piccola piattaforma di agenti AI che esegue quella prima passata in automatico, legge tutto ciò che gli è permesso leggere, non cambia nulla senza il via libera di un umano, e smette di essere utile nel momento esatto in cui smette di rispettare questa disciplina.

L'azienda, e cosa sta davvero pagando in lavoro ripetitivo

Chiamiamo l'azienda per quello che è: una SaaS B2B di media grandezza, circa 50 ingegneri, una trentina di account AWS distribuiti su una manciata di linee di prodotto, ciascuna con il proprio trio dev, staging e produzione. Nessuno ha deciso a tavolino di arrivare a 30 account. È successo nel modo ordinario, un team alla volta che chiedeva isolamento, finché AWS Organizations non ha finito per rispecchiare l'organigramma più dell'architettura.

Il lavoro ripetitivo non è drammatico. È cumulativo, e quattro numeri tratti da tre mesi di dati on-call, più un retro scomodo, ne chiariscono la forma:

• Circa 40 chiamate a settimana arrivano a chiunque sia di turno, distribuite in modo disomogeneo sui 30 account.
• 25-35 minuti di ogni chiamata vengono spesi ad assemblare il contesto prima ancora che la diagnosi inizi: l'account giusto, la dashboard giusta, il runbook giusto, e se quel runbook corrisponde ancora alla realtà.
• La revisione mensile FinOps arriva con circa tre settimane di ritardo rispetto alla spesa effettiva, quindi un autoscaling group mal configurato o un'istanza GPU inattiva brucia soldi per quasi un mese prima di comparire in un report che qualcuno legge.
• Un recente audit dei runbook ha trovato che circa uno su tre puntava a una risorsa, un ARN o un percorso della console che non esisteva più.

Nessuno di questi quattro punti è di per sé un'emergenza. Insieme rappresentano una tassa fissa sul team: circa 30-40 ore-ingegnere a settimana spese sulla parte meccanica delle operazioni, raccogliere contesto e riverificare istruzioni obsolete, pagate da persone assunte per costruire prodotto, non per fare da assemblatori umani di contesto.

Perché gli agenti, e perché ora

La risposta onesta al "perché ora" è che i pezzi esistono finalmente come servizi gestiti invece che come framework interni che qualcuno deve tenere sotto controllo. Bedrock offre un servizio gestito di orchestrazione agenti, Agents for Amazon Bedrock, dal raggiungimento della disponibilità generale nel novembre 2023, con controllo dell'orchestrazione e visibilità delle tracce di ragionamento migliorati. Ciò che è cambiato è il livello sopra di esso. Amazon Bedrock AgentCore è diventato generalmente disponibile il 13 ottobre 2025, in nove regioni, confezionando sette servizi componenti (Runtime, Memory, Identity, Gateway, Code Interpreter, Browser, Observability) che prima significavano costruire da zero un session store, un broker di credenziali e una pipeline di tracing. In parallelo, AWS ha reso open source lo Strands Agents SDK a maggio 2025 sotto licenza Apache 2.0 e ha rilasciato una versione 1.0 di produzione per Python il 21 maggio 2026, una settimana prima dell'inizio della timeline di questo post. L'infrastruttura gestita e il layer di orchestrazione open hanno superato entrambi una soglia di production-readiness negli stessi mesi. Questa è la finestra in cui questa piattaforma viene costruita.

Costruire contro comprare

Il team ha guardato prima all'acquisto, come doveva. Un prodotto AIOps o incident-copilot pronto all'uso avrebbe fatto risparmiare tempo e non avrebbe richiesto Terraform. Ha perso per tre ragioni specifiche di questa azienda, non degli agenti in generale.

• Il confine delle mutazioni non è negoziabile. Chiunque esegua una fix deve assumere un ruolo IAM strettamente delimitato nell'account interessato, con un passaggio di approvazione interno come cancello. Un prodotto SaaS ti chiede o di concedergli un accesso cross-account ampio, o di innestare a posteriori il proprio flusso di approvazione sul tuo. Possedere la piattaforma significa che il cancello di approvazione è nativo dal primo giorno, non integrato dopo.
• La conoscenza tribale di trenta account vive in thread Slack e nella testa degli ingegneri, non in un formato che una pipeline di ingestion di un vendor capisca. Una Bedrock Knowledge Base costruita sul corpus di runbook esistente, con il team che controlla direttamente chunking e qualità del retrieval, è più gestibile che esportare quella conoscenza a terzi sperando che il loro retrieval sia abbastanza buono.
• L'azienda gestisce già AWS a questa scala. Il Terraform, la CI, la rotazione on-call, la struttura degli account, tutto esiste già oggi. Il costo marginale di costruire su primitive native AWS è più basso del costo di una seconda relazione con un vendor, una seconda voce di fatturazione e una seconda revisione di sicurezza.

La controargomentazione è reale: comprare è più veloce, e la velocità ha valore quando il lavoro ripetitivo si accumula settimana dopo settimana. La risposta del team è stata delimitare strettamente lo scope della build (quattro agenti, un solo pattern di approvazione, inferenza on-demand per iniziare, la matematica del dimensionamento arriva in una parte successiva) invece di trattarla come il progetto infinito di un platform team. Il codice di accompagnamento per l'intera serie vive su github.com/flightlesstux/agents-on-call; questo post è dove inizia il suo docs/architecture.md.

La scelta dello stack: tre modi di far girare un agente su Bedrock

Una volta deciso di costruire, la decisione successiva è stata su quale livello costruire. Esistevano tre opzioni reali, e il trade-off non è affatto semplice come "usa la cosa più nuova":

Il team ha scelto AgentCore più Strands. I pezzi gestiti che non voleva possedere (isolamento delle sessioni, brokeraggio delle credenziali, un gateway cross-account) sono arrivati abbinati a un layer di orchestrazione che poteva leggere e debuggare, invece che uno da fare reverse engineering da una console. AgentCore Runtime, alla disponibilità generale, dà a ogni sessione agente isolamento completo e una finestra di esecuzione di otto ore, con supporto al protocollo Agent2Agent nel caso gli agenti di questa piattaforma debbano mai parlare con agenti esterni. La CLI @aws/agentcore, rilasciata il 22 aprile 2026, ha aggiunto un flusso create, dev, deploy, invoke, logs e traces che supporta Strands direttamente (anche LangGraph, LangChain, Google ADK, OpenAI Agents, o bring-your-own), il che ha contato per l'onboarding: nessuno ha dovuto imparare uno strumento di deploy completamente nuovo a metà progetto.

Bedrock Agents classico è rimasto genuinamente interessante di suo: due anni e mezzo di track record in produzione, meno codice custom da possedere, e un modello mentale più semplice quando un action group è tutto ciò che serve. Ha perso qui perché quattro agenti che condividono un pattern supervisor attraverso un confine IAM multi-account rigido richiedevano più controllo sul loop di quanto gli action group espongano. Il fai-da-te sulla Converse API grezza è stato scartato per la ragione opposta: scrivere da zero un session store, un broker di credenziali e una pipeline di tracing, per qualcosa che AWS già spedisce come AgentCore Runtime, Memory, Identity e Observability, avrebbe speso i primi due mesi del progetto a reinventare infrastruttura invece che a scrivere agenti.

Architettura target: hub-and-spoke su tutta l'organizzazione

La piattaforma è multi-account, hub-and-spoke, e deliberatamente additiva. Se va giù, l'organizzazione degrada esattamente allo status quo: gli umani vengono chiamati come sempre. Non sta mai nel percorso critico degli alert.

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

Ogni account workload espone esattamente due ruoli verso ops-tooling: ops-readonly, assumibile da ogni tool Lambda, costruito su policy gestite AWS di sola lettura con deny espliciti stratificati sopra; e ops-mutate, assumibile da esattamente una Lambda, quella che gira dopo che un umano approva un'azione proposta, delimitata a un allowlist di specifici documenti SSM Automation. Nessun agente, nessun'altra Lambda, nessun percorso di codice oltre quell'unico executor post-approvazione può mai assumere ops-mutate. Quella separazione, non un'istruzione nel prompt, è ciò che rende il sola-lettura il default: è imposta da IAM, non chiesta gentilmente a un modello.

Dentro ops-tooling

Zoom sull'unico account in cui vive il resto di questa serie:

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

Quattro agenti Strands girano su AgentCore Runtime dietro un supervisor: incident triage, esecuzione runbook e cost optimization. AgentCore Memory tiene lo stato di sessione e a lungo termine così il supervisor non deve rispiegare il contesto a uno specialista a ogni hop, e AgentCore Identity intermedia le credenziali in uscita così nessun codice di agente porta con sé un segreto a lunga vita. Ogni chiamata al modello passa attraverso inference profile cross-region per affidabilità e margine di burst, con Bedrock Guardrails collegati a ogni invocazione e una Knowledge Base sul corpus di runbook a supporto degli agenti triage e runbook. Il layer di tool è interamente AgentCore Gateway: Lambda a privilegio minimo dietro MCP, tre di sola lettura che assumono ops-readonly in uno spoke, una, ssm-execute, l'unico tool mutante, che non può raggiungere un account spoke direttamente. Può solo passare una proposta a Step Functions, che si mette in pausa su waitForTaskToken, pubblica il contesto completo (diagnosi, raggio d'impatto, documento SSM esatto e parametri) su Slack, e riprende solo quando un umano approva. Ogni hop da EventBridge a Gateway porta tracing OTEL verso CloudWatch generative AI observability, i log di invocazione Bedrock finiscono su S3, e Budgets più Cost Anomaly Detection sorvegliano la spesa della piattaforma stessa con tag di allocazione costi per agente.

Sola lettura è la direttiva prima

Ogni agente su questa piattaforma può guardare qualsiasi cosa rilevante e non cambiare nulla, a meno che un umano non abbia già detto sì. Questa è l'unica frase a cui il resto della serie deve rimanere fedele. Si traduce in tre decisioni IAM separate e per nulla appariscenti, non in un unico meccanismo elegante: le Lambda tool assumono un ruolo di sola lettura costruito su policy gestite AWS con deny espliciti stratificati sopra; l'unico tool mutante non può assumere nulla in un account spoke direttamente; e l'unico percorso da "l'agente ha proposto una fix" a "la fix è stata eseguita" passa attraverso uno stato di attesa di Step Functions che solo un click umano su Slack può far riprendere.

Sola lettura non è un'istruzione nel prompt che dice a un modello di stare attento. I modelli a cui viene chiesto gentilmente sono comunque, a volte, non abbastanza attenti. Sola lettura, qui, è un confine IAM che un prompt compromesso, una chiamata a tool allucinata o un semplice bug non possono attraversare, perché le credenziali per attraversarlo non esistono da nessuna parte che l'agente possa raggiungere.

Come si presenta il successo

Il finale di questa serie torna a questi numeri. Sono quelli che l'inventario del lavoro ripetitivo sopra ha impostato, resi misurabili:

• Tempo mediano dalla chiamata a un riepilogo arricchito su Slack (log, dashboard, causa probabile) sotto i 5 minuti, giù dagli attuali 25-35 minuti di raccolta manuale.
• Zero azioni mutanti vengono eseguite senza un'approvazione umana registrata da Step Functions, verificata contro CloudTrail settimanalmente.
• Il ritardo mensile FinOps scende da circa tre settimane a stesso giorno, tramite il daily cost sweep che fa emergere le anomalie prima della chiusura del ciclo di fatturazione successivo.
• L'obsolescenza dei runbook (ARN rotti, percorsi console morti) scende da circa uno su tre a meno di uno su venti, catturata in continuo invece che a un audit annuale.
• La diagnosi dell'incident-triage combacia con la causa radice effettiva abbastanza spesso, misurata contro una soglia numerica che l'eval harness definirà in una parte successiva, da far sì che l'on-call smetta di riverificarla a mano prima di agire.
• Un game day trimestrale disabilita ops-tooling interamente e conferma che paging ed esecuzione manuale dei runbook funzionano esattamente come prima che esistesse, senza dipendenze silenziose create nel frattempo.

Modalità di fallimento da tenere d'occhio fin dal primo giorno

Tre cose da osservare prima che chiunque tocchi Terraform, perché la fase di definizione dello scenario è il posto sbagliato per scoprirle in produzione. Se un tool di lettura non riesce a raggiungere un account spoke, che sia un'assunzione di ruolo negata o un servizio degradato, l'agente deve dirlo e restituire il controllo a un umano, non tirare a indovinare: una diagnosi sbagliata affermata con sicurezza è peggio di nessuna diagnosi. Se il cancello di approvazione stesso si blocca, sia lo stato di attesa sia la state machine circostante hanno bisogno di timeout espliciti, o una proposta bloccata invecchia in silenzio invece di fallire rumorosamente. E se ops-tooling è completamente giù, la piattaforma deve degradare esattamente al processo di oggi, il che regge solo se nulla al di fuori di ops-tooling inizia a dipendere silenziosamente dalla sua esistenza.

Leggi questo dopo

• Parte 2, Le Fondamenta: Terraform Prima dei Token, dove il layout degli account sopra diventa vero HCL: baseline IAM, accesso ai modelli Bedrock, e la scelta tra inferenza on-demand, provisioned e cross-region.
• AWS Multi-party Approval for Organizations su ercan.cloud, lo stesso pattern "blocca l'azione rischiosa dietro un quorum di umani", visto dal lato AWS Organizations puro invece che dal lato agente.

I due diagrammi sopra, e il layout di account e IAM che descrivono, vivono anche come Markdown nel repository di accompagnamento su github.com/flightlesstux/agents-on-call, insieme al Terraform e al Python che questa serie costruisce parte per parte. Per il lato database e infrastruttura di come far girare questo tipo di piattaforma su scala, gli appunti tecnici sono su ercan.cloud, e l'hub è su ercanermis.com.