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

_2026-09-18 · Bir ajan birçok hesapta gönderileri nasıl planlamalı: ISO 8601 farkları, saat dilimleri ve yaz saati, aralık hesabı, grupları günlere bölmek, güvenli iptal._

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](https://www.rfc-editor.org/rfc/rfc3339) 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ı](https://www.iana.org/time-zones) üzerinden çözümlemeli ve farkı o tarihe göre hesaplamalıdır.

```python
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](/en/blog/one-agent-many-clients) ç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.

## Ö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`.

```json
{
  "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](/en/blog/api-keys-scopes-and-audit) 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](/en/blog/avoid-spam-blocks-when-posting-at-scale) 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.

```json
{
  "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.

## 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ı](https://developers.facebook.com/docs/instagram-platform/content-publishing) sunuyor. YouTube ise API kotasını proje başına ayırıyor; [varsayılan değer günde 10.000 birim](https://developers.google.com/youtube/v3/getting-started) 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](/en/blog/prompts-for-a-content-agent) yazısında olduğu gibi yapıştırabileceğiniz bir planlama bloğu var.

---
Source: https://shager.ai/tr/blog/scheduling-strategy-for-agents