OpenAI, 10 Eylül'de “Codex'e güç veren aynı altyapıyı ve çalışma çatısını basit ve esnek bir API aracılığıyla geliştiricilere sunarak” Agents API'yi genel betaya açtı. 29 Eylül'deki DevDay'de ise bilgisayar kullanımı (computer use), AWS'e özgü bir kardeş servis ve yeni bir komşu kazandı: ChatGPT'nin her an aktif yeni dot'ları da aynı Codex çatısı üzerinde çalışıyor.
Bir ajan (agent) ürünü geliştiren bir yazılımcı gözüyle bakarsanız bu harika bir haber: Kendi başınıza alelacele ve yetersiz biçimde yazacağınız o çalışma çatısı artık başkasının derdi. Ancak ekibi gerçek bir kod tabanında halihazırda Claude Code ve Codex çalıştıran bir mühendis gözüyle bakarsanız soru değişiyor. Bu API, “Bir ajanı saatlerce nasıl çalışır durumda tutarım?” sorusuna yanıt veriyor. Ancak “Ekibim bu ajanlardan altısının ne yaptığını nereden bilecek ve içlerinden birinin az önce giriş yaptığı web sitesini kim onayladı?” sorusunu yanıtsız bırakıyor. İşte Sharkly tam olarak bu ikinci sorunun yanıtında devreye giriyor.
Özetle (TL;DR)
Agents API; kalıcı oturumlar (durable sessions), bağlam sıkıştırma (compaction), araç arama, alt ajanlar (subagents) ve OpenAI'dan, kendi altyapınızdan ya da dokuz iş ortağından sağlanan bir sandbox dahil olmak üzere Codex çatısını barındırıyor; üstelik token, araç ve konteyner süresi dışında hiçbir ek ücret talep etmiyor. DevDay ile birlikte uygulamanızın her yeni web sitesi kökenini (origin) ve her oturum açma işlemini onayladığı bilgisayar kullanımı (computer use — köken onayı münferit eylemlerin teyidi anlamına gelmez) ve temel yeteneklerini doğrudan AWS içinde çalıştıran Bedrock Managed Agents eklendi. Ancak bunların hiçbiri ekip katmanını üstlenmiyor: İşi kim atadı, hangi ajan üzerinde çalışıyor, ne tamamlandı, ne başarısız oldu ve sonucu kim kabul ediyor?
Agents API nedir ve OpenAI neleri yönetir?
OpenAI'ın genel bakış dokümanı API'yi dört temel kavrama indirgiyor. Bir Agent (Ajan); “ajanın erişebildiği model, talimatlar, araçlar ve MCP sunucularıdır.” Bir Environment (Ortam); “ajanın dosyalara eriştiği, becerileri yüklediği ve komutları çalıştırdığı isteğe bağlı bir sandbox veya bilgisayardır.” Bir Session (Oturum); “görevler üzerinde çalışan ve girdilere yanıt veren kalıcı bir ajan örneğidir.” Events and items (Olaylar ve öğeler) ise gönderdiğiniz girdiler ve geri dönen çıktılardır.
Bir ajan yapılandırmasıyla bir oturum oluşturur, ortam hazır olduğunda ona bir görev verir, süreci akış (streaming) veya webhook'lar üzerinden takip eder ve ardından aynı oturuma daha fazla görev veya yönlendirme gönderirsiniz. Dokümantasyondaki örneğin kısaltılmış hali şöyle:
const session = await client.beta.agents.sessions.create({
agent: {
model: "gpt-6-astra",
instructions: "Use the docs MCP and web search. Delegate independent research to subagents when useful.",
tools: [
{ type: "programmatic_tool_calling" },
{ type: "mcp", server_label: "openai_docs", transport: { type: "http", server_url: "https://developers.openai.com/mcp" } },
{ type: "web_search" },
],
multi_agent: { enabled: true, max_concurrent_subagents: 4 },
},
environment: { type: "self_hosted", workspace_directory: "/workspace" },
input: [{ role: "user", content: [{ type: "input_text", text: "Research how to connect an MCP server to an OpenAI agent and summarize the setup." }] }],
});
Yeniliklerin büyük kısmını iki satır taşıyor. multi_agent, eşzamanlılık sınırı belirleyerek alt ajanlara iş dağıtmayı (fan-out) etkinleştiriyor; environment.type ise kodun nerede çalışacağını belirliyor: openai_hosted, self_hosted veya iş ortağı sandbox ortamlarından biri (Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, Vercel).
Dokümantasyon iş bölümünü tek bir cümleyle özetliyor: “OpenAI oturumları, orkestrasyonu, bağlam sıkıştırmayı ve kurtarmayı yönetirken, uygulamanız araçları sağlar ve yürütme ortamını seçer.”
| OpenAI'ın yönettikleri | Sizin sağlamanız gerekenler |
|---|---|
| Ajan döngüsü: model çağrıları, araç kullanımı, yeniden denemeler | Görev ve tamamlanma tanımı (definition of done) |
| Oturum sınırına yaklaştığında bağlam sıkıştırma | Araçlar: MCP sunucuları, fonksiyonlar, yerleşik araçlar |
| Araç arama ve yükleme | Kasa (vault) kimlikleri aracılığıyla kimlik bilgileri |
| Alt ajanlara ayrıştırma ve koordinasyon | Ortam seçimi ve kurulumu |
| Oturumu sürdürme ve yönlendirme | Oturum bittikten sonra gerçekleşen her şey |
Model kullanımı modelin API tarifelerinden, araçlar standart tarifelerden ve OpenAI tarafından barındırılan sandbox'lar ise konteyner tarifelerinden faturalandırılıyor; lansman yazısında “Agents API'yi kullanmak için hiçbir ek ücret alınmadığı” belirtiliyor. Dokümantasyonda iki sınır açıkça ifade ediliyor: API “şu anda veri yerleşimini (data residency) yalnızca Amerika Birleşik Devletleri'nde desteklemektedir ve Sıfır Veri Saklama (ZDR - Zero Data Retention) özelliğini desteklememektedir”; ayrıca kendi barındırdığınız (self-hosted) bir sandbox seçmek de onu ZDR uyumlu hale getirmez. Uyumluluk gereksinimleriniz açısından bunlardan biri önemliyse, sandbox'ı kendi bünyenize taşımanız bu durumu değiştirmez.
DevDay ile gelen yenilikler
Bilgisayar kullanımı (Computer use). computer_use aracını ekleyin, OpenAI tarafından barındırılan bir ortamda masaüstünü etkinleştirin; ajan barındırılan bir tarayıcıyı yönetsin. Bilgisayar kullanımı rehberi, akışı onay olayları (approval events) etrafında kurguluyor. Tarayıcı, herkese açık siteler de dahil olmak üzere her yeni web sitesi kökeninden (origin) önce kullanıcının onayını istiyor. Oturum açma işlemleri; uygulamanızın e-posta, parola ve doğrulama kodu alanları için oluşturduğu ayrı istekler olarak iletiliyor; geçiş anahtarları (passkeys) ve QR kodla giriş desteklenmiyor ve kimlik bilgilerini yalnızca ana ajan talep edebiliyor, alt ajanlar edemiyor. İki kez okunması gereken kritik satır ise şu: “Köken onayı, münferit eylemlerden önce teyit alınmasını zorunlu kılmaz.” Dokümantasyon; satın alma işlemleri veya geri döndürülemez değişiklikler için barındırılan tarayıcının bu eylemleri gerçekleştiremeyecek kaynaklarla sınırlandırılmasını ya da kontrolü sizde olan bir tarayıcı çalışma zamanının kullanılmasını öneriyor. DevDay özeti, bilgisayar kullanımını “API üzerinden ve Pro 500 ile Enterprise planlarındaki Codex ve ChatGPT Work kapsamında” listeliyor.
OpenAI destekli Bedrock Managed Agents. OpenAI ve Amazon, “Agents API'nin temel yeteneklerini” alarak AWS içinde yerel olarak çalışacak şekilde özelleştirdi. AWS ürün sayfası bunu önizleme olarak listeliyor ve her ajanın kendi AWS kimliğini ve izinlerini koruyarak ajan çalışma zamanı ile model çıkarımının AWS içinde kaldığını belirtiyor.
Aynı çatı üzerindeki Dot'lar. Decrypt'in haberine göre Codex çatısı “artık dot'lara güç veriyor ve açık kaynaklı hale getirildi.” Dot'lar, ChatGPT'nin her biri kendi bulut bilgisayarına sahip olan ve sürekli çalışan ajanlarıdır; dot'lar hakkındaki inceleme yazımız neleri iyi yaptıklarını ayrıntılarıyla ele alıyor.
Böylece tek bir döngü artık bir kodlama ajanını, bir API oturumunu, bir AWS ajanını ve sürekli çalışan bir asistanı yönetebiliyor. Çalışma çatısı tek bir noktada birleşiyor. Ekibin üzerine düşen kısım ise onay olayları: Her biri tek bir oturumun içindeki bir sorudur ve o oturumun veri akışını açık tutan kişi tarafından yanıtlanır. Beş oturum birden soru sorduğunda, hangi kişinin hangi kökeni onaylayabileceğine ve bu kararın nereye kaydedileceğine birinin karar vermesi gerekir. Bu bir onay kapısı (approval gate) sorunudur ve biz bunun Bilgisayar tarafındaki versiyonunu GPT-6 Astra bilgisayar kullanımı güvenlik sınırları yazımızda ayrıntılı olarak ele almıştık.
Yönetmediği kısım: Ekip katmanı
Bir oturum yalnızca kendisinden haberdardır. Başka üç oturumun aynı repoya müdahale ettiğini ya da dördüncüsünün sonucunun Salı gününden beri okunmadan beklediğini bilmez. Bunlar yönetimsel problemlerdir ve birden fazla kişi birden fazla ajanı başlattığı anda ortaya çıkarlar.
API'nin tasarım gereği açıkta bıraktığı beş soru:
- Bunu kim, hangi görev kartı (ticket) doğrultusunda atadı? Bir oturumun yalnızca bir kimliği (ID) ve kodunuzun içine yazdığı meta veriler vardır. Bir sorumlu, bir Sprint veya ait olduğu iş kaydına (issue) giden bir bağlantı, yalnızca siz oraya koyarsanız var olur.
- Hangi repoyu ve dalı (branch) değiştirdi? Değişiklik farkının (diff), bir incelemecinin okuyabileceği bir yere ulaştırılması gerekir.
- Ne tamamlandı, ne başarısız oldu, ne bekliyor? Olaylar siz dinlerken akar ya da webhook ile gelir. Bir insanın onayını bekleyen sonuçlar kuyruğunda hiçbir şey kendiliğinden birikmez.
- Sonucu kim kabul ediyor? Bir onay olayı yapılan işi değil, yalnızca bir web sitesini veya oturum açma işlemini kapsar. İkincisini kendiniz inşa etmediğiniz sürece “oturum sona erdi” ile “bir insan kanıtları inceledi ve onayladı” aynı olay olarak kalır.
- Peki OpenAI dışındaki ajanlar ne olacak? Bir tür iş için Claude Code, diğeri için Codex kullanmak; iki farklı oturum modeli ve bakılması gereken iki ayrı yer anlamına gelir.
Bu beş sorunun çözümünü de olayların üzerine kendiniz kurabilirsiniz: bir pano, bir webhook, bir durum alanı, bir inceleme sütunu. Ancak sonrasında biri çıkıp “Dışa aktarma düzeltmesini yayına aldık mı?” diye sorduğunda yanıt, kimsenin kaydetmediği bir terminal geçmişinde (scrollback) kalır. Yapay zeka ajanı görev yönetimi yazımız, bu yapıyı kendi başınıza kurma senaryosunu ele alıyor.
Bir oturum içindeki alt ajanlar mı, yoksa panodaki görevler mi?
max_concurrent_subagents ayarı, API'nin paralellik ihtiyacına verdiği yanıttır ve doğru iş modelleri için oldukça başarılıdır. Bu durum, Codex'in alt ajan sınırını 64'e çıkarması üzerine yazdığımız ödünleşimle (trade-off) aynıdır: Alt ajanlar ortak bir üst ajanı (parent) paylaşır, tek bir birleştirilmiş yanıt olarak rapor verir ve tek bir sonuç olarak incelenir.
İş parçaları yoğun okuma gerektiriyorsa, birbirinden bağımsızsa ve yalnızca birleştirilmiş nihai yanıt önemliyse oturum içi alt ajanları kullanın: Dört farklı API'yi araştırmak, bir kod tabanını belirli bir kalıp için taramak ya da bir olay (incident) için kanıt toplamak gibi.
Her bir parçanın birinin tek başına incelemesi gereken kodlar yazdığı durumlarda ise ayrı Görevler (Tasks) kullanın: Bir veri tabanı geçişi (migration), tek bir modüldeki yeni bir özellik ya da ortak bir dosyaya dokunan bir hata düzeltmesi gibi. Sharkly'de her çalıştırma, size ait bir Computer (Bilgisayar) üzerinde kendi yalıtılmış git worktree alanını alır ve her sonuç; kendi diff'i, çalıştırma günlüğü (execution log) ve incelemecisiyle birlikte kendi Görevine geri döner. Yoğun yazma gerektiren dört değişikliğin tek bir alt ajan özetine sıkıştırılması, tek bir kararın içine gizlenmiş dört ayrı karar demektir.
Sıkça sorulan sorular
Bilgisayar kullanımı hangi model üzerinde çalışıyor? Dokümantasyondaki örneklerde gpt-6-astra kullanılıyor. Başka bir modelin computer_use aracıyla çalıştığını varsaymadan önce ilgili rehberi kontrol edin.
Sharkly, Agents API oturumlarını çalıştırıyor mu? Sharkly; Codex ve Claude Code gibi Bilgisayarlarınızda (Computers) yüklü olan CLI kodlama ajanlarını birer Çalışma Zamanı (Runtime) olarak çalıştırır. Agents API oturumları ise yerel olarak kurulu bir Runtime değil, barındırılan bir hizmettir (hosted service); bu nedenle onları ayrı bir yürütme yolu olarak değerlendirin.
İnsan incelemesi nerede gerçekleşir? Agents API'de bunu nerede inşa ederseniz orada gerçekleşir: Onay olayları sonucun kabulünü değil, yalnızca web sitesi erişimini ve oturum açmayı kapsar. Sharkly'de ise bir Ajan, Görevini insan incelemesi bekleyecek şekilde bırakabilir; istek sorumlu kişinin Gelen Kutusu'na (Inbox) düşer ve bir kişi yanıtı, çalıştırma günlüğünü ve diff'i inceledikten sonra durumu günceller.
Hangi katman nereye ait?
OpenAI altyapısındaki kalıcı bir oturum, bu lansmanın en kullanışlı ve en çok bağlılık yaratan unsurudur. Bir mühendislik ekibi için bu durum oldukça önemlidir; çünkü en güçlü kodlama ajanı sürekli değişen bir hedeftir ve inceleme durumları ile atama kuralları tek bir tedarikçinin oturum deposunda bulunan bir ekip, lider her değiştiğinde iş akışını sıfırdan kurmak zorunda kalır.
Ajan destekli bir ürün veya arka uç (backend) hizmeti geliştiriyorsanız Agents API doğru katmandır; AWS içinde buna ihtiyaç duyan ekipler için Bedrock Managed Agents da aynı doğrultuda bir tercihtir. Bakımını üstlenmek zorunda kalmadan çalışma çatısına, kaynak ayırmakla (provisioning) uğraşmadan da sandbox ortamlarına sahip olursunuz. Bir görev panosuna hiç ihtiyacınız olmayabilir; çünkü panonun kendisi uygulamanızdır.
Ancak ajanlarınız kendi kod tabanınızda çalışan, insanlar tarafından yönetilen, insanlar tarafından incelenen, mevcut repolarınız ve iş takip sistemleriniz üzerinden yayına alınan ekip arkadaşlarınızsa denklem değişir. Yürütme işini Codex ve Claude Code yapar. Sharkly ise bu araçlar genelinde ekip düzeyinde atamayı, bağlı Bilgisayarları, görev bağlamını, ilerlemeyi, engelleri (blockers), sonuçları ve insan incelemesini yönetir. Ne bu Çalışma Zamanlarının (Runtime) ne de Agents API'nin alternatifi değildir. Konumlandırmaya dair aynı soru artık Codex'in kendisi için de geçerlidir; bu konuyu Codex bulutu ve kendi Bilgisayarlarınız başlıklı yazımızda ele alıyoruz.
Bir ajan geliştiriyorsanız çalışma çatısını kiralayın. Ancak onları yönetiyorsanız, yönetim katmanını kendinize saklayın ve sağlayıcıdan bağımsız tutun.
Halihazırda birden fazla ajan çalıştırıyorsanız Sharkly, bunların görevlerini ve sonuçlarını yönetmeniz için tek bir merkez sunar. Sharkly token satmaz: Model kullanımı, bağladığınız araçlarda yapılandırılmış abonelikler veya API anahtarları üzerinden işlemeye devam eder.
