Pengembang Microsoft Teams diperingatkan bahwa menyebut setiap ekstensi sebagai “bot” kini dapat menyebabkan kegagalan pada tingkat produksi. Pada tahun 2026, batasan platform itu sendiri—10 hingga 15 detik untuk menjawab pesan—mengubah bot dengan arsitektur yang salah menjadi badai timeout, yang memaksa tim untuk merancang ulang pipeline mereka.

Mengapa perbedaan ini penting

Teams menawarkan tiga jenis ekstensi, yang masing-masing dibangun untuk pola interaksi yang berbeda. Mencampuradukkannya akan memaksakan penggunaan runtime yang salah, SDK yang salah, dan model penskalaan yang salah.

Teams apps, bots, dan agents – apa itu

  • Teams apps – Tab permukaan (surface tabs), halaman statis, atau komponen UI sederhana di dalam klien Teams. Pada dasarnya mereka adalah aplikasi web: stateless, dirender sesuai permintaan, dan dihosting seperti layanan HTTP lainnya. Tidak ada alur percakapan yang diharapkan.
  • Bots – Dibangun dengan Bot Framework SDK, bot mengikuti dialog yang telah ditentukan (scripted dialogs). Logikanya adalah pohon if/else deterministik yang memutuskan balasan berikutnya murni berdasarkan aktivitas yang masuk. Karena jalur keputusannya sudah diketahui sebelumnya, responsnya sesuai dengan jendela timeout platform yang singkat.
  • Agents – Entitas berbasis tujuan yang menerima objektif tingkat tinggi, sekumpulan alat (tools), dan LLM (large language model). Menggunakan Agents SDK atau Semantic Kernel, LLM memilih alat mana yang akan dipanggil, dalam urutan apa, dan kapan harus meminta klarifikasi kepada pengguna. Alurnya bersifat dinamis, sering kali memerlukan beberapa panggilan eksternal dan penalaran (reasoning) yang berat.

Perbedaannya sangat mencolok: bot bersifat deterministik; agent bersifat probabilistik dan mengorkestrasi panggilan alat pada saat runtime.

Jebakan timeout

Ketika pengembang menyematkan penalaran berat—seperti prompt LLM, pencarian basis data, atau panggilan API eksternal—langsung di dalam message handler bot, Teams melihat permintaan tersebut tertahan melampaui jendela 10-15 detiknya. Platform akan membatalkan respons dan mencoba lagi, yang dapat berujung pada pekerjaan ganda dan throttling. Gejalanya tampak seperti kesalahan “bot tidak merespons” yang terputus-putus, tetapi akar masalahnya adalah arsitektural.

Membangun pipeline asinkron yang siap produksi

  1. Webhook entry point – Endpoint HTTP bot menerima aktivitas Teams dan segera mengonfirmasi penerimaan.
  2. Queue the event – Handler mendorong payload ke antrean (queue) yang tahan lama seperti Azure Service Bus.
  3. Background worker – Azure Durable Function, trigger Service Bus, atau worker jangka panjang lainnya mengambil pesan, menjalankan penalaran LLM atau orkestrasi alat, dan mengirimkan balasan akhir kembali ke Teams melalui API proactive messaging Bot Framework.

Karena webhook awal memberikan respons secara instan, Teams tidak pernah mencapai batas timeout-nya, dan pekerjaan berat dapat berjalan sesuai kecepatannya sendiri. Antrean berfungsi sebagai penyangga (buffer) saat terjadi lonjakan, dan worker melakukan penskalaan otomatis (auto-scale) berdasarkan panjang antrean (backlog).

Panduan keputusan cepat (tes papan tulis)

  • Dapatkah Anda menggambar seluruh pohon keputusan sebelum menulis kode apa pun? Ya → Bangun sebuah bot. Alur deterministik sesuai dengan model Bot Framework dan tetap berada dalam jendela respons.
  • Apakah masalahnya ditentukan oleh tujuan tingkat tinggi dan daftar alat yang memungkinkan? Ya → Bangun sebuah agent. Biarkan LLM merencanakan dan memanggil alat; pindahkan proses perencanaan ke background worker.

Apa yang perlu diperhatikan selanjutnya

Panduan ini adalah bagian pertama dari seri untuk pengembang .NET 9 yang membangun solusi Teams cerdas di Azure.

Jika Anda sudah melihat kesalahan “Bot timed out” di log Teams, solusinya sederhana: pisahkan (decouple) webhook dari proses berat, gunakan worker berbasis antrean, dan pilih jenis ekstensi yang benar sejak awal. Platform memiliki batas timeout, tetapi arsitektur Anda dapat menghindarinya.

Kesimpulan: Salah melabeli ekstensi Teams sebagai bot akan memaksakan desain sinkron yang tidak dapat ditangani oleh Teams. Pisahkan permintaan dari penalaran, pilih SDK yang tepat, dan solusi Teams Anda akan tetap responsif bahkan ketika otak di baliknya adalah agent bertenaga LLM.