3.4 Observational Memory

Tujuan bab

Setelah bab ini kamu bisa:

• Menjelaskan masalah yang diselesaikan observational memory dan kenapa tiga lapisan sebelumnya tidak cukup
• Mengaktifkannya, baik dalam bentuk minimal maupun dengan model khusus
• Menjelaskan peran Observer dan Reflector
• Memutuskan kombinasi lapisan memory yang tepat untuk sebuah aplikasi
• Menjelaskan konsekuensi biaya dari agent yang bekerja di latar belakang

Prasyarat

• 3.3 Semantic Recall
• @mastra/memory versi 1.1.0 atau lebih baru

Masalah percakapan yang sangat panjang

Bayangkan agent yang menemani satu pekerjaan selama berhari-hari — asisten riset, atau pendamping pengembangan produk. Setelah seribu pesan, situasinya begini:

• Message history hanya menampung sebagian kecil di ujung
• Semantic recall bisa menemukan potongan relevan, tapi potongan mentah seringkali kehilangan konteks di sekitarnya
• Working memory ringkas, tapi memang dirancang untuk fakta stabil, bukan untuk merangkum jalannya pekerjaan

Yang hilang adalah pemahaman atas keseluruhan: apa yang sudah dicoba, apa yang gagal dan kenapa, keputusan apa yang sudah diambil.

Kamu bisa saja meminta model merangkum percakapan secara berkala, dan menyisipkan rangkuman itu. Observational Memory pada dasarnya mengotomatiskan ide tersebut — tapi dengan cara yang lebih terstruktur daripada sekadar meringkas.

Cara kerjanya

Observational Memory memakai agent latar belakang — dokumentasi menyebutnya Observer dan Reflector — yang mengamati percakapan agent utamamu dan memelihara sebuah log observasi yang padat. Seiring percakapan tumbuh, log itu menggantikan riwayat pesan mentah.

Tanpa OM                          Dengan OM
┌────────────────────┐            ┌────────────────────┐
│ pesan 981          │            │ Log observasi:     │
│ pesan 982          │            │ - Tujuan: X        │
│ ...                │            │ - Sudah dicoba: Y  │
│ pesan 1000         │            │ - Gagal karena: Z  │
└────────────────────┘            │ - Keputusan: W     │
 20 pesan terakhir,               └────────────────────┘
 980 pesan sebelumnya              + pesan terkini
 tidak terwakili

Perbedaan pentingnya dari sekadar meringkas: yang dipelihara adalah observasi, bukan transkrip yang dipadatkan. Log ini menahan hal-hal yang bertahan nilainya — tujuan, hasil percobaan, keputusan — dan membuang basa-basi yang tidak lagi berguna.

Karena Observer dan Reflector adalah agent yang berjalan di latar belakang, pekerjaan ini tidak menambah latensi pada giliran percakapan yang sedang berlangsung.

Mengaktifkannya

Bentuk paling sederhana:

// src/mastra/agents/riset-agent.ts
import { Agent } from '@mastra/core/agent'
import { Memory } from '@mastra/memory'

export const risetAgent = new Agent({
  id: 'my-agent',
  name: 'my-agent',
  instructions: 'Kamu asisten yang membantu.',
  model: 'openai/gpt-5-mini',
  memory: new Memory({
    options: {
      observationalMemory: true,
    },
  }),
})

Storage wajib

Dokumentasi menandai ini secara khusus: Observational Memory memerlukan storage provider. Kamu bisa memasangnya di instance Mastra pada src/mastra/index.ts, atau memberikannya langsung ke konstruktor Memory.

Dengan model khusus

Observer dan Reflector adalah agent, jadi mereka memakai model. Kamu bisa menentukan model mana:

// src/mastra/agents/riset-agent.ts
import { Agent } from '@mastra/core/agent'
import { LibSQLStore } from '@mastra/libsql'
import { Memory } from '@mastra/memory'

const memory = new Memory({
  storage: new LibSQLStore({
    id: 'memory-storage',
    url: 'file:./memory.db',
  }),
  options: {
    observationalMemory: {
      model: 'openai/gpt-5-mini',
    },
  },
})

export const risetAgent = new Agent({
  id: 'memory-agent',
  name: 'Memory Agent',
  instructions: 'Kamu asisten yang membantu.',
  model: 'openai/gpt-5-mini',
  memory,
})

Pola yang lazim: model yang lebih ringan untuk pekerjaan latar belakang, dan model yang lebih kuat untuk agent utama. Observer tidak perlu menulis prosa yang indah; ia hanya perlu mencatat observasi dengan tepat.

Melihatnya bekerja

// run.mjs
import { mastra } from './src/mastra/index.ts'

const agent = mastra.getAgentById('memory-agent')

const memoryOptions = {
  resource: 'user-123',
  thread: 'conversation-123',
}

const pertama = await agent.generate('Ingat bahwa warna favorit saya biru.', {
  memory: memoryOptions,
})
console.log(pertama.text)

const kedua = await agent.generate('Apa warna favorit saya?', {
  memory: memoryOptions,
})
console.log(kedua.text)

Memelihara working memory

Satu kemampuan yang menghubungkan bab ini dengan 3.2: opsi observationalMemory.observation.manageWorkingMemory memungkinkan Observational Memory memperbarui working memory untuk agent.

Ini pembagian kerja yang rapi. Alih-alih agent utama harus memutuskan kapan memperbarui catatannya sendiri di tengah melayani pengguna, pekerjaan itu diserahkan ke pengamat yang memang tugasnya memperhatikan.

Memilih kombinasi lapisan

Setelah empat bab, kamu punya empat mekanisme. Tidak semuanya perlu di setiap aplikasi. Panduan memilih:

Jenis aplikasi	History	Working	Semantic	Observational
Tanya-jawab sekali pakai	—	—	—	—
Chatbot FAQ	✅	—	—	—
Asisten pribadi	✅	✅	—	—
Support dengan riwayat kasus	✅	✅	✅	—
Pendamping kerja jangka panjang	✅	✅	✅	✅

Pola yang terlihat: tambahkan lapisan saat masalahnya muncul, bukan di awal. Setiap lapisan menambah biaya dan bagian yang bisa salah. Aplikasi dengan keempatnya aktif tanpa alasan yang jelas lebih sulit didiagnosis daripada yang hanya memakai apa yang dibutuhkan.

Pertanyaan pemandu:

Ongkos yang perlu disadari

Observer dan Reflector adalah agent, dan agent memanggil model. Artinya observational memory menambah panggilan model di luar giliran percakapan.

Kabar baiknya: karena berjalan di latar belakang, ia tidak memperlambat respons ke pengguna. Kabar yang perlu diperhitungkan: ia tetap muncul di tagihan.

Karena itu pemilihan model untuk pekerjaan latar belakang bukan detail sepele. Memakai model termahal untuk Observer pada aplikasi dengan ribuan percakapan adalah cara cepat mendapat kejutan di akhir bulan.

Kesalahan umum

Gejala: Error terkait storage saat observational memory diaktifkan, padahal message history sebelumnya berjalan normal. Penyebab: Storage terpasang di satu tempat tapi tidak terlihat oleh Memory yang bersangkutan — misalnya kamu membuat new Memory() dengan konfigurasi sendiri yang tidak menyertakan storage, sementara storage hanya ada di instance Mastra dan tidak terwarisi pada susunan yang kamu pakai. Perbaikan: Pastikan storage tersedia bagi Memory tersebut. Cara paling aman saat memakai konfigurasi Memory yang terpisah adalah memberikan storage langsung ke konstruktornya, seperti pada contoh di bab ini.

Gejala: Biaya naik jauh lebih tinggi dari perkiraan setelah observational memory dinyalakan, padahal jumlah pengguna tidak berubah. Penyebab: Agent latar belakang memakai model yang mahal, dan mereka bekerja untuk setiap percakapan, bukan hanya yang panjang. Perbaikan: Tetapkan model yang lebih ringan lewat observationalMemory: { model: '...' }. Nyalakan fitur ini hanya pada agent yang percakapannya memang panjang — bukan pada semua agent di aplikasimu.

Coba sendiri

Tantangan: Bangun pendamping-agent, asisten yang menemani pengguna menyelesaikan satu proyek kecil selama beberapa sesi, lalu ukur apa yang disumbangkan observational memory.

Ketentuan:

1. Aktifkan message history dengan lastMessages: 6 dan observational memory dengan model yang lebih ringan dari model agent utama
2. Pasang LibSQLStore berbasis file langsung pada konstruktor Memory
3. Jalankan percakapan minimal 20 giliran dalam satu thread, yang di dalamnya: satu tujuan ditetapkan, dua pendekatan dicoba dan gagal karena alasan berbeda, dan satu keputusan diambil
4. Di giliran terakhir, tanyakan: "Ringkas apa yang sudah kita capai dan apa yang tidak berhasil, beserta alasannya."
5. Buat agent pembanding yang identik tapi tanpa observational memory, jalankan percakapan yang sama, dan ajukan pertanyaan yang sama
6. Bandingkan kedua jawaban

Checklist penerimaan:

• [ ] Versi dengan observational memory bisa menyebut kedua pendekatan yang gagal beserta alasannya — termasuk yang dibahas di giliran-giliran awal
• [ ] Versi tanpa observational memory hanya bisa menyebut hal-hal yang masih berada dalam enam pesan terakhir
• [ ] Model untuk agent latar belakang berbeda dari model agent utama, dan kamu bisa menjelaskan alasan pemilihannya
• [ ] Kamu bisa menyebutkan satu jenis aplikasi di mana observational memory justru berlebihan
• [ ] Kamu memperhatikan apakah waktu respons terasa berbeda antara kedua versi — dan bisa menjelaskan kenapa hasilnya begitu

Petunjuk: Untuk checklist terakhir: karena Observer dan Reflector bekerja di latar belakang, waktu respons keduanya seharusnya terasa mirip. Kalau kamu menemukan perbedaan besar, kemungkinan yang kamu ukur adalah variasi biasa antar panggilan model, bukan efek observational memory.

Ikhtisar

• Observational Memory memakai agent latar belakang — Observer dan Reflector — yang memelihara log observasi padat, dan log itu menggantikan riwayat pesan mentah seiring percakapan tumbuh.
• Yang dipelihara adalah observasi (tujuan, percobaan, kegagalan, keputusan), bukan transkrip yang dipadatkan.
• Diaktifkan dengan observationalMemory: true, atau bentuk objek untuk menentukan model. Storage wajib.
• Karena bekerja di latar belakang, ia tidak menambah latensi giliran percakapan — tapi tetap menambah panggilan model, jadi pilih model yang ringan.
• observationalMemory.observation.manageWorkingMemory memungkinkan OM memperbarui working memory untuk agent.
• Tambahkan lapisan memory saat masalahnya muncul, bukan di awal. Keempat lapisan aktif tanpa alasan hanya membuat sistem lebih mahal dan lebih sulit didiagnosis.

Lanjut ke mana

Bagian 3 selesai. Agent-mu bisa mengarahkan diri, bertindak lewat tool, dan mengingat dalam empat cara berbeda — tapi semua keputusannya masih diserahkan pada model. Untuk proses yang langkahnya sudah kamu ketahui, itu bukan yang kamu inginkan: Bagian 4 — Workflows.