9. April 2026

Agent-Infrastruktur: Colab MCP Server, botctl und Skrun

Drei Tools, die in der gleichen Woche erschienen sind, adressieren jeweils eine andere Luecke in der Agent-Infrastruktur: Cloud-Compute, Prozessmanagement und API-Deployment. Zusammen zeichnen sie ein Bild davon, wie sich das Oekosystem rund um autonome AI-Agenten professionalisiert.

Google Colab MCP Server

Google hat den Colab MCP Server als Open-Source-Projekt veroeffentlicht. Er implementiert das Model Context Protocol (MCP) und erlaubt MCP-kompatiblen Agenten -- etwa Gemini CLI oder Claude Code -- direkt mit Google Colab zu interagieren.

Was der Server kann:

Notebooks erstellen, organisieren und ausfuehren
Code-Zellen remote ausfuehren, Abhaengigkeiten verwalten
Ausgaben und Zellen umstrukturieren
Ergebnisse zurueck in den lokalen Agent-Workflow liefern

Warum das relevant ist:

Lokale Agent-Setups stossen schnell an Grenzen: kein GPU-Zugang, Sicherheitsbedenken beim Ausfuehren von unbekanntem Code. Der Colab MCP Server lagert diese Probleme in eine verwaltete Cloud-Umgebung aus. Der Agent arbeitet weiterhin lokal, delegiert aber die Ausfuehrung an Colab. Das Ergebnis ist ein interaktives, reproduzierbares Notebook -- kein Blackbox-Output.

Architektonisch laeuft der MCP-Server lokal und verbindet sich mit einer Colab-Session im Browser. Die Konfiguration erfolgt ueber eine JSON-Datei, die auf das GitHub-Repository verweist. Voraussetzungen sind Python, Git und der uv Package Manager.

botctl

botctl ist ein Process Manager fuer autonome AI-Agenten. Das Konzept: Agenten werden nicht in Chat-Sessions betrieben, sondern als persistente Hintergrundprozesse mit deklarativer Konfiguration.

Kernfunktionen:

BOT.md als Konfigurationsformat: YAML-Frontmatter fuer Einstellungen (Name, Intervall, maximale Turns), Markdown-Body als System-Prompt
Terminal-Dashboard (TUI): Uebersicht ueber alle laufenden Bots mit Status, Kosten und Logs
Web-UI: Browser-basiertes Dashboard mit denselben Faehigkeiten wie die TUI
Session Memory: Jeder Run speichert seine Session. Bots koennen da weitermachen, wo sie aufgehoert haben
Hot Reload: Aenderungen an BOT.md werden beim naechsten Run automatisch uebernommen
Messaging: Laufende Bots koennen ueber CLI oder Dashboard mit neuen Anweisungen umgelenkt werden

Typischer Workflow:

botctl create my-bot -d "Monitor weather APIs" -i 300 -m 20
botctl start my-bot --detach
botctl logs my-bot -f
botctl start my-bot --message "check the error logs"

botctl installiert sich als einzelnes Binary ueber ein Shell-Skript und unterstuetzt macOS, Linux und Windows (AMD64 und ARM64). Die Installation laeuft ueber curl -fsSL https://botctl.dev/install.sh | sh.

Warum das relevant ist:

Bisher fehlt eine Standardloesung fuer das Management mehrerer parallel laufender Agenten. botctl fuellt diese Luecke mit einem Ansatz, der sich an bekannten Process Managern wie pm2 oder systemd orientiert -- nur eben fuer AI-Agenten statt fuer Node-Prozesse oder Systemdienste.

Skrun

Skrun verfolgt einen anderen Ansatz: Jeder Agent Skill wird als API bereitgestellt. Das Projekt baut auf dem SKILL.md-Standard auf und macht daraus aufrufbare HTTP-Endpunkte.

Kernkonzepte:

SKILL.md als Eingabe: Der offene Agent-Skills-Standard (kompatibel mit Claude Code, Copilot, Codex) dient als Basis
agent.yaml als Runtime-Config: Modell, Ein-/Ausgabetypen, Berechtigungen, State, Tests
POST /run als API: Jeder Agent wird ueber einen einzigen HTTP-Endpunkt ansprechbar
Multi-Model: Unterstuetzt Anthropic, OpenAI, Google, Mistral und Groq mit automatischem Fallback
Stateful: Agenten behalten ihren Zustand ueber mehrere Runs hinweg via Key-Value-Store
Tool Calling: Eigene CLI-Tools (scripts/) oder MCP-Server (npx) als Werkzeuge

Typischer Workflow:

npm install -g @skrun-dev/cli
skrun init --from-skill ./my-skill
skrun dev          # Lokaler Server mit POST /run
skrun test         # Automatisierte Tests
skrun deploy       # Build + Push + Live-URL

Die aktuelle Version v0.1 liefert eine lokale Runtime. Cloud-Deploy ist auf der Roadmap -- die Architektur ist ueber ein RuntimeAdapter-Interface vorbereitet.

Warum das relevant ist:

Skrun schliesst die Luecke zwischen Agent Skills als Konfigurationsdateien und Agent Skills als produktive Dienste. Ein SKILL.md, das bisher nur innerhalb eines Coding-Agenten funktionierte, wird durch Skrun zu einer API, die jedes System aufrufen kann. Das macht Agent-Faehigkeiten komposierbar und integrierbar in bestehende Architekturen.

Einordnung

Alle drei Tools adressieren Infrastruktur-Probleme, die entstehen, wenn Agenten von experimentellen Chat-Demos zu produktiven Systemen werden:

Colab MCP Server loest das Compute-Problem: Agenten brauchen GPUs und sichere Ausfuehrungsumgebungen, die lokal nicht verfuegbar sind.
botctl loest das Management-Problem: Mehrere Agenten muessen parallel laufen, ueberwacht und gesteuert werden.
Skrun loest das Integrations-Problem: Agent-Faehigkeiten muessen als APIs bereitstehen, nicht nur als lokale Tools.

Gemeinsam ist allen drei Projekten, dass sie auf offene Standards setzen -- MCP, SKILL.md, YAML-Konfiguration -- statt proprietaere Plattformen zu bauen. Das deutet darauf hin, dass sich die Agent-Infrastruktur in Richtung eines modularen Oekosystems entwickelt, in dem einzelne Komponenten austauschbar sind.

Quellen

Nach oben