So bauen Sie ein selbstoptimierendes Outbound-System auf Codex

Anfang dieses Jahres ließ Andrej Karpathy (@karpathy) einen Agenten auf seinen eigenen Trainingscode los und ließ ihn zwei Tage lang laufen. Der Agent führte 700 Experimente durch, behielt die 20, die die Benchmark übertrafen, und sorgte dafür, dass das Modell 11 % schneller trainierte. Dann sagte er etwas ziemlich Interessantes: Jede Metrik, die man günstig auswerten kann, kann man einem Agenten-Schwarm übergeben.

Die Antwortrate ist eine Metrik, die man günstig auswerten kann. Ich habe seitdem etwas Zeit damit verbracht, herauszufinden, wie diese Schleife aussieht, wenn man sie auf ausgehende Kommunikation anwendet.

Mein Aufbau:

Codex liest die Ergebnisse der letzten Woche, bearbeitet die Scoring- und Play-Dateien, die das ausgehende System verwendet, führt einen Test durch und erstellt einen Pull-Request. Es schlägt eine Änderung am Playbook vor, mit den Belegen und der Bewertung, und wartet dann auf die Freigabe durch einen Menschen. Senden und Zusammenführen bleiben außerhalb der Schleife.

Ich habe die erste Schleife ein paar Mal aufgebaut: den Markt erfassen, das Konto bewerten, aus dem Signal schreiben, die Nachricht prüfen, das Ergebnis protokollieren, aus der Antwort lernen. In diesem Artikel geht es um die zweite Schleife, diejenige, die die erste bearbeitet.

Das ist der Aufbau: GTM als versionierter Code, der sich durch den Markt verbessert.

Das Repository

Beginnen Sie mit dem Ordner. Die Struktur ist wichtig, weil Codex nur das verbessern kann, was es lesen und bearbeiten kann.

1codex-self-improving-outbound/
2  AGENTS.md
3  README.md
4  config/
5    scoring.yaml
6    plays.yaml
7  prompts/
8    improve_scoring.md
9    improve_prompt.md
10    pr_summary.md
11  memory/
12    outcomes.jsonl
13  evals/
14    fixtures.yaml
15    score.py
16  scripts/
17    append_outcome.py
18    run_codex_step.sh
19    propose_improvement.py
20    open_pr.sh
21    weekly_tune.sh
22  examples/
23    outcomes.sample.jsonl
24    weekly-pr.md

Das Repository ist bewusst einfach gehalten. config/scoring.yaml enthält die Regeln, die entscheiden, welche Signale wichtig sind. prompts/ enthält die Plays, die die Nachrichten verfassen. memory/outcomes.jsonl enthält, was der Markt gemacht hat. evals/score.py ist das Tor, das sagt, ob eine vorgeschlagene Änderung geholfen hat. AGENTS.md ist das Gesetz, das Codex liest, bevor es irgendetwas anfasst.

Führen Sie die erste Version offline aus. Kein CRM, keine Anreicherung, kein Zustellsystem. Die Verbesserungsschleife sollte sich zuerst an lokalen Dateien beweisen, bevor sie in die Nähe einer echten ausgehenden Maschine kommt.

Schritt 1: Schreiben Sie zuerst das Gesetz

Bevor Sie die Scoring-Datei schreiben, bevor Sie die Prompt-Dateien schreiben, schreiben Sie AGENTS.md. Dies ist die Datei, die den Agenten nützlich und begrenzt hält.

1# Regeln für selbstverbessernde ausgehende Kommunikation
2
3Sie verbessern ein ausgehendes System anhand von Ergebnissen.
4
5Feste Regeln:
6- Senden Sie niemals Nachrichten.
7- Scrapen oder reichern Sie niemals echte Personen an.
8- Führen Sie niemals Selbst-Merges durch.
9- Bearbeiten Sie nur Dateien in diesem Repository.
10- Ändern Sie immer nur ein Konzept auf einmal.
11- Zitieren Sie für jede vorgeschlagene Änderung Ergebnisse aus memory/outcomes.jsonl.
12- Verbessern Sie evals/score.py, bevor eine Änderung zu einem PR werden kann.
13- Wenn sich die Bewertung nicht verbessert, machen Sie Ihre Bearbeitung rückgängig und hören Sie auf.
14
15Erlaubte Bearbeitungen:
16- config/scoring.yaml
17- config/plays.yaml
18- prompts/*.md
19
20Erforderliche Ausgabe:
21- geänderte Dateien
22- Grund für jede Änderung
23- Bewertung vorher
24- Bewertung nachher
25- Zusammenfassung des Pull-Requests

Das Gesetz hat eine Aufgabe: die Arbeit einzugrenzen. Ohne sie wird Codex versuchen zu helfen, indem es den Umfang erweitert. Es wird mehr Daten hinzufügen, mehr Dateien anfassen, mehr Tools aufrufen oder einen Schritt automatisieren, der unter menschlicher Kontrolle bleiben sollte. Hier ist die Aufgabe kleiner: Ergebnisse lesen, eine Dateiänderung vorschlagen, beweisen, dass sie geholfen hat, und dann warten.

Wie es gut aussieht. Sie können das Gesetz lesen, bevor Sie einen PR genehmigen, und wissen genau, was Codex tun durfte.

Wo es bricht. Das Gesetz wird zu einem Compliance-Dokument. Wenn AGENTS.md ein Inhaltsverzeichnis braucht, ist es bereits zu umfangreich. Halten Sie es operativ.

Schritt 2: Verlagerung der Bewertung in die Konfiguration

Die meiste Bewertung für ausgehende Kommunikation lebt im Kopf von jemandem. Dann kauft das Team Software und erwartet, dass die Software eine Entscheidung verbessert, die sie nicht sehen kann.

Verlagern Sie die Bewertung in eine Datei.

1signals:
2  competitor_comparison:
3    weight: 8
4    reason: "Käufer vergleicht Alternativen"
5  implementation_page_visit:
6    weight: 6
7    reason: "Käufer prüft, ob dies installiert werden kann"
8  job_repost:
9    weight: 5
10    reason: "Stelle ist noch offen und dringend"
11  funding_event:
12    weight: 5
13    reason: "Budget oder Mandat könnte sich geändert haben"
14  generic_download:
15    weight: 1
16    reason: "Inhaltsinteresse, schwache Kaufabsicht"
17
18thresholds:
19  draft: 6
20  human_review: 10
21
22negative_signals:
23  student_research: -8
24  vendor_pitch: -6
25  competitor: -10

Diese Datei beginnt als sichtbare Hypothese. Wenn ein generischer Download null zählen sollte, kann das Team auf die genaue Zeile zeigen und sie ändern. Wenn ein Besuch der Implementierungsseite ein stärkeres Signal ist als gedacht, kann Codex den Diff vorschlagen und die Ergebniszeilen zeigen, die ihn rechtfertigen.

Vergraben Sie diese Logik nicht in einer Python-Funktion. Wenn die Regel sichtbar ist, kann das Team sie überprüfen, darüber diskutieren und verbessern, ohne eine Vertriebsbewertung in ein Engineering-Refactoring zu verwandeln.

Wie es gut aussieht. Die Datei ist klein genug, um darüber zu diskutieren. Fünf Signale sind eine gute erste Version.

Wo es bricht. Die Scoring-Datei wird zur Rumpelkammer. Zwanzig Signale, sechs Schwellenwerte und Ausnahmeregeln für jeden Randfall führen dazu, dass der Verbesserer überangepasst ist. Fangen Sie eng an und lassen Sie die Ergebnisse Ihnen sagen, wo der nächste Regler hingehört.

Schritt 3: Ergebnisse als Gedächtnis schreiben

Die wichtigste Datei ist memory/outcomes.jsonl.

Eine Zeile pro Kontakt, geschrieben, wenn das Ergebnis bekannt ist:

1{"date":"2026-07-01","account":"Northwind Finance","signal":"competitor_comparison","play":"migration_note","score":8,"outcome":"reply","reason":"hat nach Migrationsnotizen gefragt"}
2{"date":"2026-07-01","account":"Bluepeak Studio","signal":"generic_download","play":"resource_followup","score":1,"outcome":"no_reply","reason":"nur Inhaltsinteresse"}
3{"date":"2026-07-02","account":"KiteOps","signal":"implementation_page_visit","play":"implementation_angle","score":6,"outcome":"reply","reason":"hat nach Implementierungszeitplan gefragt"}
4{"date":"2026-07-02","account":"Atlas Recruiting","signal":"job_repost","play":"hiring_angle","score":5,"outcome":"bad_fit","reason":"Anfrage für studentische Forschung"}

Das Feld „reason" ist der springende Punkt. „no_reply" sagt Ihnen fast nichts. „nur Inhaltsinteresse" sagt dem nächsten Durchlauf, dass dieses Signal vielleicht keinen Entwurf verdient. „bad_fit" ist nur nützlich, wenn der Grund erklärt, warum. „hat nach Implementierungszeitplan gefragt" ist die Art von Detail, die ein Gewicht ändern kann.

Bauen Sie den Validator, bevor Sie den Verbesserer bauen:

1Erstellen Sie scripts/append_outcome.py.
2
3Es akzeptiert:
4- date
5- account
6- signal
7- play
8- score
9- outcome: reply | meeting | no_reply | bad_fit | bounced
10- reason
11
12Es lehnt ab:
13- fehlende Felder
14- unbekannte Outcomes
15- leere Begründung
16- Daten in der Zukunft
17
18Hängen Sie gültige Zeilen an memory/outcomes.jsonl an.
19Geben Sie die angehängte Zeile aus.

Hier beginnt der Zinseszinseffekt. Ein Dashboard kann Ihnen sagen, dass eine Kampagne schwächelt. Ein sauberes Ergebnisprotokoll kann Codex sagen, welches Signal, welcher Play oder welche Formulierung sich vor dem nächsten Durchlauf ändern sollte.

Wie es gut aussieht. Nach einer Woche kann ein Fremder die Datei lesen und erkennen, welche Signale Antworten erzeugt haben, welche Plays zu Gesprächen mit schlechtem Fit geführt haben und welche internen Favoriten der Markt ignoriert hat.

Wo es bricht. Das Team füllt die Ergebnisse am Freitag aus dem Gedächtnis nach. Die Erfolge überleben, die Gründe für den schlechten Fit verschwimmen, und das System lernt aus Fiktion. Schreiben Sie die Zeile, wenn das Ergebnis eintrifft.

Schritt 4: Das Bewertungstor bauen

Bevor Codex irgendetwas bearbeitet, braucht es einen Test, den es nicht wegdiskutieren kann.

Erstellen Sie evals/fixtures.yaml:

1cases:
2  - account: Northwind Finance
3    signals: [competitor_comparison, implementation_page_visit]
4    expected: human_review
5    note: "zwei starke Signale bei einem Konto"
6
7  - account: Bluepeak Studio
8    signals: [generic_download]
9    expected: ignore
10    note: "nur Inhaltsinteresse"
11
12  - account: KiteOps
13    signals: [implementation_page_visit]
14    expected: draft
15    note: "Implementierungsabsicht sollte Schwellenwert für Entwurf überschreiten"
16
17  - account: Atlas Recruiting
18    signals: [job_repost, student_research]
19    expected: ignore
20    note: "Schlechter-Fit-Marker hebt das Signal auf"

Erstellen Sie dann evals/score.py:

1Erstellen Sie evals/score.py.
2
3Lesen Sie config/scoring.yaml und evals/fixtures.yaml.
4
5Für jeden Fall:
61. Summieren Sie die Gewichte für jedes Signal.
72. Fügen Sie Strafen für negative Signale hinzu.
83. Ordnen Sie das Konto zu:
9   - score >= thresholds.human_review => human_review
10   - score >= thresholds.draft => draft
11   - sonst => ignore
124. Vergleichen Sie die Zuordnung mit der erwarteten.
13
14Geben Sie jede Vorhersage aus.
15Geben Sie die endgültige Genauigkeit als score=0.00 bis score=1.00 aus.
16Beenden Sie nur mit 0, wenn die Genauigkeit 1.00 ist.

Das erste Tor sollte klein genug sein, um es zu verstehen, und scharf genug, um einen echten Fehler zu erkennen. In meinem ersten Durchlauf fiel die Basislinie in einem Fall durch:

1Northwind Finance: predicted=human_review expected=human_review
2Bluepeak Studio: predicted=ignore expected=ignore
3KiteOps: predicted=ignore expected=draft
4Atlas Recruiting: predicted=ignore expected=ignore
5score=0.75

Das war gut. Das System hatte die Implementierungsabsicht unter dem Schwellenwert für Entwürfe, also ignorierte es ein Konto, das laut Fixture eine Nachricht verdient hätte. Besser, das in einem Test zu erwischen als nach einem Monat mit verpassten Konten.

Wie es gut aussieht. Ein Befehl gibt eine Zahl aus, und jeder fehlgeschlagene Fall ist leicht zu überprüfen.

Wo es bricht. Die Fixture enthält nur offensichtliche Erfolge. Dann besteht jede rücksichtslose Änderung. Fügen Sie hässliche Fälle in das Tor ein: schwache Absicht, schlechter Fit, keine Antwort, veraltete Signale und die Konten, bei denen Sie sich gewünscht hätten, das System hätte sie übersprungen.

Schritt 5: Codex eine Scoring-Änderung vorschlagen lassen

Jetzt kann Codex bearbeiten.

Erstellen Sie prompts/improve_scoring.md:

1Sie verbessern das Scoring-System für ausgehende Kommunikation.
2
3Lesen Sie:
4- AGENTS.md
5- config/scoring.yaml
6- memory/outcomes.jsonl
7- evals/fixtures.yaml
8
9Ihre Aufgabe:
101. Finden Sie eine Scoring-Regel, die geändert werden sollte.
112. Der Grund muss Ergebnisse aus memory/outcomes.jsonl zitieren.
123. Ändern Sie nur config/scoring.yaml.
134. Führen Sie python3 evals/score.py aus.
145. Wenn sich die Bewertung verbessert, behalten Sie die Änderung.
156. Wenn die Bewertung gleich bleibt oder sinkt, machen Sie Ihre Änderung rückgängig und hören Sie auf.
16
17Ausgabe:
18- die genaue geänderte Zeile
19- die Ergebniszeilen, die die Änderung verursacht haben
20- Bewertung vorher
21- Bewertung nachher
22- ob die Änderung ein PR werden sollte
23
24Bearbeiten Sie keine Prompts.
25Fügen Sie keine neuen Signale hinzu.
26Fassen Sie keine Zustellung an.

Führen Sie es über den Repository-Wrapper aus:

1scripts/run_codex_step.sh improve_scoring

Die erste Version meines Verbesserers machte einen nützlichen Fehler. Es jagte dem saubersten Antwortsignal hinterher. competitor_comparison hatte die stärkste Antwortrate im winzigen Ergebnisprotokoll, also wollte der Verbesserer dieses Gewicht erhöhen. Die Bewertung blieb bei 0,75, also wurde die Änderung abgelehnt.

Genau deshalb gibt es das Tor. Ein schwächeres System hätte die Geschichte akzeptiert, weil sie vernünftig klang. Dieses stellte eine bessere Frage: Hat die Änderung den bekannten Fehler behoben?

Der zweite Durchlauf fand die kleinste Bearbeitung, die half:

1- implementation_page_visit: 4
2+ implementation_page_visit: 6

Die Bewertung bestand:

1Northwind Finance: predicted=human_review expected=human_review
2Bluepeak Studio: predicted=ignore expected=ignore
3KiteOps: predicted=draft expected=draft
4Atlas Recruiting: predicted=ignore expected=ignore
5score=1.00

Das ist der Moment, in dem die Schleife nützlich wird. Es änderte eine Regel, aus einem Grund, und bewies die Änderung anhand einer Fixture.

Wie es gut aussieht. Der vorgeschlagene Diff ist langweilig und nachvollziehbar: eine Zeile geändert, ein ergebnisgestützter Grund angehängt, eine Bewertung verbessert.

Wo es bricht. Codex ändert drei Gewichte und zwei Prompts auf einmal. Jetzt kann niemand mehr sagen, welche Änderung geholfen hat. Halten Sie das Gesetz streng: ein Konzept pro Vorschlag.

Schritt 6: Prompt-Dateien separat verbessern

Scoring ist nur die Hälfte des Systems. Auch die Nachrichtenvorlagen veralten.

Eine Zeile, die letzten Monat funktioniert hat, klingt jetzt vertraut. Eine Frage, die in einem Segment Antworten erhält, wird in einem anderen ignoriert. Ein Satz, der sich intern scharf anfühlt, wird vom Markt bestraft. Behandeln Sie die Prompt-Verbesserung als separaten Bereich, damit Codex nicht Scoring und Text im selben PR vermischt.

Erstellen Sie config/plays.yaml:

1plays:
2  migration_note:
3    prompt_file: prompts/plays/migration_note.md
4    use_when:
5      - competitor_comparison
6    banned_lines:
7      - "dachte, das könnte relevant sein"
8      - "kurze Frage"
9
10  implementation_angle:
11    prompt_file: prompts/plays/implementation_angle.md
12    use_when:
13      - implementation_page_visit
14    banned_lines:
15      - "schauen Sie sich unsere Lösung an"
16      - "würde mich über ein Gespräch freuen"

Erstellen Sie dann prompts/improve_prompt.md:

1Sie verbessern einen ausgehenden Play.
2
3Lesen Sie:
4- AGENTS.md
5- config/plays.yaml
6- memory/outcomes.jsonl
7- die Prompt-Datei für den ausgewählten Play
8
9Wählen Sie einen Play mit mindestens 10 Ergebnissen.
10
11Finden Sie:
12- Zeilen oder Strukturen, die in positiven Ergebnissen vorkommen
13- Zeilen oder Strukturen, die in no_reply- oder bad_fit-Ergebnissen vorkommen
14- jeden Satz, der verboten werden sollte
15
16Nehmen Sie eine kleine Bearbeitung am Prompt dieses Plays vor.
17
18Regeln:
19- Ändern Sie nicht das Scoring.
20- Erstellen Sie keinen neuen Play.
21- Fügen Sie keinen neuen Kanal hinzu.
22- Zitieren Sie Ergebniszeilen.
23- Schreiben Sie die Anweisung vorher und nachher.
24
25Führen Sie dann die Kopie-Bewertung aus, falls vorhanden.
26Wenn keine Kopie-Bewertung existiert, öffnen Sie den PR als review_required.

Einige Verbesserungen können automatisch bewertet werden. Andere erfordern immer noch Fingerspitzengefühl. Wenn es keine Kopie-Bewertung gibt, kann Codex die Prompt-Bearbeitung vorschlagen, sollte den PR jedoch zur Überprüfung markieren, anstatt so zu tun, als wäre die Bearbeitung bewiesen.

Wie es gut aussieht. Codex sagt: „Dieser Satz kam in sieben No-Reply-Ergebnissen vor, also habe ich ihn zu banned_lines hinzugefügt", oder „Positive Antworten zitierten das Implementierungsdetail in Satz eins, also habe ich den Play gestrafft, um das zu verlangen."

Wo es bricht. Der Verbesserer schreibt die gesamte Stimme neu, weil eine Nachricht eine Antwort erhalten hat. Prompt-Bearbeitungen sollten kleiner sein als Ihr Instinkt.

Schritt 7: Änderungen als Pull-Requests ausliefern

Dies ist die Kontrollebene. Codex bearbeitet Dateien, führt die Bewertung aus und schreibt die PR-Zusammenfassung. Ein Mensch überprüft und führt zusammen.

Erstellen Sie prompts/pr_summary.md:

1Schreiben Sie eine Pull-Request-Zusammenfassung für diese Verbesserung der ausgehenden Kommunikation.
2
3Fügen Sie hinzu:
41. Was geändert wurde.
52. Warum es geändert wurde, unter Zitierung von Ergebniszeilen.
63. Bewertung vorher.
74. Bewertung nachher.
85. Geänderte Dateien.
96. Risiko.
107. Was der menschliche Prüfer überprüfen sollte.
11
12Halten Sie es kurz.
13Behaupten Sie nicht, dass die Änderung live ist.

Erstellen Sie scripts/open_pr.sh:

1#!/usr/bin/env bash
2set -euo pipefail
3
4branch="codex/weekly-tune-$(date +%Y-%m-%d)"
5
6git checkout -b "$branch"
7git add config prompts evals memory
8git commit -m "Codex wöchentlicher Outbound-Tune"
9
10body="$(cat outputs/pr-summary.md)"
11
12python3 scripts/create_pr.py \
13  "$branch" \
14  "Codex wöchentlicher Outbound-Tune" \
15  "$body"

Der PR sollte sich lesen, als hätte ihn ein Teammitglied geschrieben:

1Geändert:
2- implementation_page_visit von 4 auf 6 erhöht.
3
4Warum:
5- KiteOps hatte Implementierungsseiten-Absicht und antwortete mit Implementierungszeitplan.
6- Die vorherige Bewertung ordnete dieses Konto „ignore" zu.
7
8Vorher:
9- Bewertung 0.75
10
11Nachher:
12- Bewertung 1.00
13
14Prüfer-Check:
15- Stellen Sie sicher, dass die Implementierungsabsicht spezifisch genug ist.
16- Halten Sie generische Downloads niedrig.
17- Nur zusammenführen, wenn dies der tatsächlichen Vertriebsbewertung entspricht.

Das ist das Sicherheitssystem. Codex erledigt die mühsame Arbeit. Der Betreiber behält den Standard.

Wie es gut aussieht. Ein PR pro Woche, kleiner Diff, klarer Grund, bestandene Bewertung.

Wo es bricht. Jemand gibt Codex die Erlaubnis zum Zusammenführen, weil sich die Überprüfung wie Reibung anfühlt. Diese Minute trennt ein System, das sich verbessert, von einem System, das abdriftet.

Schritt 8: Auf einen Rhythmus bringen

Führen Sie dies nicht nach jeder Antwort aus. So passt sich ein System an ein einziges lautes Konto an.

Lassen Sie die Woche geschehen, lassen Sie Ergebnisse sich ansammeln, dann justieren Sie.

Erstellen Sie scripts/weekly_tune.sh:

1#!/usr/bin/env bash
2set -euo pipefail
3
4cd "$(dirname "$0")/.."
5
6python3 evals/score.py || true
7scripts/run_codex_step.sh improve_scoring
8python3 evals/score.py
9scripts/run_codex_step.sh pr_summary > outputs/pr-summary.md
10scripts/open_pr.sh

Dann cron:

10 8 * * MON cd ~/codex-self-improving-outbound && scripts/weekly_tune.sh

Wenn Sie GitHub Actions verwenden, behalten Sie die gleiche Form:

1name: weekly-outbound-tune
2
3on:
4  schedule:
5    - cron: "0 8 * * 1"
6  workflow_dispatch:
7
8jobs:
9  tune:
10    runs-on: ubuntu-latest
11    steps:
12      - uses: actions/checkout@v4
13      - uses: actions/setup-python@v5
14        with:
15          python-version: "3.11"
16      - run: pip install -r requirements.txt
17      - run: python3 evals/score.py || true
18      - run: scripts/weekly_tune.sh

Führen Sie die ersten beiden Tune-Ups manuell durch. Lesen Sie jeden Diff. Beobachten Sie, was Codex zu ändern versucht, wenn die Stichprobe dünn ist. Sobald die Vorschläge langweilig sind, setzen Sie es auf einen Zeitplan.

Wie es gut aussieht. Ein wöchentlicher PR erscheint mit den Belegen, dem Diff und dem Bewertungsergebnis. Sie führen ihn zusammen, bearbeiten ihn oder schließen ihn.

Wo es bricht. Der Job läuft, niemand überprüft, und PRs häufen sich. Ein selbstverbesserndes System hat immer noch eine menschliche Angewohnheit: Lesen Sie den Diff.

Die Klon-und-Ausführen-Version

Das Repository sollte mit vier Befehlen ausgeliefert werden:

1git clone <repo>
2cd codex-self-improving-outbound
3python3 -m venv .venv
4source .venv/bin/activate
5pip install -r requirements.txt
6python3 evals/score.py
7python3 scripts/propose_improvement.py

Erwarteter erster Durchlauf:

1score=0.75
2changed config/scoring.yaml
3implementation_page_visit: 4 -> 6
4score=1.00
5open PR for human review

Die Offline-Demo beweist die Dateiverträge. Der Codex-Durchlauf beweist die Bearbeitungsschleife. Danach ersetzen Sie die Beispielergebnisse durch Ihre eigenen, benennen die Signale um, fügen Ihre Plays hinzu und bauen eine Fixture, die die Konten widerspiegelt, bei denen Sie sich gewünscht hätten, das System hätte sie anders eingestuft.

Beginnen Sie nicht damit, die Zustellung zu verdrahten. Beginnen Sie damit, die Verbesserungsschleife zu beweisen.

Die Vollversion: max

Dieses Repository ist die manuelle Ebene. Es läuft von Dateien, öffentlichen Signalen und Ihrem Codex-Plan. Es lehrt die Form, weil jede Regel offenliegt.

yourmax.ai ist dasselbe System mit verborgenen Nähten.

Anstelle eines Repositorys, das Sie selbst zusammenschalten, ist max der Agent, den Sie direkt verwenden. Es erkennt Bewegungen im Markt, entscheidet, wer kontaktiert werden sollte und warum jetzt, entwirft die Kontaktaufnahme per E-Mail und LinkedIn zur Genehmigung und verbessert sich kontinuierlich aus den Ergebnissen.

Das Repository zeigt die Selbstjustierungsebene, die die meisten Teams nie bauen: Ergebnisse werden zu vorgeschlagenen Regeländerungen, vorgeschlagene Regeländerungen durchlaufen ein Tor, und der menschliche Merge entscheidet, was live geht. max nimmt dieselbe Betriebslogik und führt sie als verwaltetes System aus.

Wenn Sie das vollständige Repository möchten, lassen Sie es mich wissen, und ich schicke es Ihnen zu.