Bağlantı kurulduğunda hangi iş tamamlanacak?
Satış destek ekibi müşteri talebini CRM'de, sipariş durumunu ERP'de görüyor. Yapay zekâ bu bilgileri birleştirip yanıt hazırlayabilir. Fakat iki kaydın doğru eşleştiği, hangi alanın güncel olduğu ve neyin değiştirilebileceği belirlenmeden bağlantı kurmak yeni belirsizlikler yaratır. Başlangıç görevinizi küçük tutun: doğru siparişi okumak ve CRM içinde insan incelemesine hazır bir yanıt taslağı oluşturmak. Sipariş değiştirme veya mesaj gönderme bu göreve kendiliğinden dahil olmaz.
Bu uygulamadaki sistemler, kayıtlar ve izinler tamamen sentetiktir. Canlı ERP veya CRM bağlantısı yapılmaz. Çıktı teknik ekibin kullanabileceği bir iş ve test dosyasıdır; belirli bir ürünün API kurulum rehberi değildir. Gerçek entegrasyonda seçilen ürün sürümünün yetki, kayıt ve hata davranışı ayrıca doğrulanmalıdır. Burada hangi bilgilerin uygulama ekibine verilmesi gerektiğini, tamamlanmış küçük bir örnek üzerinden göreceğiz.
Aynı müşteri, aynı sipariş demek değildir
| Kaynak | Alan | Değer |
|---|---|---|
| CRM C-71 / V5 | Talep | Siparişimin kalan ürünleri ne zaman gelecek? |
| CRM C-71 / V5 | Doğrulanmış sipariş ilişkisi | O-204; aynı kurum hesabına ait |
| ERP O-204 / V8 | Sipariş miktarı | 10 adet |
| ERP O-204 / V8 | Sevk edilen | 6 adet |
| ERP O-204 / V8 | Kalan ve tarih | 4 adet; kesin sevk tarihi yok |
Müşteri adının benzemesi kayıt ilişkisi kurmak için yeterli değildir. Bu örnekte CRM talebiyle ERP siparişi arasındaki ilişki doğrulanmış olarak verilmiştir. Gerçek sistemde bu ilişkinin hangi kimlikten geldiği ve kullanıcıya hangi kaydın gösterilebileceği açıklanmalıdır. Birden fazla eşleşme varsa model en olası siparişi seçerek yanıt üretmez. Kayıt sahibi veya yetkili kullanıcı ilişkiyi netleştirir; belirsiz eşleşme normal akıştan ayrı sonuçlanır.
ERP'deki ‘6 sevk edildi’ bilgisi müşterinin altı ürünü teslim aldığı anlamına gelmez. Aynı şekilde kalan dört ürün için tarihin boş olması ‘bugün’ veya ‘gecikme yok’ demek değildir. Sistemlerin durum sözlüklerini birbirine çevirmek gerekir. Veri sözleşmesinde her alanın anlamı, kaynağı ve güncellik bilgisi bulunmalıdır. Modelin akıcı bir müşteri cümlesi üretmesi, bu anlam farklarını otomatik çözmüş sayılmaz.
Her alana aynı yazma yetkisini vermeyin
| Alan / işlem | Kaynak sahibi | Bu pilotun izni | Kontrol |
|---|---|---|---|
| Sipariş miktarı ve sevk | ERP / operasyon | Okuma | Doğru sipariş ve güncel sürüm |
| Talep ve kayıt ilişkisi | CRM / destek | Okuma | Kimlik ve erişim doğrulaması |
| Yanıt taslağı | CRM / destek | Taslak alanına yazma | Kaynak sürümü ve taslak durumu |
| Sipariş miktarı / tarih değişikliği | ERP / yetkili operasyon | Yok | Ayrı iş kararı gerekir |
| Müşteriye gönderim | İletişim akışı / yetkili kişi | Yok | Ayrı onay ve işlem kaydı |
Anthropic'in ajan açıklaması, araç sonuçlarının sonraki adımları yönlendirmesini ve durma koşullarını ele alır. Bu entegrasyon sözleşmesi özgün bir eğitim uygulamasıdır.Kaynak: Anthropic — Building effective agents
Taslak alanına yazma izni düşük etkili görünse de hangi kayda ve hangi koşulla yazılacağı belli olmalıdır. Başka bir çalışan C-71'i güncellediyse eski bilgiyle onun düzenlemesini ezmemek gerekir. Kaynak sürümünü kontrol etmek ve çakışmada yeniden değerlendirmek bu yüzden önemlidir. Aynı mantık ERP verisinin okunması ile CRM taslağının kaydedilmesi arasında sipariş durumunun değişmesi için de geçerlidir. İki sistemde aynı anda güncellik garantisi varmış gibi anlatılmamalıdır.
Akışı ara sonuçlarıyla yazın
- CRM talebinin kimliğini, erişimini ve sipariş ilişkisini doğrula.
- ERP siparişini verilen izinle oku; alan anlamlarını ve kaynak sürümünü kaydet.
- Verilen olgulardan yanıt taslağını ve açık bilgileri oluştur.
- CRM sürümü hâlâ uygunsa taslak alanına kaydet; işlem sonucunu doğrula.
- İnsan incelemesine hazır durumunu göster; müşteri gönderimi yapma.
O-204 siparişinde 10 adedin 6'sı sevk edilmiş, 4'ü bekliyor. Kalan miktar için kesin sevk tarihi kayıtta bulunmuyor; operasyon sorumlusundan teyit gerekiyor. [ERP V8] CRM hedefi: C-71 taslak alanı; okunan sürümV5. Durum: insan incelemesine hazırlanmış beklenen metin. Sevk, teslim alma olarak yazılmadı. Gerçek kayıt veya gönderim yapılmadı.
Akışta ‘kaydet’ çağrısının kabul edilmesi her zaman son kaydın tamamlandığını göstermez. Kullanılan sistemin yanıt sözleşmesi incelenmelidir. Zaman aşımında ilk yazmanın gerçekleşip gerçekleşmediği belirsizse körlemesine tekrar yapmak ikinci taslak veya çakışma üretebilir. İş kimliğiyle sonucu sorgulama veya yetkili incelemeye bırakma yolu tasarımda yer alır. Mevcut kabul edildi/tamamlandı ve tekrar işlem yazıları bu ayrıntıları somut örneklerle açıklar.
Mutlu yolun yanına beş farklı durumu koyun
| Vaka | Beklenen davranış |
|---|---|
| V1: Doğru ilişki, izin ve sürüm | Kaynaklı taslak kaydına ilerle; dış gönderim yok |
| V2: Sipariş ilişkisi eksik | Açıklama veya kayıt sahibi incelemesi; tahmini eşleşme yok |
| V3: Kullanıcı siparişe yetkisiz | ERP içeriği bağlama ve taslağa girmez |
| V4: ERP'de tarih boş | Tarih üretme; açık bilgiyi göster |
| V5: CRM sürümü değişmiş | Eski sürümle üzerine yazma; yeniden değerlendir |
| V6: Kayıt isteği zaman aşımına uğramış | Sonucu doğrula; bilinmeyen durumda kör tekrar yok |
Bunlar uygulanmış test sonuçları değildir; teknik denemede kontrol edilecek beklenen davranışlardır. Test ortamı üretimden ayrı, veriler sentetik ve dış gönderim kapalı olmalıdır. Her vakada yalnız ekrandaki mesaj değil, sistemde oluşan son kayıt da incelenir. V3'te kullanıcıya ‘erişim yok’ yazarken kapalı içeriğin taslak alanına kaydedilmesi kabul edilmez. Benzer şekilde V5'in uyarı mesajı doğruyken eski kaydın üstüne yazılmış olması da başarısızlıktır.
İlk entegrasyon toplantısına bu dosyayla girin
Girdi: C-71/V5, O-204/V8, izin tablosu ve V1–V6. Görev: adım, kaynak, çıktı, yetki ve hata yolunu eşleştir. Sevki teslim alma yapma; boş tarihe değer ekleme. CRM taslağı dışında işlem yetkisi üretme. Çıktı: entegrasyon çalışma notu ve test anahtarı. Kontrol: belirsiz eşleşme, eski sürüm ve belirsiz işlem sonucu ayrı kapanmalı.
Küçük alıştırma: Taslak hazırlanırken ERP'de sevk miktarı sekize çıksın ve yeni sürüm V9 oluşsun. Yeni olgu 2 adet kaldığıdır; kesin tarih hâlâ yoksa bu alan açık kalır. Eski V8 taslağını güncel yanıt diye sunmayın. Kaynak tekrar okunur, CRM'deki mevcut taslak ve sürüm kontrol edilir, uygun yeni taslak insan incelemesine hazırlanır. Bu değişiklik müşteri gönderimi için yeni bir yetki oluşturmaz.
Dosyanın sonunda veri sahipleri, gerekli sistem yetkileri ve kabul kanıtları bulunmalıdır. Uygulama ekibi bu bilgileri ürünün gerçek API davranışına çevirebilir. Süreç sahibi ise başarılı işin ne olduğunu takip edebilir. Bu iki bakış aynı kayıtta buluştuğunda entegrasyon projesi yalnız bağlantı kurma işi olmaktan çıkar; hangi kullanıcı için hangi bilginin hangi sınırda kullanılacağını açıklayan bir iş uygulamasına dönüşür.
Kaynaklar ve doğrulama
- Anthropic — Building effective agents
Önceden tanımlanmış akış ile modelin adım ve araç seçimini yönlendirdiği ajan ayrımı. 2024 yazısının kavramsal ayrımı kullanılır; güncel araç listesi önerisi yapılmaz.
Erişim ve kontrol:
AI Ajanları ve İş Akışı Otomasyonu
AI Ajanları ve İş Akışı Otomasyonu programı için hangi sistemin hangi alanı yönettiğini ve dış işlem sınırını yazın. Eğitim talebinizde gerçek sistem erişimi paylaşmadan akışın girdisini ve beklenen çıktısını tarif edebilirsiniz.
- Kuruma özel planlanır