Codex Üzerinde Kendi Kendini Geliştiren Bir Outbound Sistemi Nasıl Kurulur

Bu yılın başlarında, Andrej Karpathy (@karpathy) bir ajanı kendi eğitim koduna yöneltti ve iki gün boyunca çalıştırdı. Ajan 700 deney yaptı, benchmark'ı geçen 20 tanesini tuttu ve modelin eğitimini %11 hızlandırdı. Ardından oldukça ilginç bir şey söyledi: ucuz bir şekilde değerlendirebileceğiniz herhangi bir metrik bir ajan sürüsüne devredilebilir.

Yanıt oranı, ucuz bir şekilde değerlendirebileceğiniz bir metriktir. Bu döngünün giden pazarlamaya yönelik nasıl görüneceğini anlamak için biraz zaman harcadım.

Benim yapım:

Codex, geçen haftanın sonuçlarını okur, giden sistemin çalıştırdığı puanlama ve oyun dosyalarını düzenler, bir test çalıştırır ve bir pull request açar. Kanıt ve puanıyla birlikte oyun kitabında bir değişiklik önerir, ardından bir insanın onaylamasını bekler. Gönderme ve birleştirme döngünün dışında kalır.

İlk döngüyü birkaç kez kurdum: pazarı hisset, hesabı puanla, sinyalden yaz, mesajı kontrol et, sonucu kaydet, yanıttan öğren. Bu makale, ilk döngüyü düzenleyen ikinci döngü hakkında.

İşte yapı bu: pazardan gelen geliştirmelerle sürümlendirilmiş kod olarak GTM (Pazara Gidiş Stratejisi).

Depo

Klasörle başlayın. Yapı önemlidir çünkü Codex yalnızca okuyup düzenleyebildiği şeyleri geliştirebilir.

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

Depo kasten basit tutulmuştur. config/scoring.yaml, hangi sinyallerin önemli olduğunu belirleyen kuralları içerir. prompts/ klasörü, mesajları yazan oyunları (plays) barındırır. memory/outcomes.jsonl, pazarın ne yaptığını tutar. evals/score.py, önerilen bir değişikliğin yardımcı olup olmadığını söyleyen geçit kapısıdır (gate). AGENTS.md, Codex'in herhangi bir şeye dokunmadan önce okuduğu yasadır.

İlk sürümü çevrimdışı çalıştırın. CRM, zenginleştirme veya dağıtım sistemi yok. Geliştirme döngüsü, gerçek bir giden makinesine yaklaşmadan önce yerel dosyalarda kendini kanıtlamalıdır.

Adım 1. Önce Yasayı Yazın

Puanlama dosyasından, komut dosyalarından önce, AGENTS.md'yi yazın. Bu dosya, ajanı kullanışlı ve sınırlı tutar.

1# Kendi Kendini Geliştiren Giden (Outbound) Kuralları
2
3Giden bir sistemi sonuçlardan yola çıkarak geliştirirsiniz.
4
5Kesin kurallar:
6- Asla mesaj gönderme.
7- Gerçek kişileri asla kazıma (scrape) veya zenginleştirme.
8- Asla kendi kendine birleştirme (self-merge) yapma.
9- Yalnızca bu depodaki dosyaları düzenle.
10- Her seferinde tek bir konsepti değiştir.
11- Her önerilen değişiklik için memory/outcomes.jsonl'deki sonuçları referans göster.
12- Bir değişiklik PR haline gelmeden önce evals/score.py'yi geliştir.
13- Değerlendirme (eval) iyileşmezse, düzenlemeni geri al ve dur.
14
15İzin verilen düzenlemeler:
16- config/scoring.yaml
17- config/plays.yaml
18- prompts/*.md
19
20Gerekli çıktı:
21- değiştirilen dosyalar
22- her değişiklik için neden
23- önceki puan
24- sonraki puan
25- pull request özeti

Yasanın tek bir işi vardır: işi daraltmak. O olmadan, Codex kapsamı genişleterek yardım etmeye çalışacaktır. Daha fazla veri ekleyecek, daha fazla dosyaya dokunacak, daha fazla araç çağıracak veya insan kontrolünde kalması gereken bir adımı otomatikleştirecektir. Burada iş daha küçüktür: sonuçları oku, tek bir dosya değişikliği öner, yardımcı olduğunu kanıtla, sonra bekle.

İyi olanın tarifi. Bir PR'yi onaylamadan önce yasayı okuyabilir ve Codex'in ne yapmasına izin verildiğini tam olarak bilirsiniz.

Nerede bozulur. Yasa bir uyumluluk belgesine dönüşür. AGENTS.md'nin bir içindekiler tablosuna ihtiyacı varsa, zaten çok büyümüştür. Operasyonel tutun.

Adım 2. Yargıyı Yapılandırmaya (Config) Taşıyın

Çoğu giden pazarlama yargısı birinin kafasında yaşar. Sonra ekip bir yazılım satın alır ve yazılımın göremediği bir kararı iyileştirmesini bekler.

Yargıyı bir dosyaya taşıyın.

1sinyaller:
2  rakip_karsilastirmasi:
3    agirlik: 8
4    neden: "alıcı alternatifleri karşılaştırıyor"
5  uygulama_sayfasi_ziyareti:
6    agirlik: 6
7    neden: "alıcı bunun kurulup kurulamayacağını kontrol ediyor"
8  is_ilani_yenileme:
9    agirlik: 5
10    neden: "rol hala açık ve acil"
11  fonlama_haberi:
12    agirlik: 5
13    neden: "bütçe veya yetki değişmiş olabilir"
14  genel_indirme:
15    agirlik: 1
16    neden: "içerik ilgisi, zayıf satın alma niyeti"
17
18esikler:
19  taslak: 6
20  insan_incelemesi: 10
21
22negatif_sinyaller:
23  ogrenci_arastirmasi: -8
24  satici_tanitimi: -6
25  rakip: -10

Bu dosya görünür bir hipotez olarak başlar. Genel bir indirmenin sıfır sayılması gerekiyorsa, ekip tam satırı işaret edip değiştirebilir. Bir uygulama sayfası ziyareti düşündüğünüzden daha güçlü bir sinyal ise, Codex farkı (diff) gösterebilir ve bunu haklı çıkaran sonuç satırlarını sunabilir.

Bu mantığı bir Python fonksiyonuna gömmeyin. Kural görünürse, ekip onu inceleyebilir, tartışabilir ve bir satış yargısını mühendislik yeniden düzenlemesine dönüştürmeden geliştirebilir.

İyi olanın tarifi. Dosya, tartışılabilecek kadar küçüktür. Beş sinyal iyi bir ilk sürümdür.

Nerede bozulur. Puanlama dosyası bir çekmeceye dönüşür. Yirmi sinyal, altı eşik ve her uç durum için istisna kuralları, iyileştiricinin aşırı uyum sağlamasına (overfit) neden olur. Dar başlayın ve sonuçların size bir sonraki düğmenin nereye ait olduğunu söylemesine izin verin.

Adım 3. Sonuçları Bellek Olarak Yazın

En önemli dosya memory/outcomes.jsonl'dir.

Her dokunuş için bir satır, sonuç bilindiğinde yazılır:

1{"tarih":"2026-07-01","hesap":"Northwind Finance","sinyal":"rakip_karsilastirmasi","oyun":"goc_notu","puan":8,"sonuc":"yanit","neden":"göç notlarını sordu"}
2{"tarih":"2026-07-01","hesap":"Bluepeak Studio","sinyal":"genel_indirme","oyun":"kaynak_takibi","puan":1,"sonuc":"yanit_yok","neden":"sadece içerik odaklı niyet"}
3{"tarih":"2026-07-02","hesap":"KiteOps","sinyal":"uygulama_sayfasi_ziyareti","oyun":"uygulama_acisi","puan":6,"sonuc":"yanit","neden":"uygulama zaman çizelgesini sordu"}
4{"tarih":"2026-07-02","hesap":"Atlas Recruiting","sinyal":"is_ilani_yenileme","oyun":"is_alin_acisi","puan":5,"sonuc":"uygunsuz","neden":"öğrenci araştırma talebi"}

Neden (reason) alanı asıl amaçtır. yanit_yok size neredeyse hiçbir şey söylemez. sadece içerik odaklı niyet, bir sonraki çalıştırmaya bu sinyalin bir taslağı hak etmeyebileceğini söyler. uygunsuz, yalnızca neden ne olduğunu açıkladığında kullanışlıdır. uygulama zaman çizelgesini sordu, bir ağırlığı değiştirebilecek türden bir ayrıntıdır.

İyileştiriciyi (improver) oluşturmadan önce doğrulayıcıyı (validator) oluşturun:

1scripts/append_outcome.py dosyasını oluşturun.
2
3Şunları kabul eder:
4- tarih
5- hesap
6- sinyal
7- oyun
8- puan
9- sonuc: yanit | toplanti | yanit_yok | uygunsuz | geri_dondu
10- neden
11
12Şunları reddeder:
13- eksik alanlar
14- bilinmeyen sonuçlar
15- boş neden
16- gelecekteki tarihler
17
18Geçerli satırları memory/outcomes.jsonl dosyasına ekleyin.
19Eklenen satırı yazdırın.

Bileşik etkinin (compounding) başladığı yer burasıdır. Bir pano (dashboard) size bir kampanyanın düştüğünü söyleyebilir. Temiz bir sonuç günlüğü (outcome log), Codex'e bir sonraki çalıştırmadan önce hangi sinyalin, oyunun veya ifadenin değişmesi gerektiğini söyleyebilir.

İyi olanın tarifi. Bir hafta sonra, bir yabancı dosyayı okuyup hangi sinyallerin yanıt yarattığını, hangi oyunların uygunsuz konuşmalar yarattığını ve pazarın hangi dahili favoriyi görmezden geldiğini söyleyebilir.

Nerede bozulur. Ekip, Cuma günü sonuçları hafızadan geriye dönük doldurur. Kazanımlar kalır, uygunsuz nedenler bulanıklaşır ve sistem kurgudan öğrenir. Sonuç geldiğinde satırı yazın.

Adım 4. Değerlendirme Geçidini (Eval Gate) Oluşturun

Codex herhangi bir şeyi düzenlemeden önce, açıklayamayacağı bir teste ihtiyacı vardır.

evals/fixtures.yaml dosyasını oluşturun:

1durumlar:
2  - hesap: Northwind Finance
3    sinyaller: [rakip_karsilastirmasi, uygulama_sayfasi_ziyareti]
4    beklenen: insan_incelemesi
5    not: "tek hesapta iki güçlü sinyal"
6
7  - hesap: Bluepeak Studio
8    sinyaller: [genel_indirme]
9    beklenen: yoksay
10    not: "sadece içerik odaklı niyet"
11
12  - hesap: KiteOps
13    sinyaller: [uygulama_sayfasi_ziyareti]
14    beklenen: taslak
15    not: "uygulama niyeti taslak eşiğini geçmeli"
16
17  - hesap: Atlas Recruiting
18    sinyaller: [is_ilani_yenileme, ogrenci_arastirmasi]
19    beklenen: yoksay
20    not: "uygunsuzluk işareti sinyali iptal eder"

Ardından evals/score.py dosyasını oluşturun:

1evals/score.py dosyasını oluşturun.
2
3config/scoring.yaml ve evals/fixtures.yaml dosyalarını okuyun.
4
5Her durum için:
61. Her sinyal için ağırlıkları topla.
72. Negatif sinyal cezalarını ekle.
83. Hesabı yönlendir:
9   - puan >= esikler.insan_incelemesi => insan_incelemesi
10   - puan >= esikler.taslak => taslak
11   - aksi halde => yoksay
124. Yönlendirmeyi beklenenle karşılaştır.
13
14Her tahmini yazdırın.
15Nihai doğruluğu score=0.00 ile score=1.00 arasında yazdırın.
16Yalnızca doğruluk 1.00 olduğunda Exit 0 ile çıkın.

İlk geçit, anlaşılabilecek kadar küçük ve gerçek bir hatayı yakalayabilecek kadar keskin olmalıdır. İlk çalıştırmamda, temel (baseline) bir durumda başarısız oldu:

1Northwind Finance: tahmin=insan_incelemesi beklenen=insan_incelemesi
2Bluepeak Studio: tahmin=yoksay beklenen=yoksay
3KiteOps: tahmin=yoksay beklenen=taslak
4Atlas Recruiting: tahmin=yoksay beklenen=yoksay
5puan=0.75

Bu iyiydi. Sistem uygulama niyetini taslak eşiğinin altında tutuyordu, bu yüzden fikstürün bir mesajı hak ettiğini söylediği bir hesabı görmezden geldi. Bunu bir aylık kaçırılan hesaptan sonra değil, bir testte yakalamak daha iyidir.

İyi olanın tarifi. Tek bir komut tek bir sayı verir ve başarısız olan her durumu incelemek kolaydır.

Nerede bozulur. Fikstür yalnızca bariz kazanımları içerir. Ardından her pervasız değişiklik geçer. Geçide çirkin durumları koyun: zayıf niyet, uygunsuzluk, yanıt yok, bayat sinyaller ve sistemin atlamış olmayı dilediğiniz hesaplar.

Adım 5. Codex'in Tek Bir Puanlama Değişikliği Önermesine İzin Verin

Şimdi Codex düzenleyebilir.

prompts/improve_scoring.md dosyasını oluşturun:

1Giden pazarlama puanlama sistemini geliştiriyorsun.
2
3Şunları oku:
4- AGENTS.md
5- config/scoring.yaml
6- memory/outcomes.jsonl
7- evals/fixtures.yaml
8
9Görevin:
101. Değişmesi gereken bir puanlama kuralı bul.
112. Gerekçe, memory/outcomes.jsonl'yi referans göstermelidir.
123. Yalnızca config/scoring.yaml dosyasını değiştir.
134. python3 evals/score.py komutunu çalıştır.
145. Puan iyileşirse, değişikliği koru.
156. Puan sabit kalır veya düşerse, değişikliğini geri al ve dur.
16
17Çıktı:
18- değiştirilen tam satır
19- buna neden olan sonuç satırları
20- önceki puan
21- sonraki puan
22- değişikliğin PR olması gerekip gerekmediği
23
24İstemleri (prompt) düzenleme.
25Yeni sinyaller ekleme.
26Dağıtıma dokunma.

Depo sarmalayıcısı (repo wrapper) aracılığıyla çalıştırın:

1scripts/run_codex_step.sh improve_scoring

İyileştiricimin ilk sürümü yararlı bir hata yaptı. En temiz görünen yanıt sinyalini kovaladı. Küçük sonuç günlüğünde rakip_karsilastirmasi en güçlü yanıt oranına sahipti, bu yüzden iyileştirici bu ağırlığı artırmak istedi. Değerlendirme 0.75'te kaldı, bu yüzden değişiklik reddedildi.

Geçidin var olmasının nedeni tam olarak budur. Daha zayıf bir sistem, kulağa makul geldiği için hikayeyi kabul ederdi. Bu sistem daha iyi bir soru sordu: değişiklik bilinen hatayı düzeltti mi?

İkinci geçiş, yardımcı olan en küçük düzenlemeyi buldu:

1- uygulama_sayfasi_ziyareti: 4
2+ uygulama_sayfasi_ziyareti: 6

Değerlendirme geçti:

1Northwind Finance: tahmin=insan_incelemesi beklenen=insan_incelemesi
2Bluepeak Studio: tahmin=yoksay beklenen=yoksay
3KiteOps: tahmin=taslak beklenen=taslak
4Atlas Recruiting: tahmin=yoksay beklenen=yoksay
5puan=1.00

Döngünün kullanışlı hale geldiği an budur. Tek bir nedenden dolayı tek bir kuralı değiştirdi ve değişikliği bir fikstüre karşı kanıtladı.

İyi olanın tarifi. Önerilen fark (diff) sıkıcı ve izlenebilirdir: bir satır değiştirilmiş, bir sonuç destekli gerekçe eklenmiş, bir değerlendirme iyileştirilmiş.

Nerede bozulur. Codex aynı anda üç ağırlık ve iki istemi değiştirir. Artık kimse hangi değişikliğin yardımcı olduğunu söyleyemez. Yasayı katı tutun: teklif başına tek bir konsept.

Adım 6. İstem Dosyalarını Ayrı Ayrı Geliştirin

Puanlama sistemin sadece yarısıdır. Mesaj şablonları da bozulur.

Geçen ay işe yarayan bir satır tanıdık gelmeye başlar. Bir segmentte yanıt getiren bir soru, diğerinde görmezden gelinir. İçeride keskin hissedilen bir ifade, pazar tarafından cezalandırılır. İstem iyileştirmeyi ayrı bir kulvar olarak ele alın, böylece Codex aynı PR'de puanlama ve metni karıştırmaz.

config/plays.yaml dosyasını oluşturun:

1oyunlar:
2  goc_notu:
3    istem_dosyasi: prompts/plays/goc_notu.md
4    ne_zaman_kullanilir:
5      - rakip_karsilastirmasi
6    yasakli_satirlar:
7      - "bunun alakalı olabileceğini düşündüm"
8      - "küçük bir sorum var"
9
10  uygulama_acisi:
11    istem_dosyasi: prompts/plays/uygulama_acisi.md
12    ne_zaman_kullanilir:
13      - uygulama_sayfasi_ziyareti
14    yasakli_satirlar:
15      - "çözümümüze göz atıyorum"
16      - "sohbet etmeyi çok isterim"

Ardından prompts/improve_prompt.md dosyasını oluşturun:

1Bir giden pazarlama oyununu geliştiriyorsun.
2
3Şunları oku:
4- AGENTS.md
5- config/plays.yaml
6- memory/outcomes.jsonl
7- seçilen oyunun istem dosyası
8
9En az 10 sonucu olan bir oyun seç.
10
11Bul:
12- olumlu sonuçlarda görünen satırlar veya yapılar
13- yanit_yok veya uygunsuz sonuçlarında görünen satırlar veya yapılar
14- yasaklanması gereken herhangi bir ifade
15
16O oyunun isteminde küçük bir düzenleme yap.
17
18Kurallar:
19- Puanlamayı değiştirme.
20- Yeni bir oyun oluşturma.
21- Yeni bir kanal ekleme.
22- Sonuç satırlarını referans göster.
23- Önceki ve sonraki talimatı yaz.
24
25Ardından varsa metin değerlendirmesini (copy eval) çalıştır.
26Metin değerlendirmesi yoksa, PR'yi review_required olarak aç.

Bazı iyileştirmeler otomatik olarak puanlanabilir. Diğerleri hala beğeni gerektirir. Metin değerlendirmesi yoksa, Codex istem düzenlemesini önerebilir, ancak düzenlemenin kanıtlandığını iddia etmek yerine PR'yi inceleme için işaretlemelidir.

İyi olanın tarifi. Codex, "Bu ifade yedi yanıt alamama sonucunda ortaya çıktı, bu yüzden yasaklı satırlara ekledim" veya "olumlu yanıtlar birinci cümledeki uygulama detayını alıntıladı, bu yüzden oyunu bunu gerektirecek şekilde sıkılaştırdım" der.

Nerede bozulur. İyileştirici, tek bir mesaj yanıt aldığı için tüm sesi yeniden yazar. İstem düzenlemeleri içgüdünüzden daha küçük olmalıdır.

Adım 7. Değişiklikleri Pull Request Olarak Gönderin

Bu kontrol katmanıdır. Codex dosyaları düzenler, değerlendirmeyi çalıştırır ve PR özetini yazar. Bir insan inceler ve birleştirir.

prompts/pr_summary.md dosyasını oluşturun:

1Bu giden pazarlama iyileştirmesi için bir pull request özeti yaz.
2
3Şunları ekle:
41. Ne değişti.
52. Neden değişti, sonuç satırlarını referans göstererek.
63. Önceki puan.
74. Sonraki puan.
85. Değiştirilen dosyalar.
96. Risk.
107. İnsan inceleyicinin neyi kontrol etmesi gerektiği.
11
12Kısa tut.
13Değişikliğin canlı olduğunu iddia etme.

scripts/open_pr.sh dosyasını oluşturun:

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

PR, bir takım arkadaşı tarafından yazılmış gibi okunmalıdır:

1Değişen:
2- uygulama_sayfasi_ziyareti 4'ten 6'ya yükseltildi.
3
4Nedeni:
5- KiteOps, uygulama sayfası niyeti gösterdi ve uygulama zamanlaması ile yanıt verdi.
6- Önceki puan bu hesabı yoksay olarak yönlendirdi.
7
8Önce:
9- değerlendirme puanı 0.75
10
11Sonra:
12- değerlendirme puanı 1.00
13
14İnceleyici kontrolü:
15- Uygulama niyetinin yeterince spesifik olduğundan emin olun.
16- Genel indirmeleri düşük tutun.
17- Yalnızca gerçek satış yargısıyla eşleşiyorsa birleştirin.

Güvenlik sistemi budur. Codex sıkıcı işi yapar. Operatör standardı korur.

İyi olanın tarifi. Haftada bir PR, küçük fark, net neden, geçen değerlendirme.

Nerede bozulur. Birisi, inceleme sürtüşme gibi hissettirdiği için Codex'e birleştirme izni verir. O bir dakika, gelişen bir sistemi sürüklenen bir sistemden ayırır.

Adım 8. Bir Düzene (Cadence) Koyun

Her yanıttan sonra bunu çalıştırmayın. Bu, bir sistemin tek bir gürültülü hesaba aşırı uyum sağlamasına neden olur.

Haftanın geçmesine izin verin, sonuçların birikmesine izin verin, ardından ayarlayın.

scripts/weekly_tune.sh dosyasını oluşturun:

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

Ardından cron:

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

GitHub Actions kullanıyorsanız, aynı yapıyı koruyun:

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

İlk iki ayarı elle çalıştırın. Her farkı okuyun. Örneklem küçükken Codex'in neyi değiştirmeye çalıştığını izleyin. Teklifler sıkıcı hale geldiğinde, bir programa koyun.

İyi olanın tarifi. Kanıt, fark ve değerlendirme sonucuyla birlikte haftalık bir PR görünür. Birleştirir, düzenler veya kapatırsınız.

Nerede bozulur. İş çalışır, kimse incelemez ve PR'ler yığılır. Kendi kendini geliştiren bir sistemin hala bir insan alışkanlığı vardır: farkı oku.

Klonla ve Çalıştır Sürümü

Depo dört komutla birlikte gelmelidir:

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

Beklenen ilk çalıştırma:

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

Çevrimdışı demo, dosya sözleşmelerini kanıtlar. Codex çalıştırması, düzenleme döngüsünü kanıtlar. Bundan sonra, örnek sonuçları kendi sonuçlarınızla değiştirin, sinyalleri yeniden adlandırın, oyunlarınızı ekleyin ve sistemin farklı şekilde yönlendirmiş olmayı dilediğiniz hesapları yansıtan bir fikstür oluşturun.

Dağıtımı kablolayarak başlamayın. Geliştirme döngüsünü kanıtlayarak başlayın.

Tam Sürüm: max

Bu depo manuel katmandır. Dosyalardan, herkese açık sinyallerden ve Codex planınızdan çalışır. Her kural açık olduğu için şekli öğretir.

yourmax.ai aynı sistemdir, ancak dikişler gizlidir.

Kendinizin bir araya getirdiği bir depo yerine max, doğrudan kullandığınız ajandır. Pazardaki hareketi algılar, kiminle ve neden şimdi iletişime geçmeye değer olduğuna karar verir, e-posta ve LinkedIn üzerinden onayınız için taslak mesajlar oluşturur ve sonuçlardan sürekli olarak iyileşir.

Depo, çoğu ekibin asla inşa etmediği kendi kendini ayarlama katmanını gösterir: sonuçlar önerilen kural değişiklikleri haline gelir, önerilen kural değişiklikleri bir geçitten geçer ve insan birleştirmesi neyin canlı olacağına karar verir. max, aynı işletim mantığını alır ve yönetilen bir sistem olarak çalıştırır.

Tam depoyu isterseniz, bana bildirin ve size göndereyim.