Yapay zekâ, son dönemde yalnızca model geliştirme odaklı bir alan olmaktan çıkarak, gerçek dünya süreçlerine entegre edilen sistemler bütününe dönüşmeye başladı. Geçmişte bir yapay zekâ mühendisi için derin öğrenme modellerinin temelleri, CNN–RNN mimarileri, optimizasyon algoritmaları, veri işleme teknikleri ve klasik makine öğrenmesi yaklaşımları ön plandaydı. Bu konular bugün hâlâ önemini koruyor; ancak odak noktası artık farklı bir yere kaymış durumda. 

Günümüz yapay zekâ ekosistemi, “modeli nasıl eğitiriz?” sorusundan çok, “bu modeli nasıl çalışır bir sisteme dönüştürürüz?” sorusu etrafında şekilleniyor. Yani mesele yalnızca akıllı bir model üretmek değil; bu modeli karar alabilen, aksiyon üretebilen ve süreçlere entegre olabilen yapılara dönüştürmek. 

Bu noktadan sonra teorik bilgiyi, pratik sistem tasarımıyla birleştirmek gerekiyor. Agent kavramı ve agent orkestrasyonu tam olarak bu ihtiyacın sonucunda ortaya çıkıyor. 

Yapay Zekâyı Yönetmek Ne Anlama Gelir? 

Son yıllarda sıkça duyduğumuz "komut mühendisliği," yapay zekâ sistemlerini yönlendirmenin ilk adımlarından biri olarak öne çıkmıştır. Temel olarak bu yaklaşım, yapay zekâya doğru soruları sorarak, modelin sahip olduğu bilgiyi daha etkili biçimde kullanmayı amaçlamaktadır. 

Ancak zamanla önemli bir sorun ortaya çıkmıştır: Yapay zekâyı etkin biçimde yönlendirebilmek için, yön verilen alan hakkında belirli bir hâkimiyete sahip olmak gerekmektedir. Aksi takdirde, kullanıcı farkında olmadan modeli yanlış yönlendirebilir ve ortaya çıkan sonuçlar güvenilirliğini kaybedebilir. Bu durum, yalnızca soru sormaya dayalı yaklaşımların sınırlı olduğunu açık biçimde göstermektedir. 

Komut Mühendisliğinden Bağlam Mühendisliğine Geçiş 

Son yıllarda, yalnızca tek seferlik komutlar aracılığıyla yapay zekâ sistemlerini yönlendirmeye dayanan “komut mühendisliği” yaklaşımının, sektör ihtiyaçlarını tam anlamıyla karşılamadığı görülmüştür. Bu nedenle, daha kapsamlı ve sürdürülebilir bir çerçeve sunan “bağlam mühendisliği” kavramı ön plana çıkmaya başlamıştır. Bağlam mühendisliği, yapay zekâ uygulamalarının hangi ortamda, hangi amaç doğrultusunda ve hangi sınırlar içerisinde çalışacağını ayrıntılı biçimde tanımlamayı hedeflemektedir. Böylece, sistemlerin yalnızca anlık komutlara yanıt veren yapılar olmaktan çıkarılması, bunun yerine bütünsel bir işleyiş çerçevesi içinde hareket etmeleri sağlanmaktadır. 

Bağlamın doğru şekilde oluşturulması, yapay zekâ sistemlerinin öngörülebilir, kontrol edilebilir ve güvenilir biçimde çalışmasının önünü açmaktadır. Bu yaklaşım sayesinde, yapay zekâ yalnızca yanıt üreten bir araç olmaktan çıkarak, belirli bir kurumsal hedefe hizmet eden dijital bir yardımcıya dönüşmektedir. Böylelikle, yapay zekâ teknolojileri iş süreçlerine entegre edildiğinde, kurumların beklentilerine uygun güvenilir ve etkili çözümler sunulabilmektedir. 

Bu çerçevede, LangChain tabanlı yazılım süreçlerinde de bağlam mühendisliği yaklaşımının önemi giderek artmaktadır. Bir sonraki bölümde, bu kapsamda geliştirilen yazılım bileşenlerinin bütüncül olarak nasıl orkestre edilebileceği ele alınacaktır. 

Agent Nedir ve Neden Var? 

Yapay zekâ, ChatGPT’nin 2022 yılında yayınladığı büyük dil modeli ile uzun süredir devam eden durağan dönemden yavaşça çıkmaya başladı. Burada ana kavramı gözden kaçırmamak önemlidir: Yapay zekâ, günümüzde herkesin dilinde olan büyük dil modellerinden ibaret değildir. Konunun daha iyi anlaşılması için aşağıda bir diyagram paylaşıyorum, inceleyebilirsiniz. 

Resim 1: Yapay Zekâ, LLM ve Agent Mimarisi Diyagramı  

Nerede kalmıştık. ChatGPT sayesinde önümüzde geniş bir fırsat penceresi açılmıştı. Ardından birçok yapay zekâ şirketi bu fırsatı değerlendirerek sektördeki konumunu sağlamlaştırmaya çalıştı. Bu süreç, esas olarak büyük dil modeli (LLM) teknolojilerinin gelişmesine ve bu modelleri temel alan yeni girişimlerin ve projelerin ortaya çıkmasına zemin hazırladı. 

Kullanım alanları genişledikçe, sistemin yetersizlikleri de giderek belirginleşmeye başladı. LLM modelleri, bir girdi karşısında yalnızca bir çıktı üretmekle sınırlı kalıyordu; yani metin girdisiyle metin çıktısı almak artık yeterli olmamaya başladı. Burada pek çok sorun ortaya çıktı: güncel veriye erişim eksikliği, çıktının yalnızca metin formatında sunulması (eylem gerçekleştirme ihtiyacının karşılanamaması), elde edilen yanıtların güvenilir olmaması gibi çeşitli kısıtlar söz konusu oldu. 

Bu noktada devreye, yalnızca bilgiyi işleyen bir “beyin” olmaktan çıkıp, bağımsız olarak karar verebilen ve aksiyon alabilen yazılım bileşenleri giriyor; yani agentlar. LLM’in tek başına gerçekleştiremediği asıl işlev tam olarak buydu: sadece veri analiz ediyordu, fakat dış dünyaya müdahalede bulunamıyordu. Agent mimarisi ise LLM’e bir fiziksel varlık kazandırarak, çevresini algılayabilen, hedefler belirleyebilen, plan oluşturabilen ve bu planı uygulamak için eyleme geçebilen otonom bir sistem hâline getiriyor. Artık LLM, gerekli olduğunda web üzerinde arama yapabiliyor, bir sistemde işlem gerçekleştirmesi gerektiğinde API çağrısı yapabiliyor, bir araştırmayı derinleştirmek için kendi kendine döngü kurabiliyor; kısacası “ara, uygula, getir” diyebileceğimiz bir akla sahip oluyor. Böylece pasif bir sohbet aracı olmaktan çıkıp, aktif olarak görevleri yerine getiren dijital bir çalışan hâline geliyor. 

Daha teknik bir ifadeyle, bir Agent; çevresinden aldığı girdileri (sensör verileri, kullanıcı talepleri, sistem çıktıları, web tabanlı bilgiler gibi) işleyerek, bu verileri belirlenmiş bir hedef doğrultusunda analiz eden ve ardından uygun aksiyonları seçip uygulayabilen otonom bir yazılım modülüdür. Burada, LLM yalnızca bu yapının “bilişsel” katmanını oluştururken; agent mimarisi, bu temel üzerine bellek (hafıza), araçlar (fonksiyonel modüller), planlama birimi, yürütme katmanı ve geri bildirim mekanizması ekleyerek tamamen otonom şekilde aksiyona geçebilen, karar alabilen ve kendi başına görevleri tamamlayabilen bütünsel bir sistem haline getirir. 

Agentlar Birlikte Güçlü 

Aslında teoride bakıldığında ortada bir sorun kalmıyor; agent, işleri üstlenir, üzerimizdeki yükü alır ve süreçleri bizim adımıza otomatikleştirir. Ancak uygulamaya geçildiğinde önemli bir gerçek ortaya çıkıyor: tek bir agent çoğu zaman yeterli olmuyor. Çünkü karmaşık iş problemleri genellikle birden fazla uzmanlık alanı, farklı araç setleri ve birbirinden bağımsız alt görevlerin koordinasyonunu gerektiriyor. Tek bir agent ile tüm bu işleri yürütmeye çalışmak sistemi hem yavaşlatıyor hem de hata oranını artırıyor. Bunun yerine, tıpkı gerçek bir ekipte olduğu gibi, birden fazla agent’ın birlikte çalışması ve birbirinden devraldığı görevlerle bir orkestrasyon oluşturması gerekiyor. Örneğin, araştırma yapan bir agent, bu araştırmanın sonucunu işleyen başka bir agent ve elde edilen çıktıyı değerlendiren ayrı bir agent olabilir. 

Bundan sonraki bölümde daha çok teknik detaylar ve kod örnekleriyle ilerleyeceğiz. Bu süreçte Langchain platformunu kullanacağız. Langchain’in ne olduğunu merak ediyorsanız aşağıdaki bağlantıdan detaylarına ulaşabilirsiniz. 

LangChain Dokümantasyonu: https://docs.langchain.com/ 

Kısaca özetlemek gerekirse, Langchain; odağında agent geliştirmek olan ve bu amaçla farklı yazılım çerçeveleri (framework) sunan bir teknoloji şirketidir. Deepagent, Langchain ve LangGraph gibi açık kaynak kodlu framework’leri mevcuttur. Şimdi agent mimarisine geçelim: 

Resim 2: Yapay Zekâ, LLM ve Agent Mimarisi Diyagramı  

Agent’in Temel Bileşenleri 

Bir agent tasarlamak istediğinizde karşınıza temel olarak iki ana unsur çıkar. Birincisi, agent’a işlevsellik kazandıran “Araç (Tool)”, ikincisi ise doğrudan agent’ın kendisidir, yani “Agent”. 

Araç (Tool): Agent’ların işlem ve hareket kabiliyeti kazanmasını sağlayan, fonksiyon tabanlı yazılım modülleridir. 

Agent: Agent’ın kendisini ifade eder. Araçları kullanarak, kullanıcının sağladığı girdilere göre çıktı üretir ve bu çıktıları sistemin hedeflerine uygun şekilde işler. 

Langchain’de Araç Tanımlama 

Langchain üzerinde bir araç tanımlayabilmek için öncelikle ilgili paketlerin kurulumu gerekmektedir. Burada Python SDK’sını kullanacağım; dilerseniz TypeScript SDK’yı da tercih edebilirsiniz. 

pip install -U langchain 

Gerekli ana paketi yükledikten sonra, ana kodunuzu yazmak üzere main.py isminde bir dosya oluşturabilirsiniz: 

Resim 3: kod örneği 

Tool dekoratörü ile oluşturduğumuz fonksiyonu, agent için bir araç olarak tanımlıyoruz. Araç (tool) içerisinde yer alan açıklama satırları büyük önem taşıyor; çünkü agent bünyesindeki büyük dil modeli (LLM), bu aracı kullanıp kullanmayacağına dair kararını, bu açıklamalara bakarak veriyor. Şimdi, birkaç farklı araç (tool) daha geliştirelim. 

Resim 4: kod örneği 

Divizyon kullanıcı kayıt aracı olarak bir aracımız daha olsun; burada amacım, araçları (tool) ihtiyacınıza göre farklı alanlarda özelleştirebileceğinizi göstermek. İlk aracımız web araması gerçekleştirirken, ikincisi dosya kaydedebilecek, belki üçüncüsü veri analizi yapacak şeklinde çeşitlendirilebilir. Temel mantığı kavramanız açısından bu önemli. 

Bir araç geliştirirken edindiğim bazı teknik ipuçlarını sizlerle paylaşmak isterim: Araç tanımı esasen bir fonksiyondur ve bu fonksiyonda yapılan her işlemin hata ile sonuçlanabileceğini göz önünde bulundurarak tasarım yapılmalıdır. Yazılım geliştirmede olduğu gibi “Hata Yönetimi” (Error Handling) yapısına araç tanımlarken de titizlikle yaklaşmak gerekir. Aksi takdirde, agent gerekli aracı çağırdıktan sonra beklenen sonucu alamazsa sürekli tekrar denemeler yapacak, hatalı yolları araştıracak ve bu durum modelin işletim maliyetini artıracaktır. Bu nedenle, hata yönetimi oldukça önemlidir. Bir diğer önemli husus ise, geliştirdiğiniz araçların amacı ve kapsamının net bir şekilde belirlenmesidir; bir aracın birden fazla işi üstlenmesi yazılım mimarisine aykırıdır. Her araç kendi işlevini tam olarak yerine getirebilmeli ve bağımsız çalışabilmelidir. Böylelikle agent, aracı kullanırken çıktı formatını öngörebilir ve buna uygun bir yanıt üretebilir. 

Araçlardan Agentlara 

Artık elimizde çeşitli fonksiyonel modüller (araçlar) mevcut; şimdi bu modülleri kullanacak olan Agent’ın tanımlanmasına geçelim. İlk adım olarak, gerekli olan model yapısının oluşturulması gerekmektedir. 

Model oluşturma aşamasında, Langchain’in sunduğu herhangi bir servis sağlayıcıyı (provider) tercih edebilirsiniz. Ben bu örnekte Gemini modelini kullanacağım. 

Resim 5: kod örneği-model tanımlama 

Model tanımı oldukça yalın bir şekilde yapılabilir; burada hangi servis sağlayıcısının (provider) hangi modeli kullanacağı, modelin üreteceği çıktının doğruluk ve açıklık düzeyi ile max_tokens, timeout gibi çeşitli parametrelerle yapılandırılması mümkündür. Agent, temel olarak Büyük Dil Modeli’ne (LLM) işlevsellik kazandırmayı hedefler. Dolayısıyla, sahip olduğunuz araçların (tool) amaç ve kapsamına göre seçeceğiniz modelin özellikleri de kritik önem taşır. Bu konuya ilerleyen bölümlerde tekrar değineceğiz. 

Resim 6: kod örneği 

Agent oluşturmak için create_agent fonksiyonunu kullanacağız ve bazı parametreler tanımlayacağız. Öncelikle, daha önce belirlediğimiz araçlar (tools) ve bu araçları kullanacak olan LLM modeli (Büyük Dil Modeli) gerekmektedir. Sonrasında ise aşağıda sıralanan kritik parametreler devreye giriyor: 

Agent oluştururken belirtebileceğiniz en önemli parametrelerden biri system_prompt yani sistem yönlendirmesi. Bu prompt, agent’ın genel tutumunu, rolünü ve hedef davranış biçimini tanımlar. Sağlam bir yönlendirme yapılmazsa, agent tamamen modele bağlı olarak hareket eder ve tutarsız sonuçlar ortaya çıkabilir. 

Sonrasında ara katman (middleware) yapısı devreye girer. Middleware’ler adeta bir agent’ın “trafik kontrolcüsü” gibi çalışır; model çağrısından önce veya sonra davranışları değiştirebilir, araç çağrılarını yönlendirebilir, loglama (kayıt tutma) ekleyebilir veya özel bir durum yönetimi sağlayabilir. 

Bir diğer önemli parametre yanıt formatı (response_format)dır. Burada agent’ın yapılandırılmış bir çıktı üretmesini talep edebilirsiniz. Örneğin, JSON biçimi, özel bir Pydantic modeli veya daha gelişmiş otomatik/strateji tabanlı yönlendirmeler. Bu parametre verildiğinde agent, modelden gelen cevabı bu formata uyarlamaya çalışır. 

Ardından durum şeması (state_schema) ve bağlam şeması (context_schema) gelir. Bunlar, ölçeklenebilir sistemlerde kritik öneme sahiptir; çünkü agent’ın çalışma sürecinde tuttuğu durumu özelleştirmenize imkan tanır. Ara katmanlarla birleştiğinde, çoklu agent yapılarında “her agent kendi durumunu bilir” prensibini hayata geçirmiş olursunuz. 

interrupt_before ve interrupt_after parametreleri ise agent’ın belirli noktalarda durmasını, kullanıcıdan onay almasını veya özel bir tetikleyici çalıştırmasını sağlamak için kullanılır. Örneğin, bir “silme” işlemi gerçekleştirecek araç çağrısından önce durup kullanıcıya “emin misiniz?” sorusunu yöneltebilirsiniz. 

Tüm bu parametreler bir araya geldiğinde create_agent fonksiyonu, ilgili yapılandırmalar doğrultusunda tam anlamıyla işlevsel bir agent grafı oluşturur. Model, mesajlar üretir; bu mesajlara istinaden araçları çağırır, araç sonuçlarını tekrar modele gönderir ve bu döngü araç çağrısı tamamlanıncaya kadar devam eder. 

Buraya kadar geldiyseniz, artık agent kavramını biliyor ve araçlarla besleyebiliyorsunuz. İhtiyaçlar doğrultusunda onlarca agent ve onlarca araç oluşturmanız gerekebilir. Bunun en sade örneği, geçtiğimiz günlerde üzerinde çalıştığım bir projede karşınıza çıkıyor. Aşağıya bırakıyorum: onlarca araç ve bu araçları yöneten agentlar ile onları yöneten bir üst agent (supervisor). Evet, doğru okudunuz; agentları yöneten de bir agent var (denetleyici agent). 

Resim 7: kod mimari yapısı  

Resim 8: Supervisor agent mimarisi 

Bu agent'a farklı araçlar (tool) ile çeşitli yetkinlikler kazandırmıştık; ancak hâlâ eksik kalan bazı unsurlar mevcut. Neler eksik olabilir? 

Günlük çalışma hayatında, bir projede ana odağı farklı olan, çeşitli uzmanlık alanlarına sahip kişilerle ortak bir çıktıya ulaşmak hedeflenir. Örneğin, bir web platformu geliştirirken bir ekip üyesi ön yüz (frontend), bir diğer ekip üyesi arka uç (backend), bir başkası ise devops alanında uzmanlaşmış olabilir. Fark ettiyseniz, ortak bir hedefe ulaşmak için farklı bilgi ve becerilere sahip kişiler bir araya gelerek iş birliği içinde çalışır. 

Buradan tekrar agent mimarisine dönecek olursak; elimizde yalnızca tek bir agent olursa, örneğin sadece ön yüz geliştirme görevini üstlenebilir veya sadece arka uç geliştirme işlevini yerine getirebilir. Fakat birden fazla, alanında uzmanlaşmış agent tanımlanırsa, projenin tam anlamıyla istenen çıktısını elde etmek mümkün olur. Birden fazla uzmanlık alanına sahip agent ile daha profesyonel ve kapsamlı bir sonuç üretmek mümkündür. Ancak... 

Birden fazla agent yapısı, birden fazla sorumluluk anlamına gelir. Tek bir uzmanlık alanına sahip agent'ları birbiriyle iletişime geçirmek, onları yönetmek ve yönlendirmek gerekir ki nihai çıktı beklentilere uygun şekilde elde edilebilsin. Bu kadar ön bilgi yeterli diyorsanız, şimdi Multi-Agent Yapısına geçebiliriz. 

Resim 9: alt agent sistemi 

Multi-Agent Yapısı Nedir? 

Birden fazla agent’ın iş birliğiyle ortak bir hedefe ulaşmasını sağlayan sistematik bir yapıdır. Temelinde, bütüncül bir çözüm elde etmek için farklı ve özelleşmiş agent’ların bir arada çalışması fikri yatar. Böyle bir yapı, alanında uzmanlaşmış agent’ları koordineli şekilde bir araya getirerek daha kapsamlı ve verimli sonuçlar üretmeyi amaçlar. 

Langchain platformunda bu tarz bir yapı kurmak için, öncelikle ilgili kütüphanelerin eksiksiz şekilde kurulması gerekir. 

pip install -U langchain 

Gerekli paketin kurulmasının ardından, ihtiyaç duyulan temel bileşenleri oluşturmaya başlayabiliriz. Daha önce de belirttiğim gibi, bir yazılım geliştirme sürecinde çoklu agent mimarisi kurgulayacaksak, atomik yapıların ötesine geçmemiz gerekir. Bu nedenle, öncelikle kullanılacak araçları (tool) tanımlamak önemlidir. 

İlerleyen süreçte sorun yaşamamak ve sürdürülebilir bir multi-agent mimarisi kurmak adına, genellikle tercih ettiğim dosya yapısını aşağıda bulabilirsiniz. 

Resim 10:kod örneği 

Tools (Araçlar) klasörüne göz attığımızda, her bir agent için birden fazla araç tanımını dikkate alarak aşağıdaki gibi yapılandırılmış bir dizin oluşturmak daha uygun ve kurumsal bir yaklaşım olacaktır. 

Resim 11: kod örneği 

Bu araçlardan bazılarını daha yakından inceleyelim. Örneğin, API aracı bizim için ne anlama geliyor, hangi yeteneklere sahip? 

Resim 12: kod örneği 

İçerisinde yer alan örnek bir araç, RESTful API uç noktalarını (endpoint) otomatik olarak tasarlamaktadır. 

Bir diğer araca geçelim; Frontend agentının kullanacağı tasarım araçları arasında yer alan suggest_layout_improvement aracını inceleyelim. 

Resim 13: kod örneği 

Bu araç, sayfa ve bileşen (React tabanlı uygulamalar için özelleştirilmiş) düzenini analiz ederek, kullanıcıya iyileştirme önerileri sunmaktadır. 

Artık araçların temel işlevlerini ve sınırlarını daha net kavrayabildik. Şimdi ise bu araçlara işlev kazandıracak ve onları aktif olarak kullanacak olan agent yapılarına göz atalım. 

Backend agentına daha yakından baktığımızda, önceki yazıda da ele aldığımız temel bileşenlerle agent’ımızı oluşturduğumuzu görüyoruz. Bu bileşenler; agent’ın operasyonlarında kullanacağı araçlar ile bu araçları etkin şekilde kullanabilmesini sağlayacak Büyük Dil Modeli (LLM) yapılandırmasından oluşmaktadır. 

Resim 14: kod örneği 

Tool ve LLM (Büyük Dil Modeli) mimarisini kavradıysak, burada kritik bir noktaya daha değinmek isterim. Agent'lar, işlevlerini yalnızca araçlar (tool) üzerinden kavrayan yapılar değildir; bu noktada hâlâ gelişime açıktır. Agent'ın görev ve yetki alanının netleşmesi için, yönlendirici ve rol belirleyici bir yapı gerekmektedir. İşte bu noktada, system_prompt devreye girer. System_prompt, agent'ın üstleneceği rolü, kapsamını ve sınırlarını açıkça tanımlayan bir komut dizisidir. Örneğin aşağıdaki gibi bir betik ile agent'ın görev tanımını ve sorumluluklarını kurumsal bir şekilde belirleyebilirsiniz: 

Resim 15: kod örneği 

Bu system_prompt sayesinde, LLM’in hangi görevleri yerine getirip hangilerini gerçekleştiremeyeceği net şekilde tanımlanmış olur. Ayrıca, isterseniz bu bölümde örnek bir sohbet geçmişi (chat history) oluşturarak modele ek yönlendirmeler de sağlayabilirsiniz. Bunlar, uygulama sırasında dikkat edilmesi gereken önemli detaylar olup, ileride talep olması halinde tekrar ele alınabilir. Şimdi sürece devam edelim. 

Resim 16: kod örneği 

İlgili araçları, Büyük Dil Modeli (LLM) yapılandırmasını ve sistem yönlendirme komutlarını aktardıktan sonra, backend agentımızı kurmuş oluyoruz. Aynı prensiple diğer agentları da geliştirebilirsiniz. Şimdi ise DeepAgent’a geçelim. 

Supervisor Agentını Tanımlayalım 

Supervisor agent, şimdiye kadar oluşturduğumuz agentları yöneten üst düzey bir agent olarak görev yapar. Kurumsal iş yaşamında, bu agentı bir ürün yöneticisi (product manager) gibi düşünebilirsiniz; her katılımcıya görevlerini dağıtan ve çıktıları takip eden sorumlu bir yapı. Supervisor agentı geliştirirken, standart agent tanımlama sürecinden farklı bir yöntem izlemeyeceğiz. Buradaki temel fark, araçlarımızın (tool) aslında agentlardan oluşacak olmasıdır. 

Supervisor agent için bir Frontend araç tanımı aşağıda örneklenmiştir: 

Resim 17: kod örneği 

Bu tanımlamada dikkat edilmesi gereken husus, aracın (tool) arka planda bir agent çağrısı (agent çağrısı) gerçekleştirerek ilgili agent’tan aldığı yanıtı (response) geri döndürmesidir. Şimdi, backend tool tanımına daha yakından bakalım. 

Resim 18: kod örneği 

Şimdi, bu araçları çağıran üst düzey denetleyici (supervisor) yapılandırmasında kullanılan yönlendirme komutunun (prompt) teknik ve kurumsal terimlerle Türkçeleştirilmiş halini inceleyelim: 

Resim 19: kod örneği 

Burada göz önünde bulundurulması gereken kritik bir husus mevcut: Eğer denetleyici ajan (supervisor agent) yeterince açık ve sistematik bir şekilde yönlendirilmezse, diğer agentlar iş süreçlerini verimli şekilde yürütemez. Bu sebeple, dosya ekinde görebileceğiniz gibi (ilgili ekran görüntüsünü inceleyebilirsiniz), sistem komutu (system_prompt) yaklaşık 150 satırdan oluşan, detaylı ve kapsamlı bir tanımlamaya sahiptir. Denetleyici agentın; kimlerin hangi görevleri üstlendiğini, sistemin işleyiş mantığını ve izlenmesi gereken adımları eksiksiz biçimde bilmesi gerekmektedir. 

Böylelikle, sürecin sonunda araç → agent → üst düzey agent (superagent) yapılandırmalarının nasıl olması gerektiğini bütüncül bir yaklaşımla ele almış olduk. 

Daha fazla teknik detay ve kapsamlı bilgi edinmek isterseniz, mesaj göndererek bana ulaşabilirsiniz. Sorularınızı memnuniyetle yanıtlamaktan mutluluk duyarım.