Ajanlar için planlama stratejisi: saat dilimleri, aralıklı gönderim ve saat 9.00'da kırk sayfayı aynı anda doldurmamak

Bir ajan için iyi bir planlama stratejisi üç kurala dayanır: zamanları her zaman, müşterinin saat diliminden hesaplanmış açık bir farkla ISO 8601 biçiminde gönderin; her şeyi aynı anda ateşlemek yerine gönderimi hesap bazında aralıklara yayma işini platforma bırakın; büyük hesap listelerini tek dev bir gönderim yerine ayrı gönderilere ve ayrı saatlere bölün. Önce taslak hazırlayın, planlamayı ayrı bir adım olarak yapın ve iptali kolay tutun.

Aşağıdaki her şey, bu kuralları Shager'ın beklediği alanlarla somut hâle getirmekle ilgili.

Ajanlar zamanı neden yanlış hesaplar?

Dil modelleri saat konusunda kötüdür. Siz söylemedikçe saatin kaç olduğunu bilmezler, hiçbir fark belirtmeden gönül rahatlığıyla 2026-11-02T09:00:00 yazarlar ve saat dilimleri arasındaki dönüşümü kafadan yaparlar. Bunların her biri, gönderilerin 9.00 yerine 7.00'de çıkmasına yol açabilir.

Shager belirsizliği reddederek bu kapılardan birini kapatır: schedule_at değeri farkı belirtilmiş bir ISO 8601 zamanı olmalıdır, örneğin 2026-10-20T09:00:00+03:00. Z ya da fark içermeyen bir zaman damgası doğrulamadan geçmez. Bu biçim RFC 3339 ile tanımlanan profildir ve ajanınızın talimatlarında bunu adıyla belirtmeye değer.

Diğer kapı farkın kendisidir. +03:00, ekimde İsrail için doğru, aralıkta yanlıştır. Farklar yaz saati uygulamasıyla değişir ve geçiş tarihleri İsrail, AB ve ABD arasında farklılık gösterir. Ajan bir farkı asla sabit kodlamamalıdır. Müşterinin saat dilimi adını, yaygın her dilde hazır gelen IANA saat dilimi veritabanı üzerinden çözümlemeli ve farkı o tarihe göre hesaplamalıdır.

from datetime import datetime
from zoneinfo import ZoneInfo

local = datetime(2026, 11, 2, 9, 0, tzinfo=ZoneInfo("Europe/Berlin"))
print(local.isoformat())   # 2026-11-02T09:00:00+01:00

Her Shager çalışma alanının da bir timezone değeri vardır: çalışma alanı oluşturulurken belirlenen bir IANA saat dilimi adı (varsayılan Asia/Jerusalem). Ajanın bunu okumasını ve kullanmasını sağlayın. Tek bir ajanı birçok müşteride çalıştırdığınızda müşterilerin hepsi aynı saat diliminde olmayacaktır; her müşterinin hangi dilimde yaşadığını kaydeden tek yer çalışma alanıdır.

Diyagramın tamamı için yana kaydırın

Önce taslak, sonra planlama

create_post, schedule_at verirseniz gönderiyi hemen planlayabilir. Müşteri işlerinde ajanların bunu yapmasına nadiren izin veririm. Daha güvenli yol iki çağrıdır:

1. schedule_at olmadan create_post; bu bir taslak kaydeder.
2. Bir insan ya da bir kural onay verdikten sonra, gönderi kimliği ve zamanla schedule_post.

{
  "tool": "schedule_post",
  "arguments": {
    "workspace_id": "ws_example",
    "post_id": "pst_example",
    "schedule_at": "2026-10-20T09:00:00+03:00"
  }
}

Bunun bir yetki gerekçesi de var. Shager'da planlama için API anahtarında publish yetkisi gerekir, taslak içinse yalnızca write yeterlidir. Bir insan, ajanın test ortamını sahiplenirken publish yetkisini açıkça verir ve bu yetki olmadan da anahtar oluşturabilir. Bu ayrım, taslak hazırlayan bir ajana geniş özgürlük tanırken son adımı bir insanın arkasında tutmanızı sağlar. Ayrıntılar API anahtarları, yetki kapsamları ve denetim yazısında.

schedule_post başarısızlık durumunda da işe yarar bir şey yapar: herhangi bir hesap gönderiyi reddedecekse ya da müşteri onayı gerekli olduğu hâlde eksikse, yarısı başarısız olacak bir gönderimi planlamak yerine net bir gerekçeyle hata verir.

Aralıklı bir gönderim gerçekte ne kadar sürer?

Shager hesap hesap yayın yapar ve aynı platformdaki hesaplar arasında rastgele bir bekleme süresi bırakır. Bu aralığı stagger_seconds alanı belirler, varsayılan değer [30, 90]. Platformlar paralel çalışır; dolayısıyla gönderimin süresini en çok hesaba sahip platform belirler.

Hesap, ajanın bir saat seçmeden önce yapabileceği kadar basit:

En büyük platformdaki hesap sayısı	Aralık	Ortalama bekleme	Yaklaşık gönderim süresi
10	[30, 90]	60 sn	yaklaşık 9 dakika
40	[30, 90]	60 sn	yaklaşık 39 dakika
40	[60, 180]	120 sn	yaklaşık 78 dakika
120	[30, 90]	60 sn	yaklaşık 2 saat

İnsanları şaşırtan son satırdır. Müşteri "her şey 10.00'a kadar yayında olmalı" diyorsa ve elinizde 120 Facebook sayfası varsa, 9.00'a yapılan bir planlama bu şartı karşılamaz. Ya daha erken başlayın ya da gönderimi bölün.

Bir son tarihe aralığı [0, 5] seviyesine indirerek karşılık vermeyin. Bekleme süresi, toplu bir gönderimin tek kaynaktan gelen ani bir patlama gibi görünmemesi için vardır. Ölçekli paylaşımda spam engellerinden kaçınmak yazımız, temponun neden tek bir açıklamadan daha önemli olduğunu anlatıyor.

Saate göre değil, gruba göre bölün

Büyük müşteriler için daha sağlam yöntem, her hesap grubu için kendi saati olan ayrı bir gönderidir. 90 şube sayfası olan bir perakende zinciri bölgelere göre gruplanabilir. Ajan, her bölge grubu için bir tane olmak üzere üç gönderi oluşturur ve bunları farklı sabahlara ya da günün farklı saatlerine yayar.

{
  "tool": "create_post",
  "arguments": {
    "workspace_id": "ws_example",
    "group_ids": ["grp_north"],
    "caption": "Winter hours start Sunday at every northern branch.",
    "per_channel": [
      { "channel_id": "ch_fb_haifa", "caption": "Haifa branch: winter hours start Sunday. We open at 8:30." }
    ],
    "campaign": "winter-hours",
    "stagger_seconds": [60, 150]
  }
}

Gruplar, bir ad ve channel_ids listesi alan create_group ile oluşturulur. Bir grubu hedeflediğinizde gruptaki tüm aktif kanallar eklenir.

Diyagramın tamamı için yana kaydırın

Ajanın uyması gereken platform sınırları

Platformların kendileri de bir hesabın API'leri üzerinden ne kadar yayın yapabileceğini sınırlar. Meta, API ile yayınlanan Instagram gönderileri için 24 saatlik kayan bir pencerede hesap başına bir sınır belgeliyor ve mevcut kullanımı kontrol etmek için bir content_publishing_limit uç noktası sunuyor. YouTube ise API kotasını proje başına ayırıyor; varsayılan değer günde 10.000 birim ve yüklemeler en pahalı işlemler arasında.

Gönderim tarafını Shager halleder, ama planlama tarafı ajanın sorumluluğundadır. Bir günde altı gönderi alan bir hesap, API sorunu olmadan önce bir strateji sorunudur. Ajanlara basit bir kural veriyorum: bir insan aksini söylemedikçe hesap başına günde en fazla bir akış gönderisi.

Takvimler, bayramlar ve sessiz günler

Shager'ın takvimi İsrail'deki bayramları içerir. Bu, büyük bir bayramın arifesine planlanan bir gönderinin çevrimdışı bir kitleye denk geldiği İsrailli müşteriler için önemlidir. Başka ülkelerdeki müşteriler için ajana, talimatlarında müşterinin kendi kapanış ve etkinlik takvimini verin. Modeller resmî tatillerin aşağı yukarı ne zaman olduğunu bilir; ama bu müşterinin deposunun her çeyreğin son cuma günü sayım için kapandığını bilmezler.

İptal etmek ve taşımak

cancel_post, henüz yayınlanmaya başlamamış bir gönderinin planlamasını kaldırır. Gönderiyi silmez: gönderi onaylanmış bir taslağa geri döner, böylece ajan yeni bir saatle tekrar schedule_post çağırabilir. İptal, hâlâ bekleyen gönderiler içindir; yayın başladıktan sonra cancel_post artık uygulanmaz.

Ajan herhangi bir şeyi taşımadan önce, o çalışma alanında kuyrukta neler olduğunu görmek için status değeri SCHEDULED olarak ayarlanmış bir list_posts çağırmalıdır. Aynı saatte aynı hesaplara düşen iki planlanmış gönderim, en sık gördüğüm kendi kendine yapılan hatadır.

Sık sorulan sorular

Ajan UTC gönderirse Shager hangi saat dilimini kullanır?

Z içeren bir zaman damgası belirsiz değildir; Shager onu tam o ana planlar. Çalışma alanının saat dilimi, insanların planı takvimde nasıl gördüğü ve ajanın kendi akıl yürütmesi açısından önemlidir. Yerel saati doğru farkla göndermek, ajanın kayıtlarını onları kontrol eden insanlar için okunur kılar.

Ajan tek bir gönderide farklı hesapları farklı saatlere planlayabilir mi?

Bir gönderinin tek bir schedule_at değeri vardır; hesaplar sonra aralıklı sırayla çıkar. Gerçekten farklı saatler için ayrı gönderiler oluşturun, genellikle grup başına bir tane. Her gönderi kendi label değerini taşıyabildiği için raporlama da daha temiz olur.

Makul bir varsayılan aralık nedir?

Varsayılan [30, 90] çoğu gönderim için uygundur. Video için ve tek bir platformda yaklaşık 50'den fazla hesaba yapılan gönderimlerde bunu [60, 150] gibi bir değere genişletiyor ve daha erken başlıyorum. Bedeli erişim değil, zamandır.

Bundan sonra

Bu kuralları her görevde tekrarlamak yerine ajanınızın kalıcı talimatlarına koyun. İçerik ajanı için komut istemleri yazısında olduğu gibi yapıştırabileceğiniz bir planlama bloğu var.