Bir agent dağıtılıyor. İlk demosu etkileyici. Sonra gerçek kullanımda bir şeyler ters gidiyor — yanlış karar alıyor, yanlış öncelik seçiyor, bağlam dışı bir şey yapıyor. İlk tepki genellikle aynı: "Model yeterince iyi değil."
Model değişiyor. Prompt ince ayar alıyor. Bazen düzeliyor. Çoğunlukla aynı sorun farklı biçimlerde geri geliyor.
Sorun modelde değil.
Geçen ay kendi iş akışımda küçük bir deney yaptım. Müşteri destek ticketlarından içgörü çıkaran bir agent kurdum — haftalık rapor üretsin, öne çıkan şikayetleri sınıflandırsın. İlk çıktı beni şaşırttı: agent, gerçekte en sık tekrar eden sorunu değil, en "dramatik" dil kullanan şikayetleri öne çıkarıyordu.
Model mi hatalıydı? Hayır. Ona "önemli şikayetleri bul" demişim. "Önemli" kelimesini benim gibi tanımlaması için hiçbir neden yoktu.
Bağlamı ben yanlış kurmuştum.
Şu an pek çok ekip benzer bir döngüde. Agent yanlış davranıyor → prompt yeniden yazılıyor → agent biraz daha iyi davranıyor → farklı bir durumda yine yanlış davranıyor. Bu döngü bitmez, çünkü köke inilmiyor.
Kökteki sorun şu: ürün ekiplerinin büyük çoğunluğunun "başarı" ve "öncelik" tanımları, bir insanın anlayabileceği ama bir agent'ın kullanabileceği biçimde yazılmış değil.
"Kullanıcı memnuniyetini artır." "Kritik hataları önce çöz." "Yüksek değerli müşterilere odaklan."
Bunlar strateji. Ama agent için bunlar boş kelime.
Burada PM'in işi gerçekten değişiyor.
Önceki model şuydu: PM bir şeylerin yapılmasını koordine eder, engineering nasıl yapacağını bilir. Artık koordinasyon kısmı otomasyona gidiyor. Geriye "ne yapılacak"ı tanımlamak kalıyor — ama tanımlama biçimi de değişmek zorunda.
Bir insana "şu müşteri segmentine odaklan" diyebilirsin, bağlamı zamanla dolduruverir. Agent için bu cümle başlangıç noktası bile değil.
Agent'ın kullanılabilir kararlar alması için şunların hazır olması gerekiyor: Hangi sinyaller önceliği etkiler? Çatışan hedefler arasında hangisi üstün? Hangi durum "normal" sayılır? Hangi veri güvenilir, hangi veri gürültü?
Bu liste PM'e ait. Başka kimseye ait değil.
Medibulut'ta bunu somut yaşadım. Farklı branşlara hizmet eden üç ürün — diş hekimleri, genel sağlık klinikleri, diyetisyenler — tek codebase üzerinde. Bir agent'a "en sık talep edilen özellikleri bul" demek yeterli değil. Çünkü diş hekiminin talebinin önceliği ile diyetisyenin talebinin önceliği aynı formülle değerlendirilemez. Segment büyüklüğü, gelir etkisi, churn riski, teknik maliyet — bunların ağırlıkları bağlama göre değişiyor.
Agent bunu benden öğrenemez. Ben yazmasam, o tahmin eder. Tahmin ettiğinde de genellikle en gürültülü sinyale yöneliyor — en dramatik şikayet, en fazla tekrar eden talep, en uzun ticket.
Buna "bağlam mimarisi" diyorum. (Kelime biraz akademik duruyor ama daha iyi karşılık bulamadım.)
Basitçe şu: agent'larla çalışan ekipler, kararlarının arkasındaki mantığı belgeleyen bir alışkanlık geliştirmek zorunda. Bu sadece "neden" sorusu değil — "hangi koşulda farklı davranılır" sorusu.
Bir yazılı kaynak olması bile yeterli. Ama o kaynak yoksa, her yeni agent kurulumunda aynı sorunla baştan yüzleşiyorsunuz.
Model performansı son iki yılda dramatik bir şekilde arttı. Ama ekiplerin karar belgelemedeki kalitesi aynı hızda artmadı.
Bu fark kapanmadıkça agent başarısızlıkları devam eder — ve "model yeterince iyi değil" yanlış teşhisi de devam eder.
Doğru soru şu değil: "Daha iyi bir model var mı?"
Doğru soru: "Agent'a neyi bilmesi gerektiğini gerçekten anlattık mı?"