Entscheidung: AWS Lambda + CDK als Standard fuer Cron-Agents
Kontext
Wir bauen mehrere autonome Background-Agents: Beleg-Pipeline, Daily-Planner, Mahnungs-Checker, Follow-up-Bot, … — alle Cron-getriggert, alle senden Telegram-Push, alle rufen MCPs auf. Vor dieser Entscheidung lief eine Phase-0-Implementation auf Cloudflare Workers (~/source/agents/email-agent/, ~580 LOC TypeScript). Frage: welche Plattform fuer alle zukuenftigen Agents.
Optionen die wir geprueft haben
| Option | Pro | Contra |
|---|---|---|
| Cloudflare Workers (Status quo Phase 0) | Cron nativ, Free-Tier, schon halb implementiert | Long-Lived AWS Access Key in CF-Secret noetig, SigV4 cross-cloud, 128 MB Memory, 2 Provider-Bills |
| AWS Lambda + EventBridge + CDK | IAM-Execution-Role statt Access-Key, native AWS-SDKs, bis 10 GB Memory, eine Bill, ARM64 billiger | Phase-0-Code wird weggeworfen (~1 Tag), CDK-Lernkurve (haben wir aber schon durch mcp-vf-hosted) |
| AWS Bedrock AgentCore Runtime | Memory + Multi-Turn-Sessions managed | Overkill fuer Cron-Stateless-Jobs, Pricing intransparent, Konversations-Use-Case-orientiert |
Entscheidung
AWS Lambda + EventBridge + CDK ist der Standard fuer alle Cron-Agents ab 2026-05-12.
Plattform-Repo: ~/source/agents-platform/
Pattern-Construct: AgenticVenturesAgent (Lambda + EventBridge-Rule + IAM-Role + CloudWatch-Logs)
Shared Code: Lambda-Layer agentic-common (Telegram-Client, Bedrock-Wrapper, MCP-Client, Vault-Helper, Logging)
Account: av-production (425924867359), Region eu-central-1
Detail: agents-platform.
Konvention fuer neue Agents
- Lambda-Code unter
~/source/agents-platform/lambdas/<name>/mitmain.py(handler(event, context)) - CDK-Stack unter
~/source/agents-platform/infra/lib/<name>-stack.tsnach Vorlagebeleg-pipeline-stack.ts - Stack in
infra/bin/app.tsinstanzieren - Permissions ueber
permissions: [...]Construct-Prop — nicht direkt am Lambda - Secrets nur ueber Secrets Manager, niemals Env-Vars mit Klartext
- Cross-Account-Schreibzugriff ueber STS AssumeRole, nicht ueber Long-Lived Credentials
- Telegram-Push am Run-Ende mit standardisiertem Format (siehe Capability-Doku)
- CloudWatch-Logs-Retention default 30 Tage
- Eintrag im Vault unter
intern/projekte/<name>/_index.md - Eintrag in der „Aktive Agents”-Tabelle in aktive-agents
Was NICHT in dieses Pattern gehoert
- Konversations-Agents mit Memory (HeyJulia, Voit-Style-Assistenten) → eigene Evaluation AgentCore Runtime + Memory, separat
- HTTP-MCP-Server (Capabilities die von Clients angerufen werden) → bleiben auf Fargate-Tunnel siehe mcp-vf-hosted
- Event-getriggerte Lambdas die nicht zu „Marvin’s Agents” gehoeren (z.B. S3-Event-Handler fuer Customer-Workloads) → eigener Stack pro Use-Case in Kunden-Sub-Account
Konsequenzen
- Cloudflare-Workers-Setup
~/source/agents/email-agent/wird archiviert (Git-Tagv0-cloudflare-archived). Code bleibt als Referenz fuer Patterns (Telegram-Push-Format, Gmail-Auth-Refresh) aber wird nicht weiterentwickelt. - IAM-User
email-agent-beleg-writerin av-production wird deprecated sobald Lambda live ist. Access Key wird invalidiert. Cross-Account-Role in mk-privat behaelt nur die Lambda-Role-ARN im Trust. - Alle zukuenftigen Agents (Daily-Planner, Mahnungs-Checker, Follow-up-Bot, …) folgen dem Pattern. Sub-Sessionen die einen Agent „ad hoc” anlegen wollen, muessen erst die Capability-Doku lesen und das Pattern nutzen — kein Wildwuchs.
- Bei neuem Cron-Bedarf: erst pruefen ob ein existierender Agent erweitert werden kann (z.B. neuer Filter, neue Klasse), erst dann neuer Agent.
Reminder
Mai 2027 — re-evaluieren: gibt’s bessere Alternativen, sind Bedrock-Preise gestiegen, hat AgentCore mittlerweile auch Cron-Support mit IAM-Roles ohne Memory-Overhead? Stand 2026-05-12 ist Lambda klarer Sieger fuer diese Use-Cases.