Wirksame Agent-Automatisierungen erstellen

Da KI unsere Arbeit beschleunigt, wird es immer schwieriger, mitzuhalten. Bei Anthropic werden häufig einfache Agent-Automatisierungen als Hilfe eingesetzt. Sie laufen oft nach einem Zeitplan, sammeln im Hintergrund Kontext und teilen uns proaktiv mit, was wir wissen müssen. Aber es ist schwierig, wirksame Agent-Automatisierungen zu bauen: Sie können den Zugriff auf eine Quelle verlieren, ohne dass jemand es bemerkt, oder unsere Präferenzen nicht befolgen.

Mit Claude Managed Agents (Beta) haben wir eine Referenzimplementierung gebaut, die benutzerdefinierte Quellen (z. B. Slack und GitHub-Repos) nach einem Zeitplan liest, nachverfolgt, was sich seit dem letzten Lauf geändert hat, und postet, was Sie wissen müssen (z. B. in Slack). In diesem Artikel gehen wir jeden Schritt durch, teilen eine Referenzimplementierung und stellen einen Befehl bereit, der in Claude Code ausgeführt werden kann und den Agenten für Sie konfiguriert.

CODE HOLEN

Die Referenzimplementierung ist hierverfügbar. Für einen interaktiven Durchlauf führen Sie den folgenden Befehl in Claude Code aus. Der claude-api Skill kann beim Einrichten des Agenten gemäß den Hinweisen in diesem Artikel helfen:

/claude-api managed-agents-onboard https://claude.dev/blog/building-effective-agent-automations/

Für diese Referenzimplementierung benötigen Sie eine Slack-App (aus dem Manifest erstellen) und einen GitHub-Token. Die bereitgestellten Dateien (unten dargestellt) sind die Konfiguration für Claude-API-Ressourcen, einschließlich des Agenten, seiner Umgebung, Speicher, Vault und Bereitstellung.

daily-brief/
├── agent.md                        model, tools, instructions
├── deployment.md                   schedule, time zone, budget, input message
├── environment.yaml                network allowlist
├── memory_store_preferences.yaml   user preferences
├── memory_store_state.yaml         the agent's bookmarks, ledger, notes, and run records
├── vault.yaml                      the vault that holds the credentials
├── claude-lock.json                resource IDs, written by ant apply
└── slack/manifest.yaml             one bot app

ant apply, ein Befehl in der ant CLI, liest diese Dateien, erstellt die Ressourcen in Ihrem Claude-API-Workspace (wo die Plattform sie speichert und ausführt) und zeichnet die IDs auf in claude-lock.json.

Wir werden diesen Befehl in den folgenden Abschnitten verwenden. Nach der Konfiguration läuft die Automatisierung nach einem Zeitplan auf der Infrastruktur von Anthropic, sodass nichts auf Ihrem Rechner laufen bleiben muss.

ÜBERBLICK

Der Agent, den wir bauen werden, hat sechs Komponenten, die in dieser Reihenfolge behandelt werden:

• Quellen - Eine benannte Liste von Orten, die gelesen werden
• Ziel - Ein Ort, an den der Agent schreiben darf
• Agent - Das Modell, die Tools und die Ausführungsschritte in agent.md
• Zeitplan - Ein Cron-Zeitplan
• Speicher - Ihre Präferenzen und der eigene Speicher des Agenten
• Schutzmaßnahmen - Schreibgeschützter Zugriff überall dort, wo der Agent nur liest, und ein Ausgabenlimit pro Lauf

QUELLEN

Der Agent liest zwei Standardquellen: Slack-Kanäle und GitHub-Pull-Requests. Die Kanäle und Repos sind in Ihrer preferences -Datei aufgelistet. Die Vorlage kann erweitert werden, um andere Quellen zu verwenden.

Geben Sie dem Agenten eigene, eingeschränkte Zugangsdaten

Mit Verwaltete Agenten, Zugangsdaten befinden sich in Tresore". Der Agent kann auf diese Zugangsdaten verweisen, aber die echten Werte bleiben im Tresor, außerhalb der Sandbox, in der Claudes Code ausgeführt wird (siehe hier und hier):

• MCP-Server (GitHub). Der Agent ruft MCP-Tools über einen Proxy auf, der außerhalb der Sandbox läuft. Der Proxy findet den Vault-Credential, dessen URL mit der des Servers übereinstimmt.

• Die Shell (Slack). Der Agent ruft die Slack API mit curl auf und nutzt dabei das bash-Tool innerhalb der Sandbox. Die Sandbox enthält nur einen intransparenten Platzhalter, $SLACK_BOT_TOKEN. Sobald die Anfrage die Sandbox verlässt, ersetzt die Plattform den Platzhalter durch das echte Token für die von Ihnen zugelassenen Hosts.

Erstellen Sie den Vault mit der ant CLI und der Vorlagendatei im Repository:

ant apply vault.yaml

Damit wird der Vault in Ihrem Claude API Arbeitsbereich erstellt, wo die Plattform ihn speichert, und seine ID in claude-lock.jsonhinterlegt. Fügen Sie dann jede Anmeldedatum mit dem TypeScript SDKzum Vault hinzu. Hier ist ein Beispiel, das das Hinzufügen der Slack-Anmeldedaten zeigt:

const vaultId = process.env.VAULT_ID!; // the vault's ID, from claude-lock.json

await client.beta.vaults.credentials.create(vaultId, {
  display_name: "SLACK_BOT_TOKEN",
  auth: {
    type: "environment_variable",
    secret_name: "SLACK_BOT_TOKEN",
    secret_value: process.env.SLACK_BOT_TOKEN!,
    networking: { type: "limited", allowed_hosts: ["slack.com"] },
    injection_location: { header: true },
  },
});

Nachdem Sie den Vault erstellt und jede Anmeldedatum hinzugefügt haben, verknüpfen Sie den Vault mit der Bereitstellung. Kopieren Sie die Vault-ID aus claude-lock.json in vault_ids in der Bereitstellungsdatei, deployment.md.

Lesen Sie dort weiter, wo Sie aufgehört haben

Ein häufiger Fehler ist, den Agenten zu bitten, ein festes Fenster zu lesen wie "die letzten 24 Stunden." Ein später Lauf lässt eine Lücke und ein früher Lauf wiederholt Elemente. Geben Sie dem Agenten stattdessen ein Lesezeichen pro Quelle. Am Ende jedes Laufs schreibt der Agent den Zeitstempel des neuesten Elements, das er aus jeder Quelle gelesen hat, in eine Datei, bookmarks.json, mit einem Eintrag pro Quelle: "slack": "2026-09-14T13:02:11Z".

Der nächste Lauf beginnt bei diesen Lesezeichen, sodass sein Fenster sich ausdehnt oder verkleinert, um alles seit dem letzten Lauf abzudecken. Die Lesezeichen befinden sich im memory store namens state: ein Ordner mit Textdateien, den die Plattform in die Sandbox jedes Laufs unter /mnt/memory/ einbindet und zwischen den Läufen beibehält. Der Agent liest und schreibt sie mit seinen gewöhnlichen Dateiwerkzeugen, und die Anweisungen in agent.md sagen ihm, wie.

Verwechseln Sie nicht eine fehlgeschlagene Leseoperation mit einem ruhigen Tag

Wenn ein MCP-Server ausgefallen ist oder sein Token abgelaufen ist, startet der Lauf trotzdem, nur ohne die Werkzeuge dieses Servers. Die Sitzung protokolliert einen Fehler, aber der Agent sieht nichts von dieser Quelle und meldet „nichts Neues.“

Drei Regeln in agent.md helfen, das zu beheben. Wenn eine Quelle fehlschlägt, wird der Agent: das Lesezeichen der Quelle an seinem Ort belassen, die Zusammenfassung aus den anderen Quellen schreiben und die Zusammenfassung mit einer Zeile abschließen, die nennt, was er nicht lesen konnte („pull requests unavailable this run“), damit der Leser darüber informiert ist.

DESTINATION

Unsere Vorlage veröffentlicht in einem Slack-Kanal, mit einem datierten Beitrag bei jedem Lauf.

Der Agent veröffentlicht in Slack mit dem bash-Werkzeug in seiner Sandbox und verwendet dabei dasselbe Bot-Token, mit dem er auch liest.

Nichts muss den Beitrag genehmigen. Der Agent sendet ihn mit einem bash-Befehl, und das eingebaute bash-Werkzeug läuft standardmäßig ohne Genehmigungsanfrage. slack.com steht auch auf der Allowlist des environmentdes Agenten, der Sandbox, in der er läuft. Der Beitrag ist eine einzige Anfrage:

curl -s https://slack.com/api/chat.postMessage \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN" \
  -H "Content-Type: application/json; charset=utf-8" \
  -d '{"channel": "C0123456789", "text": "Daily brief, Tue Sep 15 ..."}'

Bestätigen Sie, dass der Beitrag gelandet ist, bevor Sie ihn aufzeichnen

Sobald ein Beitrag bestätigt ist, aktualisiert der Agent sein Verzeichnis der gemeldeten Elemente und seine Lesezeichen. Wenn diese Aufzeichnungen nicht mit dem übereinstimmen, was tatsächlich veröffentlicht wurde, können zwei Dinge schiefgehen. Zeichnet der Agent einen Beitrag auf, der nie gelandet ist, rücken die Lesezeichen weiter und diese Elemente werden nie gemeldet. Veröffentlicht er erneut, weil er sich nicht sicher ist, ob der erste Beitrag gelandet ist, erhalten die Leser dieselbe Zusammenfassung zweimal.

Drei Regeln in agent.md verhindern dies. Erstens sucht der Agent nach dem heutigen Titel in den aktuellen Nachrichten des Kanals und veröffentlicht nicht, wenn die Ausgabe bereits vorhanden ist. Zweitens gilt der Beitrag nur dann als gesendet, wenn Slack "ok": true und einen message ts zurückgibt. Drittens aktualisiert der Agent das Verzeichnis und die Lesezeichen erst nach dieser Bestätigung. Ist das Ergebnis unklar, markiert er den Lauf als „maybe posted“ und ändert nichts weiter, sodass nichts verloren geht.

Der Agent führt einen Laufdatensatz in seinem Memory Store (runs/<date>.md). Er markiert den Lauf vor dem Beitrag als „posting“, danach als „posted“ mit der Nachrichten-ID oder als „maybe posted.“

AGENT

In Claude Managed Agents ist ein agent ist eine versionierte Konfiguration: ein Modell, ein System-Prompt und Tools. Jeder Lauf folgt seinen Lauf-Schritten und stoppt.

In unserer Referenzimplementierung ist die Agentenkonfiguration agent.md:

---
name: Daily brief
model: claude-sonnet-5-5
mcp_servers:
  - type: url
    name: github
    url: https://api.githubcopilot.com/mcp/
tools:
  - type: agent_toolset_20260401
    configs:
      - name: web_search
        enabled: false
      - name: web_fetch
        enabled: false
  - type: mcp_toolset
    mcp_server_name: github
    default_config:
      permission_policy:
        type: always_allow
---

[Eight numbered run steps; the full text is in agent.md in the repo.]

Das Frontmatter liefert den Agentennamen, das Modell, die Tools und die MCP-Server. Der Hauptteil enthält die Anweisungen für den Agenten. MCP-Tools verlangen standardmäßig eine Freigabe, und niemand ist da, um sie zu erteilen, daher ist das GitHub-Toolset auf always_allow gesetzt und das GitHub-Token ist read-only.

Halte die Zusammenfassung kurz

agent.md lenkt Claude in Richtung Kürze:

4. Decide. An item earns a line when the reader would act on it today, or it changes a decision they are about to make. When unsure, leave it out. Most days that is a few items, sometimes none. A count ("12 open reviews") is not an item; link the ones that are blocked. An item already in the ledger and still open is carried as one marked line ("still waiting, day 3"), not re-reported; a closed item is dropped without comment. Do not bring back a topic the preferences file has retired.

Prüfe alles, was noch offen ist, unmittelbar vor dem Posten erneut

Zustände können sich ändern, zwischen dem Moment, in dem der Agent die Quellen liest, und dem Moment, in dem er postet. Unmittelbar vor dem Posten agent.md weist den Agenten an, den Live-Status jedes Elements erneut zu prüfen:

5. Verify. The world moved while you read. For every item you will report, re-check its live source just before posting: resolved since you read it, drop it; still open but changed, fix the line; cannot confirm, drop it and list it in the run record's cuts. One stale "still waiting on you" costs more trust than ten missing items, so never hedge an item's status: assert it or drop it. Every link is copied from the source's own link field (a pull request's html_url, a Slack permalink), never assembled by hand.

SCHEDULE

Bei Claude Managed Agents ist der Agent nur eine Konfigurationsdatei; ein Deployment führt ihn aus. Das Deployment benennt den Agenten, die Umgebung und die erste Nachricht jedes Laufs. Es enthält außerdem den Zeitplan, den Vault, die Memory Stores und das Budget. Jedes Mal, wenn der Zeitplan auslöst, startet die Plattform eine neue Agenten- Session.

In unserer Vorlage ist das Deployment in deployment.mderfasst, mit der ersten Nachricht als Inhalt:

---
name: Daily brief
agent: ./agent.md
environment_id: ./environment.yaml
schedule:
  type: cron
  expression: "32 7 * * 1-5"
  timezone: America/New_York
vault_ids: [vlt_...]   # the vault you create under Sources
resources:
  - path: ./memory_store_preferences.yaml
    access: read_only
    instructions: The reader's preferences. Re-read them every run. Never write here.
  - path: ./memory_store_state.yaml
    access: read_write
    instructions: Your state. Bookmarks, ledger, notes, proposals, and run records.

---

Write today's brief.
The reader's time zone is America/New_York. Work out every date in that zone.

Follow your run steps in order. Today's edition is titled "Daily brief, <weekday> <month> <day>".

Dies erzeugt das Deployment mit dem Agenten, der Umgebung und den Memory Stores, die es per Pfad benennt.

ant apply deployment.md

Um es zu testen, ohne auf den Zeitplan zu warten, starte einen Lauf von Hand mit ant beta:deployments run --deployment-id <id>unter Verwendung der ID aus claude-lock.json.

Daten in Ihrer Zeitzone berechnen

Ein häufiger Fehler ist, dass der Agent diesen Morgen als „gestern" bezeichnet, weil er Daten in der Zeitzone des Servers berechnet. In deployment.mdlegt das timezone -Feld fest, wann der Lauf ausgelöst wird, und die zweite Zeile im Haupttext teilt dem Agenten mit, welche Zeitzone er für Daten verwenden soll.

MEMORY

Jeder Lauf beginnt in einer frischen Sandbox ohne Erinnerung an den vorherigen. Ohne Speicher bleibt Feedback ohne Wirkung. Veralteter Speicher kann den Agenten jedoch verwirren: Er meldet einen Punkt noch als wartend, obwohl er bereits erledigt ist, oder lässt einen aus, der noch offen ist, weil er „bereits gemeldet" war.

Unsere Vorlage verwendet zwei Speicherspeicher, die Ordner, die unter /mnt/memory/ eingebunden sind (siehe Sources):

• preferences (Ihre, für den Agenten nur lesbar): welche Kanäle und Repositories gelesen werden, was ausgelassen wird, die Längenobergrenze, das Ziel und wann gestoppt werden soll.

• state (die des Agenten, lesbar und schreibbar): die Lesezeichen, ein Verzeichnis dessen, was er gemeldet hat, je Lauf ein Eintrag, Änderungsvorschläge zu Ihren Präferenzen und Notizen zum Verhalten jeder Quelle („liefert nur die neuesten 50 Einträge").

ant apply deployment.md erstellt den preferences-Speicher, aber nicht die Datei darin. Vor dem ersten Lauf schreiben Sie Ihre preferences.md dorthin mit dem scripts/seed-preferences.sh.

Lesen Sie Ihre Präferenzen zu Beginn jedes Laufs erneut

Ein häufiges Problem tritt auf, wenn eine Kopie der Präferenzen in den Prompt eingebettet ist, wodurch Regeln weiter angewendet werden, die Sie bereits geändert haben. Lassen Sie den Agenten die Datei bei jedem Lauf frisch lesen. Wenn er die Datei nicht lesen kann, soll er anhalten und dies mitteilen, statt mit Standardwerten weiterzulaufen.

Führen Sie ein Verzeichnis über bereits Gemeldetes und berichten Sie die Änderung

Der Agent führt ein Verzeichnis, ledger.md, über jeden Punkt, den er gemeldet hat, damit die Zusammenfassung sich nicht wiederholt. Jede Zeile vermerkt, wann der Punkt gemeldet wurde, woher er kam, eine unveränderliche ID (ein Slack-Nachrichten-Zeitstempel oder eine Pull-Request-Nummer) und seinen letzten bekannten Status:

2026-09-09 slack:C0123456789 1788963600.000100 refund thread: customer waiting on a decision
2026-09-11 github 481 review blocked, day 2 (still waiting)
2026-09-11 slack:C0234567891 1789117333.000300 enterprise escalation: owner named, in progress

GUARDRAILS

Da unsere Automatisierung nach Zeitplan im „Hintergrund" läuft, setzen wir Grenzen dafür, was der Agent tun und was er ausgeben darf.

Grenzen dafür, was er tun darf

Der Agent liest Nachrichten und Issues, die andere Personen verfasst haben, und dieser Text kann als Anweisungen interpretiert werden. Begrenzen Sie, was der Agent tun könnte, wenn er ihnen folgt. In unserem Beispiel sind der GitHub-Token und der preferences -Speicher nur lesbar, und die Umgebung erreicht nur Hosts auf ihrer Allowlist. Eine eingeschleuste Anweisung kann dennoch ändern, was in der Zusammenfassung steht, auch über die Notizen, die der Agent zwischen den Läufen aufbewahrt. Er kann nicht auf GitHub schreiben oder Ihre Regeln bearbeiten.

Slack ist die Ausnahme: Derselbe Token postet, also laden Sie den Bot nur dorthin ein, wo er lesen oder posten muss.

Legen Sie das Ausgabenlimit anhand echter Läufe fest

Ein Ausgabenlimit schützt Sie vor außer Kontrolle geratenden Kosten. Beginnen Sie mit dem Drei- bis Fünffachen der Kosten eines normalen Laufs und straffen Sie es, sobald Sie echte Zahlen sehen. Ein Lauf, der sein Limit erreicht, pausiert, statt zu fehlschlagen, daher sieht ein zu niedrig gesetztes Limit aus wie eine verstummte Zusammenfassung. Das Limit ist das budget in deployment.md. Jeder Lauf erhält den vollen Betrag, und ein Lauf, der ihn erreicht, pausiert mit einem budget_reached stop reason:

budget:
  type: limit
  max_list_cost:
    amount: "500" # a string, in cents: "500" is $5.00
    currency: USD

ERSTE SCHRITTE

Unsere Referenzimplementierung läuft auf sechs Regeln hinaus:

• Lies jede Quelle über ein Lesezeichen, nicht über ein festes Zeitfenster.
• Melde eine fehlgeschlagene Lesung als unlesbar, niemals als stillen Tag.
• Prüfe jedes Element unmittelbar vor dem Posten erneut.
• Zähle einen Post erst als gesendet, wenn Slack dies bestätigt, und aktualisiere dann Lesezeichen und Ledger.
• Lies deine Präferenzen bei jedem Durchlauf erneut, aus einem Speicher, den der Agent nicht bearbeiten kann.
• Gib dem Agent schreibgeschützten Zugriff, wo er nur liest, und begrenze, was jeder Durchlauf ausgeben darf.

Claude Code kann dich durch die in diesem Artikel gegebenen Hinweise führen. Führe zunächst ein Update aus:

claude update

Verwende dann das claude-api-Skill:

/claude-api managed-agents-onboard https://claude.dev/blog/building-effective-agent-automations/

Das claude-api-Skill liest diesen Beitrag, schlägt ein Setup vor, schreibt die Dateien in einen agents/-Ordner in Ihrem Projekt und erstellt die Ressourcen mit ant apply. Betrachten Sie dies als Ausgangspunkt und passen Sie den Agenten an Ihre Quellen, Ihr Ziel oder Ihre Speicher-Präferenzen an.