Einstieg in Agent Accounts: Architektur und E-Mail-Flows

Was ist ein Nylas Agent Account?

Ihr KI-Agent muss E-Mails senden und empfangen. Selbst gehostete E-Mail bedeutet 5 Systeme, die Sie selbst betreiben: DNS-MX-Records (24-48 Stunden Propagierungszeit), einen SMTP-Daemon wie Postfix oder Exim (12 Sicherheitshinweise seit 2020, laut der offiziellen Ankündigungsliste), Spamfilterung über SpamAssassin, TLS-Zertifikate mit vierteljährlicher Rotation und einen MIME-Parser für das RFC 5322 Wire-Format.

Ein Nylas Agent Account ersetzt alle 5 mit einem CLI-Befehl. Sie erhalten eine vollständig verwaltete E-Mail-Identität, die ohne OAuth-Zugangsdaten, MX-Records oder ein Drittanbieter-Postfach sendet und empfängt. Die API stellt Ihre Adresse in unter 2 Sekunden bereit und gibt einen Grant zurück — denselben Entitätstyp, der für Gmail-, Outlook- und IMAP-Verbindungen verwendet wird — sodass jeder Standard-Endpunkt für E-Mail, Kalender und Kontakte identisch funktioniert. Ihre Adresse liegt auf der *.nylas.email Domain, und die Identität wird in dieselbe Nylas v3 API eingebunden wie jedes OAuth-verbundene Postfach.

Was kann ein Agent Account?

Ein Agent Account gibt Ihrem Agenten 3 Funktionen auf einer einzigen Identität: E-Mail, Kalender und Kontakte. Ein Grant, ein API-Schlüssel, ein Workspace. Ihr Agent liest seinen Posteingang, prüft Frei/Belegt-Verfügbarkeit und erstellt Kalendertermine — kein zweiter Dienst, keine separate Integration. Wettbewerber wie Agentmail, Cloudflare Email Workers und Postmark bieten verwaltete E-Mail-Konten an. Keiner bietet Kalender- oder Kontakt-Endpunkte auf derselben Identität.

Jede Funktion verwendet dieselbe CLI- und API-Oberfläche, die Sie bereits von OAuth-verbundenen Postfächern kennen. Wenn Ihr Agent E-Mails mit nylas email send sendet, kann er auch nylas calendar events list und nylas contacts list ausführen. Kein zusätzliches Setup. Keine weiteren Zugangsdaten. Für KI-Agenten, die über MCP verbunden sind, stehen alle 36 Tools über dieselbe Serververbindung zur Verfügung.

Wie erstelle ich ein Agent Account?

Die Erstellung eines Agent Accounts dauert einen CLI-Befehl und ist in unter 2 Sekunden abgeschlossen. Der Befehl stellt einen Grant mit provider=nylas bereit, erstellt den verwalteten Connector automatisch, falls dieser noch nicht existiert, und speichert den Grant lokal, sodass nachfolgende Befehle ihn automatisch auflösen. Kein OAuth-Handshake, keine DNS-Propagierung, keine Dashboard-Klicks.

Der Befehl nylas agent account create akzeptiert die gewünschte E-Mail-Adresse als einziges Argument. Die Domain ist die *.nylas.email Zone Ihrer Application. Die Adresse ist live und sendebereit innerhalb von 2 Sekunden nach Rückgabe des Befehls:

nylas agent account create support@yourapp.nylas.email

✓ Agent account created successfully!

Email:      support@yourapp.nylas.email
Provider:   nylas
Status:     valid

Sobald das Konto existiert, senden Sie E-Mails mit demselben nylas email send Befehl wie für jeden anderen Grant. Die Absenderadresse wird automatisch vom aktiven Grant übernommen — kein --from Flag nötig. Die Zustellung erfolgt in unter 2 Sekunden mit DKIM-Signierung auf der *.nylas.email Domain:

nylas email send \
  --to customer@example.com \
  --subject "Your receipt" \
  --body "Order #4821 confirmed. Shipping Tuesday."

Das Lesen des Posteingangs Ihres Agenten erfolgt mit nylas email list. Fügen Sie --json hinzu für strukturierte Ausgabe, die Agenten-Schleifen und Shell-Pipelines parsen können. Die Nylas v3 API gibt bis zu 200 Nachrichten pro Aufruf zurück:

nylas email list --limit 5 --json | jq '.[] | {from: .from[0].email, subject}'

Das ist eine funktionierende Agenten-Identität — erstellen, senden, empfangen — in 3 Befehlen. Für die vollständige Anleitung mit App-Passwörtern für IMAP/SMTP-Zugriff, Statusprüfungen und Produktionslimits siehe Eine KI-Agent-E-Mail-Identität erstellen.

Wie ist Agent Account architektonisch aufgebaut?

Agent Account basiert auf einer 5-Entitäten-Kette: Application, Connector, Grant, Workspace und Policy mit Rules. Die Application hält API-Schlüssel, der Connector definiert den verwalteten Provider-Typ, der Grant ist die E-Mail-Identität selbst, der Workspace gruppiert Policy- und Rule-Zuordnungen, und Rules definieren Bedingungs-Aktions-Paare, die eingehende und ausgehende E-Mails filtern. Eine einzelne Application kann Hunderte von Agent Accounts über diese Kette verwalten.

Jede Entität hat eine spezifische Rolle:

• Application — Ihr Container auf Projektebene. Enthält API-Schlüssel, Regionseinstellungen (US oder EU) und alle Connectors. Wird einmalig im Nylas Dashboard erstellt.
• Connector — definiert den Provider-Typ. Für Agent Accounts ist dies der verwaltete Nylas-Provider. Das CLI erstellt ihn automatisch beim ersten nylas agent account create Aufruf — kein manuelles Connector-Setup erforderlich.
• Grant (Agent Account) — die individuelle E-Mail-Identität. Hat eine E-Mail-Adresse, ein Statusfeld und eine workspace_id, die auf die Konfiguration verweist. Funktioniert mit jedem Standard-Endpunkt für E-Mail, Kalender und Kontakte — derselbe Grant, der den Posteingang liest, steuert auch nylas calendar events list und Verfügbarkeitsabfragen.
• Workspace — der Ankerpunkt für Policy- und Rule-Konfiguration. Enthält policy_id und rules_ids[] Referenzen. Diese Entität ist die Architekturschicht zwischen der Identität und ihren Verhaltenseinschränkungen.
• Policy — definiert ausgehende Einschränkungen für den Workspace (Rate Limits, Domain-Beschränkungen).
• Rules — Bedingungs-Aktions-Paare. Jede Rule passt auf Envelope-Felder wie Absenderdomain oder Empfänger und löst dann eine Aktion aus: block, archive, mark_as_read oder mark_as_starred.

Was ist ein Workspace und warum gibt es ihn?

Ein Workspace sitzt zwischen dem Grant Ihres Agent Accounts und dessen Policies und Rules. Anstatt policy_id direkt in den Grant-Einstellungen zu speichern, hält der Workspace sowohl policy_id als auch rules_ids[] als separate Referenzen. Warum ist das wichtig? Sie können Policies wechseln, ohne den Grant zu berühren, Rules unabhängig von Policies verwalten und Konfigurationen kontoübergreifend teilen.

Ihr Workspace befindet sich unter /v3/workspaces/{id} auf der Nylas API. Wenn Sie ein Agent Account erstellen, stellt die API sowohl den Grant als auch seinen Workspace in einem einzigen Aufruf bereit — unter 2 Sekunden. Sie interagieren nie direkt mit dem Workspace. Wenn Sie nylas agent policy list ausführen, lädt das CLI Ihren Standard-Grant, ruft den Workspace ab, liest die policy_id des Workspace und gibt die zugehörige Policy zurück. Die Kette ist für Sie unsichtbar.

Drei architektonische Vorteile ergeben sich aus dieser Indirektion:

1. Policy-Rotation — wechseln Sie Policies durch Patchen des Workspace, nicht des Grant. Die Identität bleibt stabil, während sich das Verhalten ändert. Null Ausfallzeit, unter 200 ms pro Update.
2. Unabhängige Rule-Verwaltung — fügen Sie Rules zum Workspace hinzu oder entfernen Sie sie, ohne das Policy-Objekt zu berühren. Das rules_ids[] Array des Workspace ist die maßgebliche Rule-Liste für dieses Konto.
3. Mandantenfähigkeit — verschiedene Konten können auf denselben Workspace verweisen, wenn sie Verhaltenseinschränkungen teilen, oder jedes kann seinen eigenen haben. Eine Application mit 50 Agent Accounts könnte 3 Workspaces nutzen: einen für Support-Postfächer, einen für Benachrichtigungssender, einen für Testautomatisierung.

So zahlt es sich aus: Ihr Agent sendet Kundenquittungen über eine Policy, die das ausgehende Volumen auf 500/Stunde begrenzt. Marketing möchte das Limit für eine Startkampagne erhöhen. Ohne Workspaces würden Sie die Grant-Einstellungen patchen und riskieren, den Agenten mitten im Versand zu stören. Mit Workspaces wechseln Sie die Policy am Workspace in einem PATCH-Aufruf. Der Grant ändert sich nie. Der Agent startet nie neu. Unter 200 ms, null Ausfallzeit.

Führen Sie nylas agent account get aus, um die Workspace-Verknüpfung eines Agent Accounts zu sehen. Das Feld Workspace ID verbindet Ihre Identität mit ihrer Konfiguration:

nylas agent account get me@yourapp.nylas.email

Email:        me@yourapp.nylas.email
Provider:     nylas
Status:       valid
Workspace ID: ws_abc123

Wie erreicht eingehende E-Mail ein Agent Account?

Jemand sendet eine E-Mail an die *.nylas.email Adresse Ihres Agenten. Die Nachricht gelangt in die verwaltete Mail-Infrastruktur von Nylas, wird anhand der E-Mail-Adresse Ihrem Grant zugeordnet, lädt Ihren Workspace und wertet Rules nach Priorität aus. Wenn keine Rule blockiert, landet die Nachricht im Posteingang. Der vollständige Pfad vom externen Absender zur zugestellten Nachricht dauert bei 95 % der Nachrichten unter 3 Sekunden.

Der eingehende Pfad hat 4 Stufen:

1. MX-Auflösung — Nylas verwaltet die *.nylas.email MX-Records. Der sendende Server verbindet sich mit der Mail-Infrastruktur von Nylas, nicht mit Ihrer. Keine DNS-Konfiguration auf Ihrer Seite.
2. Grant-Zuordnung — die Empfängeradresse der Nachricht wird dem entsprechenden Grant zugeordnet. Jede Agent-Adresse wird genau einem Grant zugeordnet.
3. Policy-/Rules-Auswertung — der Workspace des Grant wird geladen, und die Policy sowie jede Rule in rules_ids[] werden nach Priorität ausgewertet. Rules passen auf Envelope-Felder: Absenderdomain, Absenderadresse, Betreffzeile.
4. Zustellung oder Blockierung — wenn eine Rule block auslöst, wird die Nachricht abgelehnt. Andernfalls landet sie im Posteingang und löst registrierte message.created Webhooks aus.

Wie verlässt ausgehende E-Mail ein Agent Account?

Ihr Agent ruft nylas email send auf oder nutzt die v3 Messages API. Die Anfrage löst Ihren aktiven Grant auf, lädt den Workspace, wertet Ihre ausgehende Policy aus und leitet die Nachricht durch die transaktionale Sende-Pipeline von Nylas. Zwei Sekunden von der Grant-Auflösung bis zum Mailserver des Empfängers.

Der ausgehende Pfad hat 4 Stufen:

1. Grant-Auflösung — das CLI löst den aktiven Agent-Account-Grant auf. Die Absenderadresse wird automatisch vom Grant übernommen — kein --from Flag nötig.
2. Workspace-Abfrage — die workspace_id des Grant wird abgerufen. Der Workspace enthält die Policy und Rules, die das ausgehende Verhalten steuern.
3. Policy-/Rules-Auswertung — ausgehende Einschränkungen und Rules werden geprüft. Wenn die Policy die Empfängerdomain beschränkt, eine Rule den Versand blockiert oder die Senderate die Limits überschreitet, wird die Anfrage abgelehnt, bevor sie SMTP erreicht.
4. Transaktionaler Versand — Nylas signiert die Nachricht mit DKIM für die *.nylas.email Domain und stellt sie an den Mailserver des Empfängers zu. Ein message.send_success Webhook wird bei Zustellung ausgelöst.

Warum ersetzt Agent Account selbst gehostete E-Mail?

Selbst gehostete E-Mail erfordert 5 separate Systeme, jedes mit Wartungs- und Sicherheitsaufwand. Laut der offiziellen Ankündigungsliste von Postfix hat der beliebteste Open-Source-MTA seit 2020 12 Sicherheitshinweise veröffentlicht. Jeder Hinweis bedeutet einen Patch, einen Neustart und einen Rauchtest. Agent Account ersetzt alle 5 Systeme mit einem API-Aufruf, der ein funktionierendes Postfach in unter 2 Sekunden bereitstellt.

Der architektonische Unterschied ist, dass Agent Account die Mail-Infrastruktur hinter eine API-Grenze verschiebt. Sie verwalten keine Daemons, Zertifikate oder DNS-Records — Sie rufen einen Endpunkt auf. Policy- und Rule-Durchsetzung findet auf der Workspace-Ebene statt, bevor Nachrichten SMTP berühren, sodass eine Prompt-Injection, die auf einen KI-Agenten abzielt, die Einschränkungen nicht umgehen kann. Für das vollständige Containment-Muster siehe Ihren KI-Agent vor unkontrolliertem Verhalten schützen.

Agent Accounts unterstützen auch eigene Domains — Sie können von Ihrer eigenen Domain statt von *.nylas.email senden und empfangen. Für schnelles Prototyping und Testautomatisierung funktioniert die verwaltete Domain sofort. Wenn Sie für Produktions-Branding bereit sind, konfigurieren Sie Ihre eigene Domain über das Nylas Dashboard.

Nächste Schritte

• Eine KI-Agent-E-Mail-Identität erstellen — praktische Schritt-für-Schritt-Anleitung: Konto erstellen, App-Passwort hinzufügen, in 2 Minuten senden und empfangen
• Agent Rules und Policies: Vollständiger Leitfaden — jeder Trigger, jede Bedingung, jeder Operator, jede Aktion und jede Policy-Einstellung mit praxisnahen Beispielen
• Ihren KI-Agent vor unkontrolliertem Verhalten schützen — eine Containment-Policy und Rules an den Workspace anhängen, bevor der Agent senden darf
• Ihrem KI-Coding-Agent eine E-Mail-Adresse geben — Claude Code, Cursor oder Codex über MCP mit einer Agent-Identität verbinden
• E-Mails ohne SMTP-Server empfangen — Webhooks, Echtzeitverarbeitung und pro Test isolierte Postfächer
• E-Mail-Kommunikation zwischen Agents — zwei Agent Accounts erstellen und strukturiertes JSON austauschen
• Beste E-Mail-Infrastruktur für KI-Agents — Agent Accounts, Provider-APIs, IMAP, SMTP, MCP und CLI-Tools vergleichen
• Vollständige Befehlsreferenz — jedes nylas agent Flag und jeder Unterbefehl
• Nylas v3 API-Dokumentation — die API-Oberfläche, in die sich Agent-Account-Grants einfügen