10 Eyl 2026

İnsan ve Ajan Birlikte Çalışırken: Sorumluluk Kim, Onay Kim?

Geçen beş gün ajanlara yapı, politika ve aralarında çalışma düzeni verdik. Fakat bir nokta kalıyor: gerçek işlerde ajanlar yalnız mı çalışır?

Hayır. Bir fintech şirketinde “transfer_processor” adında bir ajan var. Bu ajan müşteri para transferini işleme alır. Fakat gece yarısı 1 milyar lira transfer işlemi başına bir hata bulunursa, kimin sorumluluğu?

Ajana mı? İnsana mı? Araya bir onay roller mi? Yoksa ikisinin birlikte çalıştığı sistemin sorumluluğu mu?

Senaryo: Karma Ekipte Mali Transfer

Bir e-ticaret platformunda transfer akışı şöyle:

Müşteri isteği: “Hesaptan 50,000 TL çek”
transfer_processor (AJANı): İsteği alır, geçerlilik kontrol eder, sistem bankaya gönderi isteği yazar
approval_manager (HUMAN, Mali Müdürü): Sistem tarafından flagged işlemleri (>100K TL veya yeni müşteri) insan kontrolüne sokar
banking_gateway (AJAN): Banka tarafından confirmed işlemi tutuklar

Şu iş akışını düşün:

Workflow: Customer Transfer

Input: Customer X, Amount: 50,000 TL

Step 1: transfer_processor (AGENT)
  - Hesap bakiyesi kontrol: OK (150K var)
  - Limit kontrol: OK (günlük limit 100K, bu gün 0)
  - Fraud check: OK (normal pattern)
  → Karar: "Approve and forward to banking_gateway"

Step 2: banking_gateway (AGENT)
  - Bank API çağrısı yapıldı
  - Status: "Pending" (banka süreç içinde)
  → Log: 2026-09-10 14:32:15 - Transaction ID TX-2026-0001

Step 3: Banka cevabı geliyor
  - Status: "REJECTED - Account frozen due to compliance flag"
  → Error: Customer hesabı compliance review'da, Kanunilik birim engelledi

Sorun şu: transfer_processor ve banking_gateway’in politikasında “compliance freeze” kontrolü yok. Çünkü kanunilik bilgisi ajanların şimdiki datasında bulunmuyor.

Mali Müdür insan, sabah gelip şöyle diyor: “Niye bu transferi onayladın? Müşteri dün kara para aydınlatma raporunda flag’lendı!”

transfer_processor da cevaplıyor: “Benim politikada compliance flag yok, onaylayacak şeyim.”

Çözüm 1: İş Bölümü ve Onay Roller

Bu sorunu çözmek için, workflow değişiyor:

policy.md (transfer_processor):
  - Beceri: Basic transfer validation
  - Sınırlar:
    - Maksimum 100,000 TL / işlem
    - Sadece bakiye ve günlük limit kontrol
    - COMPLIANCE FLAG KONTROL YAPAMAZ
  - Onay gerekli: Eğer tutarı 50K'yı aşarsa veya

policy.md (approval_manager HUMAN):
  - Rol: Mali müdür
  - Sorumluluk: Compliance-flagged işlemleri reddetmek
  - Access: Kanunilik bilgi sistemine
  - Veto gücü: Herhangi bir transferi reddedebilir
  - Dosya yolu: /policies/approval_manager.md → Git'te versiyon tutulur

policy.md (banking_gateway):
  - Beceri: Bank API integration
  - Sınırlar: API status kontrolü, log tutma
  - NOT: Compliance kararı yapamaz (insan görevidir)
  - Error fallback: Hata ise Mali Müdüre eskalasyon

İki şey değişti:

transfer_processor, 50K üzeri işleri Mali Müdüre gönderir
approval_manager (HUMAN), compliance bilgisi ile karar verir

New Workflow:

Step 1: transfer_processor (AGENT)
  → Check: Tutarı 50K mı? EVET
  → Action: "Requires human approval"
  → Forward to: approval_manager
  → Log: "Forwarded for manual review"

Step 2: approval_manager (HUMAN, Mali Müdür)
  → Login to dashboard
  → Check: Compliance flag? EVET, flag var
  → Decision: REJECT with reason "Compliance investigation ongoing"
  → Log: "Rejected by approval_manager at 2026-09-10 07:15"

Step 3: transfer_processor (AGENT)
  → Hata mesajı aldı: REJECTED
  → Müşteriye bildir: "Hesabınız geçici olarak review'da, lütfen destek ile iletişime geçin"
  → Log: "Customer notified of rejection"

Çözüm 2: Config-as-Code ve Git Versiyon Kontrolü

İşte kritik nokta: Bu politikalar yazılı ve versionlanmış olmalı.

Repository Structure:

/root/projects/org-config/
├── policies/
│   ├── transfer_processor.md (version: 2.3)
│   ├── approval_manager.md (version: 1.2)
│   └── banking_gateway.md (version: 1.1)
├── workflows/
│   ├── customer_transfer_flow.yaml (version: 3.1)
│   └── compliance_escalation.yaml (version: 2.0)
├── roles/
│   ├── approval_manager.json (Mali Müdür tanımı)
│   └── compliance_officer.json (Kanuni Müşavir tanımı)
└── git log
    └── "Updated transfer_processor policy to add compliance check"
       (2026-09-01 by financial_director)

Şu yapı sayesinde:

Her politika bir dosya: Takip edilir, değiştirilebilir
Git history: “Bu kuralı kim, ne zaman ekledi?” sorgulanır
PR + Review: Politika değişirken bir başka şef onay verir
Rollback: Yanlış kural yazıldıysa eski versiyona dönülebilir

Örnek: Policy Update via PR

Maliye Müdürü fark ediyor: “Onay Limitini 50K’dan 30K’ya indirmeliyiz çünkü risk arttı.”

GitHub PR #2847:
Title: "Lower transfer approval threshold to 30K due to fraud spike"

Changes:
- File: policies/transfer_processor.md
- Line 15: - Approval required: Amount > 50,000 TL
- To:      - Approval required: Amount > 30,000 TL

Reviewer: Genel Müdür (CEO)
Status: APPROVED and merged

Result:
- Main branch'e merged: 2026-09-10 10:00
- Tüm ajanlar bu policy'yi otomatik yükler
- Eski: 50K üzeri onaylanıyor → Yeni: 30K üzeri onaylanıyor

Git log’dan bir gün sonra: “Neden birdenbire 30K threshold’una çıktı?”

→ Cevap: git log policies/transfer_processor.md → PR #2847 → açıklanmış.

Çözüm 3: Sorumluluk ve Insan Veto

Fakat şu da var: İnsan ne zaman veto edebilir?

Responsibility Matrix:

Activity                          | Agent          | Human          | Veto Rights
----------------------------------|----------------|----------------|------------------
Basic validation (balance, limit) | transfer_proc  |                | N/A
Compliance check                  | (no)           | approval_mgr   | approval_mgr
                                  |                |                |
Fraud scoring                     | transfer_proc  |                | approval_mgr can override
Bank API call                     | banking_gw     | (observe log)  | approval_mgr can cancel
Customer notification             | transfer_proc  | (optional)     | N/A
Audit logging                     | banking_gw     | compliance_off | (review only, no veto)

“approval_mgr can override” ne demek? Örneğin:

transfer_processor: “Tutarı 50K, onay lazım mı? EVET, forward ediyorum.”
approval_manager: Dashboard’a bakıyor, compliance flag görmüyor, şöyle diyebilir:
- “Approve” (standart karar)
- “Approve with note: Customer has pending KYC” (açıklaması ile onay)
- “Reject and flag account for review” (veto + eskalasyon)

Veto’nun önemli kısmı: Log tutulması ve nedeni kaydedilmesi.

Audit Log:

2026-09-10 07:20 | transfer_processor  | Initiated TX-2026-0042, Amount: 75,000 TL
2026-09-10 07:21 | transfer_processor  | Escalated to approval_manager (threshold exceeded)
2026-09-10 07:25 | approval_manager    | Reviewed TX-2026-0042
2026-09-10 07:26 | approval_manager    | APPROVED with note: "KYC updated, proceeding"
2026-09-10 07:27 | banking_gateway     | API call initiated to bank
2026-09-10 07:28 | banking_gateway     | Status from bank: PENDING
2026-09-10 08:15 | banking_gateway     | Status from bank: CONFIRMED
2026-09-10 08:15 | transfer_processor  | Final confirmation sent to customer

3 gün sonra: “Bu transfer’i kim onayladı?”

→ Log’dan: approval_manager, 2026-09-10 07:26’da, “KYC updated” notu ile.

Özet: Karma Ekip Prensipleri

İş bölümü açıktır: Ajan hangisini, İnsan hangisini yapar?
Policy dosya tabanlı: Git’te versionlanır, PR ile onaylanır
Onay roller tanımlı: Kimin veto hakkı var?
Log tam tutulur: Her adımda kimin ne yaptığı kaydedilir
Rollback mümkün: Yanlış kural yazıldı mı → eski versiyona dön

Bunlar olmadığında: bir şey patladı, Mali Müdür ve transfer_processor suçluyu araştırıyor, ikisi de “benim görevim değildi” diyor.

Bunlar olduğunda: git log + policy dosyası + audit trail = tam sorumluluk zinciri.

Sonraki gün: Rol + Politika + Delegasyon + Git versioning hepsinin sentezini göreceğiz.