> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.
# Agent
> Apa yang harus dilakukan setiap lapisan arsitektur ketika pesertanya bukan manusia — runtime di luar protokol, penerimaan di bawah beban agent, otorisasi sebagai transaksi, dan lingkungan yang bisa diputar ulang.
Arah yang sedang dibangun di sini adalah keadaan di mana **satu orang diwakili oleh beberapa agent**, masing-masing bertindak atas sebagian dari apa yang orang itu inginkan. Bukan satu orang dengan satu alat, dan bukan bot yang menjalankan skrip tetap — melainkan beberapa pihak lawan di pasar yang semuanya bertanggung jawab kepada satu akun.
Ketika pesertanya berubah, mikrostruktur pasar ikut berubah. Ukuran order turun dan laju pesan naik, rasio pembatalan terhadap eksekusi melebar lebih jauh lagi, dan alirannya memperoleh korelasi yang tidak dimiliki aliran manusia: agent yang membaca sinyal yang sama sampai pada kesimpulan yang sama pada saat yang sama. Tidak satu pun dari itu selesai dengan menambah satu fitur. Itu selesai dengan menyusuri arsitektur selapis demi selapis dan menanyakan apa yang harus dilakukan masing-masing secara berbeda.
Halaman ini adalah susuran itu, berurutan, dengan posisi sebenarnya dari tiap lapisan.
1 · Aplikasi
2 · Jaringan
3 · Eksekusi
4 · State
Runtime berada di luar protokoldan tidak memegang hak istimewa apa pun — tidak ada latensi lebih rendah, data lebih awal, atau antarmuka yang tak bisa dijangkau pihak ketiga
Penerimaan, ketika pengirimnya adalah agentpembatalan yang terlambat lebih buruk daripada order yang terlambat, dan keadilan dilacak lewat riwayat terkini, bukan per pesan
Otorisasi adalah sebuah transaksipunya tinggi blok, berada di dalam set instruksi tertutup — dan mencabutnya membatalkan order terpasang milik agent itu di blok yang sama
Lingkungan yang bisa diputar ulang, berversi per blokpoint-in-time karena konstruksinya, bukan karena disiplin
Empat lapisan yang sama dengan ikhtisar arsitektur. Yang berbeda hanya pertanyaannya: apa yang harus dilakukan masing-masing ketika pesertanya bukan manusia?
| Lapisan | Apa yang berubah | Status |
| ------------ | -------------------------------------------------------------------------------------- | ---------------------------------------------------------------- |
| **Aplikasi** | Runtime — riset dan eksekusi — berada di luar protokol dan tidak memegang hak istimewa | Dikomitmenkan |
| **Jaringan** | Penerimaan di bawah aliran yang meletup, terkorelasi, dan padat pembatalan | Sudah ada, dengan dua pertanyaan terbuka |
| **Eksekusi** | Otorisasi menjadi transaksi yang membawa syarat | Sudah ada dalam bentuk semua-atau-tidak; syaratnya dikomitmenkan |
| **State** | Chain itu sendiri adalah lingkungan tempat agent dinilai | Sudah ada |
1 · Aplikasi — runtime berada di luar, dan memang harus
Runtime agent adalah kerangka riset dan eksekusi: ia membentuk pandangan, mengubahnya menjadi sesuatu yang bisa dijalankan, lalu menyodorkannya ke bursa. Ia berjalan di lapisan aplikasi, setingkat dengan front end dan klien API, dan **bukan bagian dari protokol**.
Penempatan itu adalah kendala fisik sebelum menjadi preferensi desain. Model bernalar dalam hitungan detik; pasar bergerak dalam milidetik. Apa pun yang harus memanggil model tidak bisa berada di jalur yang benar-benar dilalui sebuah order — artinya **protokol ini sama sekali tidak memuat model**. Bukan karena kelalaian, melainkan karena model di jalur penyelesaian akan menghancurkan satu-satunya sifat yang menopang segala hal lain di sini. Jalur eksekusi harus menghasilkan bita yang sama di setiap node, dan inferensi tidak melakukan itu.
Jadi runtime hidup di luar, dan pertanyaan jujurnya menjadi: apa yang protokol utangkan kepadanya. Lima hal, semuanya dikomitmenkan dan belum tersedia.
| | Apa yang diberikannya kepada agent |
| ----------------------------------- | -------------------------------------------------------------------------------------------------- |
| **Simulasi pra-transaksi** | Menilai apa yang akan dilakukan sebuah order terhadap state yang sudah dikomit sebelum mengirimnya |
| **Pengiriman idempoten** | Mencoba ulang pengiriman yang hasilnya ambigu tanpa risiko eksposur ganda |
| **State akhir yang bernama** | Tidak ada hasil yang tak diketahui — setiap tindakan berakhir di state yang punya nama |
| **Pelanjutan yang terdefinisi** | Agent yang restart tahu sampai mana ia tadi dan apa langkah berikutnya |
| **Tanda terima yang diatribusikan** | Apa yang dilakukan agent, di bawah wewenang siapa, dan berapa biayanya — sebagai keluaran protokol |
Statusnya lihat [Apa berikutnya](/id/protocol/roadmap/whats-next).
Runtime tidak memegang jalur istimewa apa pun. Tidak ada latensi lebih rendah, tidak ada data lebih awal, dan tidak ada antarmuka yang tak bisa dijangkau runtime pihak ketiga. Ini layak dinyatakan alih-alih diandaikan, karena di tempat lain arsitektur ini mengklaim bahwa tidak ada apa pun yang berdiri antara seorang trader dan Lembaga Kliring — dan sebuah alat buatan sendiri dengan jalur khusus persis menjadi «apa pun» itu.
2 · Jaringan — penerimaan, ketika pengirimnya adalah agent
Mempool memutuskan apa yang layak disimpan, transaksi mana dari seorang pengirim yang berikutnya, peer mana yang mendengarnya, dan apa yang dibuang ketika permintaan melampaui kapasitas. Aliran agent menekan keempatnya, dan dua dari sifat yang menyerapnya sudah ada karena alasan yang mendahului agent.
**Pembatalan yang terlambat lebih buruk daripada order yang terlambat.** [Mempool](/id/protocol/architecture/mempool) memperlakukan lalu lintas order dan pembatalan sebagai asimetris sejak rancangannya. Agent membuat asimetri itu lebih ekstrem, karena rasio pembatalan terhadap eksekusinya lebih tinggi daripada manusia, tetapi bentuk masalahnya adalah bentuk yang menjadi dasar pembangunan lapisan ini.
**Keadilan dilacak lewat riwayat terkini, bukan per pesan.** Mempool menyimpan catatan bergulir tentang pengirim mana dan jenis lalu lintas mana yang belakangan menghabiskan kapasitas, lalu membentuk apa yang dilayani berikutnya berdasarkan itu. **Inilah bagian yang penting untuk letupan terkorelasi**: empat puluh agent yang membatalkan atas sinyal yang sama bukanlah empat puluh kali beban rata-rata yang tersebar merata, melainkan satu lonjakan. Batas per pesan tidak melihatnya. Ingatan tentang siapa yang belakangan berisik melihatnya.
**Konsensus tidak membesar seiring throughput.** Transaksi sampai ke validator sebagai batch yang ketersediaannya dibuktikan sebelum sebuah proposal boleh merujuknya, sehingga proposal blok membawa digest, bukan isi. Populasi agent yang menaikkan laju pesan satu orde besaran sama sekali tidak menaikkan ukuran pesan konsensus.
Blok menghapus perlombaan **di dalam** dirinya: dua transaksi dalam blok yang sama punya urutan yang dihitung identik oleh setiap node. **Jaminan itu dimulai di batas blok.** Masuk ke dalam blok masih merupakan perlombaan, dibentuk oleh keadilan tingkat pengirim, bukan dihapus olehnya. Penerimaan di mempool bukan pemasukan ke blok.
Dua pertanyaan di lapisan ini masih terbuka, dan keduanya baru menjadi nyata pada volume agent, bukan pada volume manusia.
**Berapa seharusnya biaya sebuah pembatalan.** Eksekusi sudah menempatkan pembatalan lebih dulu — ia berjalan di tahap sebelum apa pun yang bisa mengambil likuiditas. Versi jaringan dari pertanyaan itu belum selesai: pembatalan yang murah dan diprioritaskan adalah yang membuat quoting bisa dipertahankan, sekaligus cara termurah membanjiri sebuah mempool. Apakah pembatalan perlu punya akuntansi kapasitas sendiri, terpisah dari penempatan order, belum diputuskan.
**Idempotensi itu milik lapisan mana.** Agent yang tidak mendapat jawaban akan mengirim ulang. Pengiriman idempoten dikomitmenkan di lapisan eksekusi dan menuntaskan akibat yang penting — tidak ada eksposur ganda. Ia tidak menuntaskan versi lapisan jaringannya: apakah mempool harus mengenali pengiriman ulang sebagai niat yang sama, atau membawa keduanya dan membiarkan eksekusi melakukan deduplikasi. Di bawah badai percobaan ulang, keduanya berperilaku berbeda.
Ada satu hal yang sengaja tidak ada dalam daftar: jalur penerimaan terpisah untuk agent. Akses prioritas adalah yang pada akhirnya dijual setiap bursa terpusat, dan itu akan bertentangan dengan klaim bahwa tidak ada apa pun yang berdiri antara seorang trader dan Lembaga Kliring. Aliran agent lewat pintu yang sama.
3 · Eksekusi — otorisasi adalah sebuah transaksi
Inilah lapisan tempat model akun berubah, dan seluruh perubahan itu mengalir dari satu fakta.
**Menyerahkan sebuah akun kepada agent adalah transaksi on-chain.** Bukan formulir yang dikirim, bukan kunci API yang diterbitkan dari halaman pengaturan, bukan satu baris di basis data operator. Sebuah transaksi, di dalam blok, pada satu tinggi, ditandatangani oleh akun yang memberikannya — dan karenanya sesuatu yang bisa ditemukan, dibaca, dan diperiksa pihak ketiga mana pun tanpa bertanya kepada siapa pun.
Tiga akibat mengikuti, dan masing-masing adalah hal yang tak bisa dilakukan sebuah kunci API.
**Ia berada di dalam set instruksi tertutup.** Otorisasi agent adalah salah satu operasi terenumerasi milik [kernel](/id/protocol/architecture/kernel). Chain serbaguna tidak bisa mengungkapkannya — makna panggilannya akan menjadi bytecode yang tak tembus pandang. Bursa terpusat menegakkannya di dalam perangkat lunak yang tidak bisa Anda periksa. Di sini wewenang dan batasnya **adalah** instruksi itu sendiri, dan karena itu batasnya bisa diperiksa, bukan sekadar dijanjikan.
**Ia membawa apa yang boleh dilakukan agent — dan tak bisa membawa apa yang tidak boleh.** Sebuah otorisasi bisa menyatakan berapa yang boleh dipegang agent, berapa yang boleh hilang, pasar mana yang boleh disentuh, dan apakah ia boleh mengubah mode margin. Ia **tidak bisa menyatakan «tarik dana»**. Itu bukan setelan yang dibiarkan mati; istilah itu memang tidak ada untuk dituliskan. Agent yang mengoperasikan sebuah akun tidak punya jalur yang bisa diungkapkan untuk memindahkan dana keluar darinya.
**Mencabutnya membatalkan order terpasang milik agent itu.** Pencabutan juga sebuah transaksi, dan ia mendarat di blok yang [pengurutannya](/id/trading/tx-sequencing) sudah menjalankan pembatalan sebelum apa pun yang bisa mengambil likuiditas. Jadi order yang ditinggalkan agent di order book pergi di blok yang sama dengan wewenangnya. Di bursa tempat pencabutan berupa tulisan basis data, kuncinya berhenti bekerja dan order terpasangnya berada dalam keadaan tak terdefinisi. Di sini penghentiannya bisa dibuktikan, dan siapa pun bisa menemukan tinggi blok tempat itu terjadi.
MemberikanSebuah transaksi di blok NIa membawa cakupannya: apa yang boleh dipegang, berapa yang boleh hilang, apa yang boleh diperdagangkan agent itu. Ia tidak bisa membawa penarikan — istilah itu tidak ada
BertindakSetiap tindakan menyebut wewenangnyaDiatribusikan ke akun yang memberikannya, bukan hanya ke agent yang mengirimkannya
MencabutSebuah transaksi di blok MOrder terpasang milik agent itu dibatalkan di blok yang sama, sebelum apa pun yang bisa mengambil likuiditas dijalankan
Tidak satu pun dari ketiganya adalah tulisan basis data yang harus diberitahukan kepada Anda. Masing-masing adalah transaksi yang bisa ditemukan siapa pun pada satu tinggi blok.
Hari ini pemberiannya bersifat semua-atau-tidak dengan masa berlaku. Syarat yang lebih kaya di atas — berapa yang boleh dipegang agent, berapa yang boleh hilang, apa yang boleh dilakukan berikutnya — dikomitmenkan dan belum tersedia; lihat [Apa berikutnya](/id/protocol/roadmap/whats-next). **Yang sudah berlaku adalah bagian yang tak bisa ditambahkan belakangan**: wewenangnya adalah objek protokol, bukan catatan operator tentang sebuah wewenang.
Apa yang sudah dipikul bursa untuk runtime
Runtime perdagangan yang harus melindungi pengguna di bursa biasa pada akhirnya membangun inti istimewanya sendiri: buku posisi yang ia pelihara dan rekonsiliasi sendiri, pemeriksaan risiko pra-transaksi yang ia jalankan sendiri sambil berharap bursanya menghitung sama, dan log audit yang ia tulis dan tak bisa ia buktikan tidak diubah. **Ketiganya adalah redundansi terhadap bursa yang tidak mau menunjukkan bukunya.**
Di sini tiga dari itu adalah sifat protokol. [Lembaga Kliring](/id/protocol/architecture/clearinghouse) adalah satu-satunya penulis buku itu. Tahap risiko berjalan sebelum matching, di blok yang sama. Log auditnya adalah chain itu sendiri, dan setiap perubahan state membawa transaksi penyebabnya. Yang tersisa bagi runtime adalah yang keempat — gateway order yang idempoten — dan itu persoalan antarmuka, bukan persoalan kepercayaan.
Matching: bloknya sudah menjadi batch
Aliran agent menaikkan frekuensi dan menurunkan ukuran dari apa yang sampai ke order book, dan itulah mikrostruktur yang paling sering dipakai untuk membela lelang batch: interval diskret, dikliringkan bersama, tidak ada keuntungan dari datang satu mikrodetik lebih awal.
Sifat itu **sudah** berlaku di sini, dan bukan karena sebuah lelang batch ditambahkan. Waktu di dalam blok adalah posisi yang dikomit konsensus, bukan jam lokal, sehingga **di dalam blok tidak ada keuntungan di bawah milidetik** — dan pembatalan berjalan sebelum apa pun yang agresif, sehingga kuotasi basi bisa ditarik dan tidak bisa dicomot order yang datang bersamaan dengan pembatalannya. Blok adalah interval diskret yang dikliringkan bersama. Ia muncul sebagai **akibat** dari mengeksekusi urutan yang sudah dikomit, bukan sebagai tempelan desain pasar.
Apakah sesuatu di luar itu memang perlu — dan prioritas harga-waktu yang kontinu serta lelang batch yang sering adalah **alternatif, bukan tambahan**, karena sebuah batch dengan sengaja menghapus prioritas waktu di dalam dirinya — sedang dieksplorasi, bukan sedang dibangun.
4 · State — chain itulah lingkungannya
Sebuah agent hanya sebaik apa yang dipakai untuk menilainya, dan justru di penilaian itulah sebagian besar kegagalan terjadi. Strategi yang tampak menguntungkan di simulator lalu gagal di produksi biasanya bukan bertemu pasar baru; ia bertemu simulator yang bukan bursanya.
[Lapisan state](/id/protocol/architecture/state/model) menghapus jarak itu lewat konstruksi, bukan lewat disiplin. State berversi per blok, dan setiap perubahan diatribusikan ke transaksi penyebabnya, sehingga memutar ulang sebuah blok berarti memutar ulang **lingkungannya**, bukan model dari lingkungan itu — mesin state yang sama yang akan mengeksekusi agent itu, atas input yang sudah dikomit jaringan. Itulah pemeriksaan kelima di [Verifikasi sendiri](/id/developers/verify), dan itulah yang membuat backtest di sini menjadi jenis objek yang berbeda dari backtest terhadap API historis sebuah bursa.
Sifat yang lebih halus adalah bahwa ini **point-in-time karena konstruksinya**. Kumpulan data yang dirakit dari API bursa hanya point-in-time kalau yang merakitnya berhati-hati, dan look-ahead menyelinap lewat celah yang tak seorang pun perhatikan — kolom yang diisi belakangan, koreksi yang diterapkan ke riwayat, harga acuan yang direvisi. Di sini pertanyaan itu tidak muncul: state sebuah blok adalah apa yang benar pada blok itu, karena itulah satu-satunya bentuk yang pernah dimiliki state.
Apa yang menjadi lebih sulit
Membangun untuk agent bukan cuma daftar hal yang membaik.
**Determinisme itu bermata dua.** Sebuah agent bisa memprediksi apa yang akan dilakukan ordernya sendiri sebelum mengirimnya, karena input yang sama menghasilkan hasil yang sama di setiap node. **Agent milik orang lain juga bisa, tentang order Anda.** Reproduktibilitas menaikkan kemampuan Anda merencanakan dan keterdugaan Anda sekaligus, dan yang kedua tidak gratis.
**Likuiditas agent adalah likuiditas yang terkorelasi.** Market maker manusia menarik diri pada saat yang berbeda-beda karena mereka menyadarinya pada saat yang berbeda-beda. Agent yang membaca state publik yang sama sampai pada kesimpulan yang sama bersamaan. Order book yang ditopang agent lebih dalam pada hari biasa dan bisa menipis lebih cepat pada hari yang menentukan — itu risiko struktur pasar yang memang menjadi rancangan lapisan penyerap protokol, bukan risiko yang mereka hapus.
**Oracle membaca bursa tempat agent juga berdagang.** Pengesahan mengikat sebuah harga ke blok yang memakainya; ia tidak membuat pasar acuannya kebal manipulasi, dan populasi agent yang bertindak atas sinyal terkorelasi adalah satu lagi cara bagi acuannya bergerak bersama. Lihat [apa yang dijamin dan tidak dijamin oracle](/id/protocol/architecture/oracle).
**Penilaian diri sebuah agent bukan bukti.** Umpan balik perdagangan berisik dan tidak stasioner dengan cara yang tidak berlaku pada umpan balik kode — kompilator memberi tahu Anda bahwa Anda salah, sementara satu minggu yang untung tidak memberi tahu bahwa Anda benar. Apa pun yang dibangun sebuah bursa untuk agent harus memperlakukan laporan agent tentang kinerjanya sendiri sebagai **input adversarial**, bukan sebagai pengukuran. Itulah salah satu alasan pemeriksaan di [Verifikasi sendiri](/id/developers/verify) disusun di sekitar apa yang bisa dihitung ulang, bukan apa yang bisa dilaporkan.
Ke mana selanjutnya
Empat fase, dan mengapa yang harus berubah adalah akunnya.
Pemeriksaan yang membuat penilaian sebuah agent menjadi sesuatu selain klaim.
Apa yang tersisa untuk dipercaya, setelah yang bisa diperiksa diperiksa.
Status runtime agent dan syarat otorisasinya.