AI agent’larda asıl darboğaz zeka değil, kontrol yüzeyi

AI agent ekosisteminde tartışmaların büyük bölümü hâlâ model katmanı etrafında dönüyor. Daha iyi model, daha uzun context window, daha güçlü reasoning, daha düşük latency, daha iyi benchmark skorları… Son iki yılda oluşan genel anlatı, sanki agent kalitesini belirleyen ana unsurun model zekâsı olduğu yönünde. Bu yüzden birçok ekip agent inşa etmeye model seçimiyle başlıyor ve çoğu zaman aynı yerde sıkışıyor: “Daha iyi model kullanırsak bu iş çözülür mü?”

Kısa cevap şu: Kısmen evet, ama asıl mesele bu değil.

Gerçek hayatta çalışan agent sistemlerinde farkı yaratan şey çoğu zaman modelin ne kadar akıllı olduğu değil, sistemin ne kadar kontrol edilebilir olduğudur. Hatta birçok durumda zeka seviyesi belirli bir eşiği geçtikten sonra marjinal değer hızla düşer; buna karşılık kontrol yüzeyi zayıfsa, en güçlü model bile güvenilemez bir bileşene dönüşebilir.

Çünkü production ortamında problem sadece doğru cevabı üretmek değildir. Problem aynı zamanda o cevabın hangi bağlam içinde üretildiğini, hangi verilere dayanarak üretildiğini, hangi araçların kullanıldığını, hangi sınırlar içinde hareket edildiğini ve hata anında sistemin nasıl davranacağını yönetmektir. Başka bir ifadeyle, bir agent’ın değerini yalnızca düşünme kapasitesi değil, davranışının yönetilebilirliği belirler.

Burada “kontrol yüzeyi” derken kastettiğim şey, agent’ın gerçek dünyada güvenli, izlenebilir ve sürdürülebilir biçimde çalışmasını sağlayan operasyonel katmandır. Bu katman genellikle model demosunda görünmez. Ama sistem gerçek kullanıcı, gerçek veri, gerçek maliyet, gerçek risk ve gerçek süreçlerle buluştuğunda en kritik katman hâline gelir.

Bir agent için kontrol yüzeyi en az şu sorulara cevap verebilmelidir:

• Hangi tool’a hangi koşullarda erişebilir?
• Hangi kararları kendi başına alabilir, hangilerinde onay gerekir?
• Belirsizlik durumunda nasıl davranır?
• Ara adımlarda neyi state olarak taşır, neyi unutmalıdır?
• Hangi aksiyonları loglar ve bunları kimler görebilir?
• Hata oluştuğunda güvenli geri dönüş yolu nedir?
• İnsan devreye ne zaman ve nasıl girer?
• Aynı görevi tekrar denerse tutarlı davranır mı?

Bu soruların hiçbiri “model daha zeki olsun” diyerek çözülmez. Bunlar sistem tasarımı, yönetişim, ürün kararları ve operasyon kabiliyeti ile çözülür.

Neden demo’da çalışan agent production’da kırılır?

Bugün birçok agent demosu etkileyici görünüyor çünkü kontrollü bir çevrede tek bir başarı anı gösteriyor. Net bir görev, temiz bir veri seti, sınırlı sayıda tool, düşük riskli bir aksiyon ve çoğu zaman insan tarafından önceden hazırlanmış bir senaryo… Böyle bir ortamda model zekâsı doğal olarak ön plana çıkıyor.

Ama production bambaşka bir şeydir. Production’da:

• input’lar dağınıktır,
• kullanıcı niyeti eksik veya çelişkili olabilir,
• tool yanıtları gecikebilir ya da başarısız olabilir,
• dış sistemler tutarsız davranabilir,
• aynı iş akışı farklı varyasyonlarla tekrar eder,
• denetlenebilirlik gerekir,
• yanlış aksiyonun maliyeti yüksektir.

Bu ortamda agent’ın başarısını belirleyen şey artık “doğru cevabı bulabildi mi?” sorusundan ibaret değildir. Asıl soru şudur: “Sistem belirsizlik, hata, yan etki ve yetki sınırları içinde hâlâ güvenilir davranabiliyor mu?”

İşte birçok agent tam bu noktada kırılır. Çünkü zekâ katmanı vardır ama davranışı yöneten sağlam bir kontrol yüzeyi yoktur. Tool çağrısı yapar ama neden yaptığını açıklayamaz. Hata alır ama uygun recovery path’i yoktur. Çok adımlı bir işte state drift yaşar. Gerekmediği yerde fazla otonom davranır, gerektiği yerde insana dönemaz. Sonuç olarak sistem teknik olarak “çalışıyor” görünse de operasyonel olarak güven vermez.

Kontrol yüzeyinin temel bileşenleri

Kontrol yüzeyi soyut bir kavram gibi gelebilir; ama pratikte oldukça somut bileşenlerden oluşur.

1. Permission boundaries

Bir agent’ın ne yapabildiği kadar ne yapamadığı da önemlidir. Hangi tool’lara erişebildiği, hangi veri sınıflarını okuyabildiği, hangi aksiyonları doğrudan gerçekleştirebildiği ve hangilerinde insan onayı gerektiği net olmalıdır.

Kurumsal senaryolarda çoğu risk “yanlış cevap”tan değil, “yanlış aksiyon”dan doğar. Yanlış kişiye mail atmak, yanlış kaydı güncellemek, yanlış müşteri verisini expose etmek, yanlış PR’ı merge etmek… Bunlar model kalitesinden çok yetki ve kontrol problemidir.

2. State management

Agent’ların büyük bölümü tek-shot prompt gibi düşünülerek tasarlanıyor. Oysa gerçek iş akışları adımlar arasında durum taşımayı gerektirir. Hangi karar neden alındı, hangi ara çıktı üretildi, hangi varsayımlar yapıldı, hangi görev beklemede… Bunlar güvenilir biçimde saklanmazsa sistem aynı akış içinde bile tutarsız davranmaya başlar.

State management zayıf olduğunda aynı görev yeniden çalıştırıldığında farklı sonuçlar üretilir, yarım kalan işler doğru yerden devam etmez ve insan müdahalesi sonrası sistem bağlamı kaybeder.

3. Observability

Bir agent’ın ne yaptığı görülemiyorsa ona güvenmek zordur. Sadece final output’u görmek yeterli değildir. Hangi adımları izlediği, hangi tool çağrılarını yaptığı, hangi karar noktalarında durduğu, neden belirli bir aksiyona yöneldiği belirli ölçüde görünür olmalıdır.

Observability burada sadece debugging aracı değildir; aynı zamanda yönetişim ve operasyon gereğidir. Özellikle ekipler arası, müşteri temaslı veya regüle süreçlerde “agent ne yaptı?” sorusu bir engineering detayı değil, bir işletme gereksinimidir.

4. Approval flows

Her kararı tamamen otonom bırakmak çoğu zaman yanlış tasarımdır. Kritik eşiklerde insan onayı istemek, sistemi zayıf değil güçlü yapar. Doğru tasarlanmış approval flow, agent’ın hızını öldürmeden riski yönetilebilir seviyeye indirir.

Buradaki mesele sadece “approve/reject” butonu koymak değil; hangi kararların onaya çıkacağını, ne kadar bağlam gösterileceğini ve reddedilirse nasıl geri dönüleceğini tasarlamaktır.

5. Recovery paths

Production sistemlerde hata istisna değil normdur. API zaman aşımı olur, üçüncü parti sistemler bozulur, dosya formatı beklenenden farklı gelir, model yanlış tool seçer, kullanıcı yarım bilgi verir. Bu durumlarda sistemin zarif biçimde toparlanabilmesi gerekir.

Gerçek kalite çoğu zaman başarı anında değil, başarısızlık anındaki davranışta ortaya çıkar. Agent hata aldığında sessizce bozuluyorsa, aynı çağrıyı körlemesine tekrar ediyorsa ya da yanlış bir sonucu başarılı gibi sunuyorsa, ne kadar akıllı olduğunun önemi azalır.

6. Human-in-the-loop design

İnsan müdahalesi agent tasarımının geçici kusuru değil, kalıcı bileşenidir. İyi tasarlanmış sistemlerde insan sadece acil durumda çağrılan son çare değildir; belirsizliğin yüksek olduğu, riskin arttığı veya iş bilgisinin gerektiği noktalarda bilinçli olarak akışın parçasıdır.

Bu yaklaşım agent’ı “tam otonom çalışan sihirli varlık” olarak görmek yerine, insanla birlikte çalışan kontrollü bir yürütme katmanı olarak konumlandırır. Bence gerçek kurumsal başarı da burada yatıyor.

Intelligence neden tek başına yetmez?

Burada önemli bir yanlış anlamayı da temizlemek gerekiyor: “Kontrol yüzeyi önemli” demek, “model kalitesi önemsiz” demek değildir. Elbette zayıf bir model üzerine güçlü bir sistem kurmak da sınırlıdır. Ancak belli bir kalite eşiğinden sonra asıl belirleyici katman modelin kendisinden çok sistemin etrafındaki kontrol mimarisi olur.

Bunu şöyle düşünmek daha doğru olabilir: Intelligence motor ise, kontrol yüzeyi direksiyon, fren, gösterge paneli, emniyet sistemleri ve yol tutuşudur. Güçlü motor faydalıdır; ama direksiyon ve fren yoksa aracı güvenle kullanamazsınız. Hatta motor güçlendikçe kontrol ihtiyacı daha da artar.

Daha otonom agent’larda bu gerçek daha da görünür olur. Çünkü sistemin etkisi arttıkça hata maliyeti de artar. Bir öneri üreten yardımcı ile gerçek sistemlerde aksiyon alan agent aynı risk düzeyinde değildir. Bu yüzden otonomi arttıkça kontrol yüzeyinin de daha sofistike hâle gelmesi gerekir.

Agent sistemleri neden kontrol sistemi gibi düşünülmeli?

Bence agent sistemlerini doğru anlamanın en iyi yollarından biri onları sadece “cevap üreten yapılar” olarak değil, birer kontrol sistemi olarak düşünmektir.

Kontrol sistemleri; hedef belirler, mevcut durumu izler, aksiyon alır, sonucu gözlemler, sapmaları tespit eder ve gerektiğinde düzeltici müdahale uygular. Güvenilir agent sistemleri de aslında benzer şekilde çalışmalıdır. Bir hedefe yürürken sadece üretim yapmamalı; kendi davranışını da sınır, geri bildirim ve denetim mekanizmaları içinde yönetebilmelidir.

Bu bakış açısı ürün kararlarını da değiştirir. Sorular artık sadece şunlar olmaz:

• En iyi model hangisi?
• Prompt’u nasıl iyileştiririz?
• Tool sayısını nasıl artırırız?

Onların yanına şu sorular gelir:

• Hangi aksiyonlar geri alınamaz?
• Hangi durumlarda insan zorunlu olmalı?
• Sistem neyi görünür kılmalı?
• Ne zaman durmalı, ne zaman retry etmeli?
• Hangi state kalıcı olmalı, hangisi ephemeral olmalı?
• Hangi kararlar audit edilebilir olmalı?

İşte production kalitesi bu soruların ciddiyetle cevaplanmasından çıkar.

Önümüzdeki dönem kim kazanacak?

Önümüzdeki dönemde agent adoption yarışını sadece en iyi modeli kullanan ekipler kazanmayacak. Hatta birçok alanda model erişimi giderek commoditized hâle geliyor. Benzer modellere birçok ekip erişebilecek. Bu durumda farkı yaratacak şey model erişimi değil, modelin etrafında kurulan ürün ve kontrol mimarisi olacak.

Bence kazananlar şunlar olacak:

• agent davranışını sınırlandırmayı bilenler,
• insan müdahalesini akıllıca tasarlayanlar,
• observability’yi ilk günden koyanlar,
• hata yönetimini “edge case” değil temel tasarım unsuru görenler,
• state ve permission modelini bilinçli kuranlar,
• güveni ürün özelliği olarak ele alanlar.

Çünkü enterprise dünyada değer sadece doğru output üretmekten gelmez. Değer; güven, izlenebilirlik, müdahale edilebilirlik, uyumluluk ve operasyonel dayanıklılık ile gelir.

Muadiller bunu nasıl yapıyor?

Piyasadaki olgun agent platformları aynı probleme farklı isimler veriyor. Ancak teknik tasarımlarına bakınca ortak çizgi açık: tool erişimini daraltmak, geri döndürülemez işlemlerde yürütmeyi durdurmak, state'i kalıcı tutmak, adımları izlemek ve kaliteyi ayrı bir değerlendirme döngüsünde ölçmek. Aşağıdaki örnekler ürün vaatlerini değil, resmi teknik dokümantasyonda tarif edilen mekanizmaları özetliyor.

OpenAI Agents SDK ve platformu

OpenAI Agents SDK'da tool guardrail'leri fonksiyon tool'u çalışmadan önce çağrıyı reddedebilir veya tripwire hatası üretebilir. Tool çıktısı için de çalıştırma sonrası kontrol tanımlanabilir. Yerel fonksiyon tool'ları insan onayı gerektirecek şekilde ayarlanabilir; onay beklenirken oturum tool çalışmasını durdurur. SDK, oturum ve konuşma yönetimini ayrı bir state/memory stratejisi olarak ele alır; run yapılandırmasında tracing, tool hata davranışı ve onay davranışı için alanlar bulunur. Bu, tek başına kurumsal yetkilendirme modeli değildir. Uygulamanın kimlik, rol ve veri erişimi kurallarını kendi sisteminde kurması gerekir. [1][2][3]

Anthropic Claude Code Agent SDK

Anthropic'in Claude Code Agent SDK'sı tool kullanımını allowedTools, disallowedTools, permission mode ve canUseTool üzerinden kontrol edebiliyor. Onay gerektiren bir işlemde host tarafı izin isteğini alabiliyor; reddedilen tool çağrısı modele sonuç olarak dönüyor. PreToolUse, PostToolUse ve PostToolUseFailure gibi hook'lar da tool öncesi kontrol, loglama ve hata sonrası işlem için uygulama uzatma noktaları sağlıyor. Oturum kimliği ile konuşma sürdürülebiliyor veya devam ettirilebiliyor. Dokümantasyonun işaret ettiği sınır önemli: allowlist otomatik onay verir, fakat tek başına modelin kullanabileceği tool kümesini daraltmaz. Kesin yasak için ayrıca disallowedTools veya host karar mantığı gerekir. [4][5][6]

Google Vertex AI Agent Engine

Google, Agent Engine'i yönetilen agent çalışma zamanı olarak konumlandırıyor. Sessions kısa süreli konuşma state'ini, Memory Bank ise oturumlar arası kalıcı belleği hedefliyor. Resmi dokümanlar ve ürün duyuruları, iz sürme, gözlemlenebilirlik ve evaluation servislerini Agent Engine yaşam döngüsünün parçaları olarak tanımlıyor. Agent değerlendirmesi, kullanıcı girdileri için trajectory sonuçları ve toplu metrikler üretebilen Gen AI evaluation hizmetiyle yapılabiliyor. Tool ve veri erişimi tarafında Google'ın vurgusu native agent identity ve güvenlik önlemleri. Bu, güvenlik temeli sağlar; hangi iş aksiyonunun insan onayına çıkacağı yine uygulama akışında açıkça tasarlanmalıdır. [7][8][9][10]

Microsoft Copilot Studio ve Microsoft Foundry

Microsoft'un rehberleri, dış sistemlere yazma veya finansal işlem gibi yüksek etkili tool çağrılarında insan onayı tanımlanmasını açıkça öneriyor. Copilot Studio agent flow'ları, akışı devam etmeden önce bekleyen human-in-the-loop ve çok aşamalı approval eylemlerini destekliyor. Yetki tarafında Entra ID tabanlı RBAC, en az yetki ilkesi ve ortam bazlı yönetişim modeli öne çıkıyor. Operasyon ekibi; Copilot Studio analitiği, transcript incelemesi, Application Insights telemetrisi, Purview audit ve Foundry trace/evaluator araçlarıyla farklı izlenebilirlik katmanlarını birleştirebiliyor. Buradaki ürün gerçeği, onay ve audit bileşenlerinin bulunduğu yönündedir. Doğru eşiklerin seçilmesi ve değerlendirmelerin sürekli çalıştırılması ise müşteri ekibinin tasarım sorumluluğundadır. [11][12][13][14]

LangGraph ve LangSmith

LangGraph, kontrol yüzeyini grafın yürütme semantiğine yerleştiriyor. Checkpointer her super-step'te thread'e state snapshot'ı yazabiliyor. Bu checkpoint'ler human-in-the-loop duraklatma, konuşma belleği, geçmiş adımı yeniden oynatma ve düğüm hatasından sonra son başarılı noktadan devam etme için kullanılıyor. İnsan onayı, interrupt_on ile seçilen tool çağrılarında duraklatılabilir; karar approve, edit veya reject olabilir. LangSmith tarafı trace, ara adım ve insan değerlendirmesini değerlendirme sürecine dahil ediyor. Bu yaklaşımın güçlü yanı recovery'nin soyut bir retry yerine state'e bağlı olmasıdır. Dayanıklılık modu seçimi yine bir ürüne ait risk ve gecikme kararıdır: sync daha güçlü yazma garantisi verirken daha fazla gecikme yaratır. [15][16][17]

GitHub Copilot ajanları

GitHub Copilot tarafında kontrol yüzeyi yazılım teslim akışına bağlı. Copilot SDK yaşam döngüsü hook'ları tool çalışmadan önce veya sonra güvenlik kontrolü, audit loglama ve approval akışı eklemek için kullanılabiliyor. MCP sunucuları oturum başına sınırlandırılabiliyor ve her oturumun context, tool ve izinleri izole edilebiliyor. Enterprise AI Controls görünümü, son agent oturumlarını ve ayrıntılı agentic audit log olaylarını görmeye yarıyor. Cloud agent için daha somut bir fren de var: agent'ın oluşturduğu taslak pull request insan tarafından gözden geçirilip merge edilmek zorunda. GitHub burada insan review'ünü tamamen kaldırmayı değil, kod üreten otomasyonu değişiklik geçmişi, oturum logları ve PR süreci içine yerleştirmeyi seçiyor. [18][19][20]

Bu örneklerin ortak sonucu şu: piyasadaki araçlar kontrol yüzeyinin parçalarını hazır veriyor, ama bu parçalar otomatik olarak güvenilir bir operasyon üretmiyor. Guardrail, audit log, checkpoint veya approval düğümü ancak hangi riski yönettiği, kimin karar verdiği ve reddedildiğinde akışın nereye döndüğü açık olduğunda değer kazanıyor. Kontrol yüzeyi hâlâ ürün mimarisinin görevi.

Sonuç

AI agent’ların geleceğini yalnızca intelligence belirlemeyecek. Asıl belirleyici olan şey, bu intelligence’ın ne kadar güvenli, görünür, denetlenebilir ve kontrol edilebilir biçimde çalıştırıldığı olacak.

Bu yüzden bence artık agent konuşurken sadece model benchmark’larını, context window’larını ya da prompting tekniklerini konuşmak yeterli değil. Asıl konuşmamız gereken şey kontrol, yönetişim, güvenilirlik ve operasyon tasarımı.

Çünkü gerçek darboğaz çoğu zaman zekâ değil. Kontrol yüzeyi.

Kaynaklar

[1] OpenAI Agents SDK, "Guardrails." https://openai.github.io/openai-agents-js/guides/guardrails

[2] OpenAI Agents SDK, "Realtime agents guide: tools, approvals, handoffs, and guardrails." https://openai.github.io/openai-agents-python/realtime/guide

[3] OpenAI Agents SDK, "Running agents." https://openai.github.io/openai-agents-python/running_agents

[4] Anthropic, "Agent SDK reference: TypeScript." https://docs.anthropic.com/en/docs/claude-code/sdk/sdk-typescript

[5] Anthropic, "Automate actions with hooks." https://docs.anthropic.com/en/docs/claude-code/hooks-guide

[6] Anthropic, "Agent SDK overview." https://docs.anthropic.com/en/docs/claude-code/sdk

[7] Google Cloud, "Get started with Vertex AI Agent Builder." https://cloud.google.com/blog/products/ai-machine-learning/get-started-with-vertex-ai-agent-builder

[8] Google Cloud, "More ways to build and scale AI agents with Vertex AI Agent Builder." https://cloud.google.com/blog/products/ai-machine-learning/more-ways-to-build-and-scale-ai-agents-with-vertex-ai-agent-builder

[9] Google Cloud, "Evaluate your AI agents with Vertex Gen AI evaluation service." https://cloud.google.com/blog/products/ai-machine-learning/introducing-agent-evaluation-in-vertex-ai-gen-ai-evaluation-service

[10] Google Cloud, "Remember this: Agent state and memory with ADK." https://cloud.google.com/blog/topics/developers-practitioners/remember-this-agent-state-and-memory-with-adk

[11] Microsoft Learn, "Process to build agents across your organization with Microsoft Foundry and Copilot Studio." https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/build-secure-process

[12] Microsoft Learn, "Agent flows overview." https://learn.microsoft.com/en-us/microsoft-copilot-studio/flows-overview

[13] Microsoft Learn, "Multistage and AI approvals in agent flows." https://learn.microsoft.com/en-us/microsoft-copilot-studio/flows-advanced-approvals

[14] Microsoft Learn, "Monitor operations, compliance, and capacity." https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/sec-gov-phase5

[15] LangChain, "LangGraph checkpointers." https://docs.langchain.com/oss/javascript/langgraph/checkpointers

[16] LangChain, "Human-in-the-loop." https://docs.langchain.com/oss/python/langchain/human-in-the-loop

[17] LangChain, "LangSmith evaluation concepts." https://docs.langchain.com/langsmith/evaluation-concepts

[18] GitHub Docs, "Application card: GitHub Copilot Agents." https://docs.github.com/en/copilot/responsible-use/agents

[19] GitHub Docs, "Agent management for enterprises." https://docs.github.com/copilot/concepts/agents/enterprise-management

[20] GitHub Docs, "Risks and mitigations for GitHub Copilot cloud agent." https://docs.github.com/en/copilot/concepts/agents/cloud-agent/risks-and-mitigations