↓Salta al contenuto principale

SCH: una sandbox economica per Coding Agents nel tuo account AWS

·22 minuti
Software Development Artificial Intelligence GenAI Agents Coding AWS Serverless
Indice dei contenuti

Intro #

Un venerdì mattina ho chiuso il coperchio del laptop mentre un coding agent continuava a lavorare in un container leggero nel cloud. Quando l’ho riaperto qualche ora dopo, il branch era pronto da rivedere, il runtime era già sparito e il costo aggiuntivo del solo compute remoto era di pochi centesimi. L’inferenza del modello, che resta una voce separata, non è inclusa in quel numero.

Per arrivarci sono stato costretto a rispondere a due domande:

  1. devo veramente tenere acceso il mio PC, o una macchina remota, per un loop di otto ore?
  2. posso lasciare lavorare un agent senza presidio senza costruirmi anche un sistema di sandboxing?

Questo post è la mia risposta: SCH, un coding harness serverless basato su AWS AgentCore.

Negli ultimi due anni si sono accumulate parecchie etichette con il suffisso “engineering”. Il context engineering ha spostato l’attenzione dal singolo prompt alle informazioni disponibili al passo successivo. Il Ralph Wiggum loop di Geoffrey Huntley, letteralmente while :; do cat PROMPT.md | claude-code; done, ha mostrato quanto si possa ottenere con un loop bash, un contesto nuovo a ogni iterazione e lo stato salvato su disco. Da lì sono arrivati loop, graph e harness engineering. Le etichette cambiano in fretta; per costruire SCH mi sono serviti soprattutto tre concetti:

  • Stato. Dove vive il lavoro quando la context window non c’è più: file, documenti di piano, cronologia git e checkpoint. Ogni tecnica di loop deve esternalizzare abbastanza stato da permettere all’iterazione successiva di ripartire.
  • Harness. Tutto ciò che sta intorno alla chiamata al modello: tool, hook, permessi, verifiche e il loop esterno che decide se “finito” è davvero finito. In prima approssimazione e semplificando molto, potremmo dire che “Agent” = “modello” + “harness”.
  • Runtime. La macchina su cui gira l’harness: filesystem, rete, credenziali e durata. Molto spesso è il laptop dello sviluppatore, con tutti i limiti che ne conseguono.

I modelli più recenti e il lavoro su questi tre elementi hanno cambiato anche l’unità di lavoro. Un task può proseguire senza presidio per ore e, attraverso più sessioni e checkpoint, anche per giorni. Questo crea due problemi pratici.

  1. Qualcuno deve tenere la macchina accesa. Un loop di otto ore significa otto ore di laptop acceso, oppure un server remoto che devo noleggiare, aggiornare e ricordarmi di spegnere.
  2. I loop lunghi incentivano lo YOLO mode. Il lavoro non presidiato si interrompe appena l’harness chiede un’autorizzazione. Con i permission gate attivi, è facile ritrovare l’agent fermo dopo dodici minuti in attesa di un “ok, procedi”. Molti finiscono quindi per usare opzioni come --dangerously-skip-permissions, --auto o --yolo.

Una sessione lunga ha più occasioni di prendere una piega inattesa. Se gira in auto-approvazione sul laptop, la stessa macchina che tiene vivo il loop contiene spesso chiavi SSH, credenziali cloud e dati personali. Il problema cresce appena si passa da una sessione a tre, su branch e task diversi: il laptop diventa un host condiviso da più agent con ampi margini di azione.

L’isolamento riduce il raggio d’azione di un errore, ma funziona soltanto se rete e permessi sono calibrati sul lavoro da eseguire. Una sandbox troppo stretta blocca l’agent al primo comando negato; una troppo permissiva sposta soltanto il problema.

Nelle scorse settimane ho cercato un setup che mi permettesse di isolare il runtime, eseguire task asincroni e “detached” e che funzionasse almeno con OpenCode e Claude Code. Volevo anche evitare server da amministrare e regole di sandbox da mantenere a mano.

Dato che lavoro molto su AWS, avevo già usato Amazon Bedrock AgentCore Runtime. L’analogia più immediata è una Lambda progettata per ospitare agent AI: runtime serverless, pagamento a consumo e sessioni isolate. Quando interviene l’idle timeout, il runtime sparisce e il compute torna a zero. Più avanti mostro i numeri raccolti in circa dieci giorni di utilizzo non continuativo.

Da qui è nato SCH - Serverless Coding Harness, ora pubblico su c-daniele/sch. Quando ne ho bisogno, AgentCore avvia un harness remoto raggiungibile dal terminale. Il runtime esegue il lavoro e poi termina; SCH salva lo stato e riporta le modifiche nella working copy locale o in un branch separato.

Il principio architetturale è che la durabilità appartenga ai checkpoint e non al runtime. Se repository, sessioni dell’agent e cronologia git possono essere ripristinati, la microVM non ha alcun motivo di restare accesa. SCH è ancora un proof of concept, conserva alcune decisioni iniziali e oggi gira soltanto su AWS. I limiti sono discussi più avanti.

Rispetto a Claude Code sul web, Codex cloud o al coding agent di Copilot, SCH richiede più setup. In cambio, repository, sessioni, checkpoint e inferenza restano nel mio account AWS, sotto policy IAM definite da me, senza legarmi a un solo harness o provider.

Cosa cambia nel mio flusso di lavoro #

SCH combina una CLI locale con un’immagine ARM che esegue OpenCode, Claude Code o Pi dentro una microVM AgentCore. Il workspace viene salvato su S3, le modifiche tornano attraverso Git e il runtime viene eliminato quando non serve più.

FunzionalitàCosa mi permette di fare
Handoff della sessioneIniziare il lavoro in locale e continuarlo nel cloud senza ricostruire il contesto
Task detachedSpegnere il laptop senza interrompere l’esecuzione
Stato e checkpoint fuori dal runtimeControllare un task e riprenderlo anche dopo che la microVM è stata eliminata
Supervisione da TelegramRicevere aggiornamenti, approvare un tool o inviare un follow-up lontano dal terminale
Un workspace per branchEseguire più task in parallelo senza condividere uno stato scrivibile
Immagine e policy centralizzateUsare un ambiente ripetibile con harness, tool, modelli e permessi definiti a monte
flowchart TB D["Dispatch: sch run / sch task"] --> P["Provision: microVM on demand"] P --> W["Work: one harness, OpenCode / Claude / Pi"] W --> C["Checkpoint: periodic + terminal, to S3"] C --> S["Supervise: sch status / dashboard / Telegram"] S --> G["Deliver: sch fetch / sync / merge"] G --> E["Evaporate: terminate after idle timeout"] E -.->|next command| P

Tre casi d’uso con SCH: handoff, workbench e batch #

I comandi seguenti assumono che SCH sia già stato distribuito. Il quickstart del README copre prerequisiti e deploy iniziale.

1. Brainstorming in locale, handoff, supervisione dal telefono #

È la modalità che uso più spesso per il lavoro non banale. Faccio brainstorming con OpenCode sul laptop finché non sono chiari obiettivi, file da modificare, test e definition of done. Quando il contesto è pronto e lo stato locale è compatibile con l’avvio del task, invio l’intera conversazione a un workspace remoto e lascio che l’agent prosegua lì:

# Export the local OpenCode conversation, seed a branch from local HEAD,
# import the conversation remotely and start the headless task (implies --continue):
sch task my-project --handoff --branch change/plan-a \
  "implement what we agreed, run the tests, fix what breaks"
#> a1b2c3...          # returns immediately; laptop can go offline

# Any time later - reads S3, does not wake the microVM:
sch status my-project
#> state        : succeeded
#> continuation : resumed prior session
#> checkpoint   : confirmed

# The branch lands locally, fast-forward only; review at your pace:
sch fetch my-project

Da qui in avanti il laptop è opzionale. Ogni workspace ha un topic in un gruppo Telegram e un prefisso [workspace] sui messaggi. Ricevo le milestone, gli aggiornamenti della todo list, un digest dei tool, un avviso se l’heartbeat non risponde e infine l’esito del task con lo stato del checkpoint.

I task headless girano con auto-approvazione per scelta progettuale. Per le sessioni interattive esiste però una modalità intermedia detached: dopo aver avviato una sessione, la lascio in esecuzione con Ctrl+] e, quando l’agent chiede un permesso, ricevo sul telefono i pulsanti Approve/Deny. La risposta torna all’hook dell’harness. Se non rispondo entro dieci minuti (SCH_APPROVAL_TIMEOUT_S), SCH torna a far valere la policy configurata nell’harness. Il testo libero scritto nel topic diventa invece un prompt di follow-up tramite task --continue. Posso quindi digitare dal telefono “adesso aggiorna anche il README” e lasciare che l’harness continui.

2. Un banco di lavoro AWS isolato #

Un altro caso d’uso è quello di uno sviluppatore che lavora soprattutto con servizi AWS. Associando una policy adeguata al ruolo IAM dell’AgentCore Runtime, l’harness remoto può leggere un log group di CloudWatch, verificare una policy IAM, prototipare una Lambda o accedere a una tabella DynamoDB senza ereditare le credenziali della workstation.

sch run aws-lab       # fresh remote workspace, straight into the OpenCode TUI
sch web aws-lab       # same backend, in a browser tab
sch acp aws-lab       # same backend, from Zed over ACP

L’immagine contiene AWS CLI, i server MCP per AWS e la sua documentazione, oltre agli strumenti di sviluppo standard. L’inferenza Bedrock usa lo stesso execution role. Il ruolo predefinito combina ReadOnlyAccess e invocazione di Bedrock: è pratico per un POC, ma troppo ampio per dati di produzione e dovrebbe essere ristretto per workspace. Terminata la sessione, la microVM viene distrutta.

3. Un backlog di task su più harness e provider #

Qui parto da un backlog di task che hanno già specifiche, test e condizioni di completamento. Posso eseguirli senza presidio, ciascuno sul proprio branch e anche con coding agent diversi:

sch task svc-a --branch change/a --harness opencode "implement change A per docs/specs/a.md"
sch task svc-b --branch change/b --harness claude   "implement change B per docs/specs/b.md"
sch task svc-c --branch change/c --harness pi --model <bedrock-model-id> "port module C as planned"

sch dashboard         # every workspace on one screen: task state, heartbeat age, checkpoint
sch fetch svc-a && sch fetch svc-b && sch fetch svc-c

L’harness viene associato al workspace al momento della creazione. Il provider predefinito è Bedrock attraverso l’execution role, ma posso configurarne altri senza inserire le chiavi nell’immagine o nei checkpoint. Ogni sessione parallela vive sul proprio branch e sch fetch accetta soltanto un fast-forward. Gli eventuali conflitti emergono durante il git merge locale.

Run vs Task #

I comandi interattivi e quelli headless offrono garanzie diverse.

ModalitàScopoGaranzia
run / shell / web / attach / acpInterattiva, human-in-the-loopCheckpoint best-effort (~60 s). Scollegarsi non significa che il turno si è completato in modo durevole.
taskLavoro autonomo affidabileHeartbeat, esito terminale, timeout imposto, checkpoint forzato. checkpoint: confirmed significa che file e cronologia sono durevoli.
status / dashboardOsservare un workspace / tuttiLetture offline-first da S3. Non svegliano una microVM, salvo una richiesta esplicita con --live o dalla dashboard.

Di solito, uso la prima famiglia per fare brainstorming ed esplorare le possibili soluzioni. Quando arrivo a definire un task o un set di task sufficientemente complessi, esco dalla sessione e procedo con il comando task, in modo da potermi dedicare ad altro e potenzialmente spegnere il pc. La mappa completa dei comandi è nel README.

Perché AgentCore si adatta a questo flusso #

SCH si appoggia a quattro proprietà di AgentCore Runtime.

Isolamento per sessione. AgentCore esegue ogni sessione in una microVM Firecracker dedicata, con kernel, CPU, memoria e filesystem propri. Quando la sessione termina, la microVM viene distrutta e la memoria sanificata. Un coding harness ottiene così una macchina usa-e-getta che parte da un’immagine nota e non condivide lo stato con altre sessioni.

Permessi tramite IAM. Dentro la VM, CLI, SDK e server MCP ricevono credenziali temporanee corrispondenti all’execution role del runtime. Posso concedere l’invocazione di Bedrock, la lettura di alcune API AWS e la scrittura su uno specifico prefisso S3 senza copiare le chiavi del laptop. La microVM non rende sicuro un ruolo sovradimensionato: il confine effettivo dipende anche dalle policy IAM e dalla configurazione di rete.

Ciclo di vita gestito. AgentCore termina le sessioni inattive. L’idleRuntimeSessionTimeout predefinito è di 15 minuti e può essere ridotto fino a 60 secondi; maxLifetime impone invece un limite massimo di otto ore. Una sessione occupata risponde HealthyBusy all’health check, evitando che il timer interrompa un agent mentre lavora. Il limite delle otto ore obbliga SCH a prevedere checkpoint e ripartenze.

Risorse e avvio compatibili con un harness. Ogni sessione dispone di 2 vCPU e 8 GB di memoria; l’immagine deve essere linux/arm64 e non può superare 2 GB. È sufficiente per i coding harness e le test suite che uso abitualmente, mentre una build molto pesante richiede un runtime diverso. Nelle mie misurazioni, un workspace cold è pronto in pochi secondi, compresi il restore da S3 e il bootstrap dell’harness.

La CPU viene fatturata soltanto quando lavora, mentre la memoria continua a esserlo finché la sessione è viva. È un modello adatto a un processo che passa molto tempo ad aspettare l’LLM, ma non significa che l’attesa sia completamente gratuita. I dati reali sono nella sezione sui costi.

Come SCH separa runtime e stato #

L’architettura è divisa in tre livelli:

  • Operator. La CLI sch gira su macOS, Linux e Windows e delega le chiamate AWS alla CLI aws, mantenendo la compatibilità con i profili AWS e i sistemi di autenticazione già configurati sulla workstation, inclusi SSO e provider di credenziali esterni.
  • Runtime. Ogni workspace esegue un solo harness in una microVM linux/arm64. Uno shim Python gestisce task headless, readiness e checkpoint; l’immagine versionata contiene OpenCode, Claude Code, Pi e gli strumenti di sviluppo.
  • Durability. SCH usa due livelli diversi. L1, il session storage di AgentCore, rende rapido stop e resume, ma si azzera quando cambia la versione del runtime e scade dopo 14 giorni di inattività. L2 utilizza un bucket S3 versionato, sopravvive anche alla cancellazione del runtime. Se L1 è vuoto, lo shim scarica e valida il checkpoint L2 prima di dichiarare pronto il workspace. Un manifest illeggibile blocca il restore, evitando di inizializzare un workspace vuoto sopra dati esistenti.

Il ciclo di vita di una sessione è questo: sch shell → invocazione SigV4 → avvio della microVM → restore L2 → bootstrap dell’harness → lavoro → checkpoint da L1 a L2 su stop o idle. Il comando successivo può ripartire da L2 su una nuova microVM.

Modelli e provider #

Ogni harness nell’immagine è preconfigurato per Amazon Bedrock attraverso l’execution role, quindi il caso d’uso predefinito non richiede chiavi di provider esterni.

Per usare altri provider, SCH inoltra al runtime soltanto una lista esplicita di variabili definite in ~/.sch/env. Lo shim le conserva in un’area temporanea esclusa dai checkpoint: le chiavi raggiungono l’harness, ma non finiscono nell’immagine o in S3. Lo stesso meccanismo può inoltrare GITHUB_TOKEN quando il workspace deve interagire direttamente con GitHub.

Perché OpenCode è il default #

I tre harness condividono la gestione di base dello stato, ma SCH è nato attorno a OpenCode e alcune funzionalità ne riflettono l’architettura. Lo stesso backend può essere raggiunto da una TUI locale con sch attach, dal browser con sch web o da un editor via ACP con sch acp. Claude Code funziona con run, task e ACP tramite un adapter. Pi è adatto soprattutto ai task headless e, al momento, non supporta in SCH approvazioni remote, interfacce alternative e handoff.

Task headless, come funziona #

L’invio restituisce un task_id in meno di un secondo e il client chiude la connessione. Lo shim avvia l’harness in modalità headless e segnala ad AgentCore che la sessione è occupata, così l’idle timer non la interrompe mentre lavora. Il timeout applicativo di sette ore resta sotto il limite di AgentCore e lascia allo shim il tempo di registrare l’esito e completare il checkpoint. L’opzione --model cambia il modello per una sola invocazione e viene registrata nello status.

Spostare il codice: sync per esplorare, git per delegare #

Per le sessioni interattive uso la sincronizzazione dei file; per i task autonomi è preferibile usare la modalità git-native.

  • --sync . sincronizza i file tra locale e remoto, mantenendo .git escluso per impostazione predefinita. Uso questa modalità durante il brainstorming con l’agent.
  • --branch <name> inizializza il workspace dall’HEAD locale e crea un branch remoto. Alla fine del lavoro, sch fetch reimporta le modifiche soltanto in fast-forward. In questo modo le sessioni parallele lavorano su branch indipendenti e gli eventuali conflitti emergono durante il git merge locale, dove mantengo il controllo della decisione.

Le credenziali git della workstation non vengono copiate in nessuna delle due modalità. I bundle viaggiano sul file channel del tunnel e l’agente remoto non esegue push, salvo il percorso opzionale configurato esplicitamente con GITHUB_TOKEN. In origine non avevo previsto alcun accesso diretto a GitHub. Questo però impediva di interagire con GitHub Actions e con altre pipeline remote. Per questo l’accesso è rimasto opzionale: chi ne ha bisogno può fornire esplicitamente GITHUB_TOKEN; negli altri casi il runtime continua a lavorare soltanto con i bundle Git.

Quanto sono costati circa dieci giorni di utilizzo non continuativo #

Avevo iniziato a provare SCH già all’inizio di agosto, ma fino al 28 agosto l’utilizzo era stato troppo sporadico per rappresentare il mio flusso abituale. Ho quindi ristretto l’analisi al periodo dal 29 agosto al 9 settembre 2026: dodici giorni di calendario, con attività effettiva in nove giornate.

AgentCore non pubblica una voce equivalente ai “minuti usati”, quindi ho ricostruito il consumo da CloudWatch, nel namespace AWS/Bedrock-AgentCore di eu-west-1. Ho usato ActiveSessionCount per i minuti di wall-clock, CPUUsed-vCPUHours e MemoryUsed-GBHours per le quantità fatturabili. I dati provengono da query GetMetricData giornaliere e sono stati estratti il 12 settembre, quindi tutti i giorni inclusi sono completi.

I prezzi usati nel calcolo sono $0.0895 per vCPU-hour**, applicati soltanto alla CPU effettivamente utilizzata, e **$0.00945 per GB-hour di memoria. La memoria viene fatturata ogni secondo in base al massimo consumo raggiunto dalla sessione fino a quel momento, con un minimo fatturabile di 128 MB. Se il processo raggiunge 7 GB e poi libera memoria, il valore fatturabile resta 7 GB fino alla terminazione della sessione.

Quantità (29 ago – 9 set, 12 giorni di calendario, singolo dev)Valore
Sessioni86
Minuti con ≥1 microVM attiva1,856 (30.9 h)
Session-minuti (overlap conteggiati)2,251 (37.5 session-hours)
Picco di sessioni concorrenti4
Durata media di sessione~26 min
CPU attiva8.57 vCPU-h (0.23 vCPU medi per sessione in esecuzione; 0.39 nel giorno più intenso lato CPU)
Memoria284 GB-h (footprint medio ~7.6 GB)
VoceImporto
CPU (8.57 × $0.0895)$0.77
Memoria (284 × $0.00945)$2.68
Totale del periodo$3.45
Per session-hour~$0.092
Per sessione~$0.040
Giorno più intenso (6 set: 22 sessioni, 7.7 h con una microVM attiva, 9.6 session-hours)$0.92

Questi dati mi hanno fatto rivedere le priorità di ottimizzazione di SCH:

  1. La memoria è ~78% del costo, la CPU ~22%. Un coding agent passa la maggior parte del tempo ad aspettare il modello. L’attesa è gratis sulla CPU, ma la memoria scatta ogni secondo in cui la sessione è viva.
  2. L’idle è la leva principale. SCH ferma una sessione dopo 15 minuti di inattività, configurabili da 60 secondi a 8 ore. Con circa 7.5 GB di memoria, la coda di 15 minuti costa circa $0.018 per ogni sessione terminata dal timeout; sch stop la evita. Ha quindi più senso ridurre idle timeout e footprint dell’immagine che ottimizzare la CPU.

Ho confrontato questi dati con una t4g.large, la taglia EC2 più vicina con 2 vCPU e 8 GB. In eu-west-1 costa circa $0.074/h, a cui ho aggiunto circa $8.8 al mese per 100 GB di storage gp3. Sullo stesso periodo, il confronto è questo:

Scenario negli stessi 12 giorni (37.5 session-hours)Costo
AgentCore, compute a zero tra le sessioni$3.45
EC2 sempre accesa (288 h + storage riproporzionato)~$25
EC2 spenta diligentemente (37.5 h + storage riproporzionato)~$6.3

Per ogni ora effettivamente usata, AgentCore costa circa il 24% in più, $0.092 contro $0.074. Nel mio pattern discontinuo, però, l’assenza di compute tra le sessioni porta a un costo circa sette volte inferiore rispetto alla VM sempre accesa. Proiettando le stesse tariffe su un mese, il break-even rispetto a una t4g.large sempre accesa è intorno a 680–700 session-hours al mese. Anche rispetto a una VM spenta con attenzione, il costo fisso di EBS mantiene AgentCore in vantaggio sotto circa 490 session-hours al mese. Il calcolo non include il tempo dedicato al patching né le inevitabili dimenticanze nello spegnimento. Un developer o un piccolo team che usa gli agent per poche ore al giorno resta molto sotto queste soglie.

Questi dati, ricostruiti dalle metriche CloudWatch, sono coerenti con la vista aggregata di Cost Explorer. Nel mio utilizzo, i costi collaterali di S3, log e Lambda sono stati trascurabili. L’inferenza è esclusa e spesso domina la spesa complessiva: il costo totale dipende quindi soprattutto dal provider e dal modello scelto, non dal solo runtime.

Non è un benchmark esaustivo: la finestra è breve, l’utilizzo non è continuativo e riguarda un solo sviluppatore. Un team numeroso scalerebbe soprattutto con il numero di session-hours. Inoltre, il session storage gestito di AgentCore è in public preview e AWS ha annunciato che il prezzo cambierà prima della GA. Al momento non compare come voce di costo e non è incluso nei $3.45.

Perché ho scelto AgentCore invece delle alternative #

EC2 non è l’unica alternativa. Fargate, AgentCore Instances e gli agent hosted risolvono parti diverse dello stesso problema.

ECS Fargate. Anche Fargate scala a zero e, per questo carico, il prezzo è dello stesso ordine di grandezza: applicando le tariffe ARM di eu-west-1 alle mie 37.5 session-hours, il costo stimato sarebbe circa $2.3 con 1 vCPU e $3.5 con 2 vCPU, contro i $3.45 di AgentCore. La differenza decisiva, per SCH, non è quindi il prezzo. Con Fargate dovrei costruire indirizzamento per sessione, idle timeout, segnale di busy, storage del workspace e invocazione autenticata. AgentCore offre già queste primitive e, grazie alle microVM pre-inizializzate, nei miei test ha ripristinato un workspace in pochi secondi. Non ho eseguito un benchmark affiancato: il confronto combina la documentazione dei servizi con una misurazione di AgentCore.

AgentCore Instances. Il servizio offre anche agent su istanze EC2 gestite da AWS nel vostro account. Si pagano l’istanza, una management fee e lo storage EBS anche quando la macchina è ferma; in cambio, le sessioni possono durare fino a 14 giorni. Questa opzione è più adatta a carichi che superano le otto ore o mantengono molto stato locale. Per SCH preferisco il limite delle otto ore perché impone checkpoint frequenti.

Agent hosted. Claude Code sul web, Codex cloud e il coding agent di Copilot permettono già di chiudere il laptop e richiedono meno setup. SCH mi interessa per un requisito diverso: tenere repository, sessioni, checkpoint e inferenza nel mio account AWS, sotto policy IAM definite da me, scegliendo harness e provider. Oggi SCH usa una rete con egress pubblico. AgentCore supporta anche VPC, security group, endpoint privati e ingresso via PrivateLink, ma non ho ancora validato questa configurazione con SCH.

A chi può essere utile oggi #

  • Developer che lavorano su AWS e vogliono usare Bedrock tramite execution role, conservare la credential chain della CLI aws e limitare modelli e API accessibili al deploy.
  • Chi esegue task lunghi e intermittenti, preferendo checkpoint e branch a un server acceso h24. Ctrl+], sch status, una sessione per branch e sch fetch coprono questo flusso.
  • Team di sviluppo con requisiti di standardizzazione, che vogliono evitare una configurazione diversa per ogni sviluppatore. Un’immagine condivisa può raccogliere harness, modelli, server MCP, skill e plugin approvati.

Il caso del team è ancora una direzione da validare, non una raccomandazione di adozione enterprise. SCH centralizza l’ambiente dell’agent, ma non decide se le sue azioni siano corrette. Un execution role sovradimensionato resta pericoloso anche dentro una microVM. Anche Telegram è un adapter pratico per il mio flusso personale, non il control plane che proporrei come standard aziendale.

Limiti #

  • Eredità da POC. Il trust model è single-account e il ruolo predefinito è ampio. Alcune API AgentCore sono ancora in preview; il session storage ha limiti propri, ogni runtime accetta al massimo 10 shell interattive concorrenti e il canale WebSocket impone quote su frame e rate. Questi vincoli sono documentati nel repository come note di sicurezza o invarianti di specifica.
  • Costi esclusi. ECR, bucket e registry possono generare costi anche tra le sessioni. L’inferenza, esclusa dai $3.45, è spesso la voce dominante. Il session storage è gratuito soltanto durante la preview. Un cambio di runtime version o la scadenza dopo 14 giorni ricrea la microVM; L2 ripristina il checkpoint, ma gli ultimi secondi non ancora salvati vanno persi.
  • Differenze tra harness. Pi non ha in SCH il canale di approvazione, le modalità web, attach, acp e handoff né l’integrazione MCP. I transcript JSONL di Claude crescono cumulativamente, quindi il timeout di sette ore limita anche quel consumo. OpenCode rimane l’harness con il supporto più completo.
  • Dipendenza da AWS. Il codice di SCH usa direttamente i servizi e le api di AWS tramite la aws cli. Il progetto dichiara esplicitamente che l’astrazione multi-cloud non è un obiettivo. Il pattern architetturale può essere portato altrove, ma l’implementazione attuale comporta lock-in.
  • Un solo maintainer. Oggi il progetto dipende da una sola persona, quindi continuità e velocità di manutenzione non sono quelle di un prodotto supportato. Specifiche e controlli end-to-end nel repository riducono il rischio, ma non lo eliminano.

Cosa viene dopo: immagine più snella, guardrail, VPC e identità #

I prossimi passi, in ordine approssimativo di priorità, sono:

  • Una prova con un team più ampio. Voglio validare registry, separazione dei workspace per proprietario e SSO reale per capire se un’immagine condivisa funziona con più sviluppatori.
  • Un’immagine più snella. La memoria produce circa l'80% del costo, quindi ridurre il memory footprint è la prima ottimizzazione economica.
  • Guardrail di costo per workspace. Oggi uso timeout del task, allow-list dei modelli e sch stop; mancano budget e allarmi per workspace.
  • Un deployment privato. Devo validare la network mode VPC e PrivateLink per il percorso di invocazione.
  • Identity passthrough. Oggi ogni sessione agisce sotto un unico execution role. Vorrei farle assumere l’identità del developer che la invoca, preservandone i permessi. AgentCore Identity e i session tag STS sono possibili elementi della soluzione, che non ho ancora progettato.

Il pattern, una sandbox per sessione, checkpoint su object storage e identità cloud come confine dei permessi, non è esclusivo di AWS. Portarlo su un altro cloud richiederebbe però di riscrivere shim e infrastruttura; non è un obiettivo della roadmap attuale.

Codice sorgente completo, specifiche, diagramma di architettura e script di verifica sono su c-daniele/sch.

Per provarlo partirei da sch run aws-lab, che crea un workbench usa-e-getta, e poi userei sch task --branch su un branch sacrificabile. Le issue più utili sono quelle accompagnate dall’output di sch status, soprattutto per race durante il restore e timeout delle approvazioni.

Riferimenti #