Perkembangan AI agent sedang bergerak ke fase yang lebih struktural. Fokusnya tidak lagi semata-mata pada cara membuat model bahasa semakin cerdas, melainkan pada cara mengemas pengetahuan domain, prosedur kerja, integrasi sistem, skrip, referensi, dan aturan operasional menjadi kemampuan yang dapat digunakan ulang oleh banyak agent. Dalam konteks inilah Agent Skills dan Agent Plugins menjadi penting.
Secara ringkas, Agent Skills menyediakan format terbuka untuk menyimpan pengetahuan prosedural yang dibutuhkan agent saat bekerja, sedangkan Agent Plugins menyediakan format paket portabel untuk membungkus skill dan/atau server MCP sebagai satu unit yang dapat ditemukan dan dimuat secara konsisten oleh klien yang kompatibel [1][2]. Pada 6 Agustus 2026, Google secara resmi mengumumkan dukungannya terhadap Agent Plugins 1.0.0 dan menyatakan ikut bergabung sebagai Core Maintainer, melengkapi kolaborasi vendor-neutral yang sebelumnya melibatkan Amazon, Cursor, Microsoft, OpenAI, dan Vercel [3].
Jika dibaca sepintas, perubahan ini tampak seperti pembakuan struktur folder dan berkas JSON semata. Namun dampaknya berpotensi jauh lebih besar. Kita mungkin sedang melihat lahirnya software packaging layer untuk era AI agent: sebuah lapisan yang membuat kemampuan agent menjadi artefak yang lebih modular, dapat dipindahkan, dapat ditinjau, dan dapat dikelola seperti komponen perangkat lunak.
Ada masalah nyata yang mendorong kemunculan pendekatan ini. Dalam generasi awal aplikasi LLM, banyak sistem dibangun dengan pola sederhana: pengguna memberi instruksi, model membaca prompt, lalu model memberi jawaban. Ketika kasus penggunaan masih ringan, pendekatan tersebut memadai. Akan tetapi saat agent harus mengerjakan tugas kompleks, system prompt mulai dipenuhi aturan bisnis, langkah prosedural, petunjuk API, format keluaran, pengecualian, contoh, bahkan potongan skrip. Pada titik tertentu, prompt bukan lagi sekadar instruksi bahasa alami, melainkan sesuatu yang sudah menyerupai program, tetapi belum diperlakukan seperti program.
Masalah dari pola itu cukup jelas: sulit diuji, sulit dipakai ulang, sulit dipindahkan antar-agent, dan sulit dipisahkan antara pengetahuan umum model dengan cara kerja spesifik organisasi. Inilah alasan mengapa diskusi tentang prompt engineering mulai bergeser ke arah yang lebih matang, yaitu capability engineering. Yang dibangun bukan hanya respons model, tetapi kemampuan yang utuh.
Menurut spesifikasi resmi, sebuah Agent Skill adalah folder yang minimal berisi file SKILL.md. Di dalamnya, pengembang dapat menambahkan scripts/, references/, assets/, dan sumber daya lain yang dibutuhkan agent untuk menjalankan suatu alur kerja [1]. Artinya, kombinasi antara pengetahuan, prosedur, dan material pendukung mulai diperlakukan sebagai artefak perangkat lunak yang eksplisit, bukan sekadar teks instruksi yang tercecer di dalam prompt.
- Model menyediakan kemampuan penalaran umum.
- Skill menyimpan cara kerja spesifik untuk suatu tugas.
- Tool/MCP memberi akses ke sistem dan tindakan eksternal.
- Plugin membungkus semuanya menjadi paket yang portabel.
Di sini penting untuk menegaskan apa itu Agent Skill. Skill bukan model AI, bukan API, dan bukan sekadar fungsi tunggal. Skill lebih tepat dipahami sebagai pengetahuan prosedural yang menjelaskan kepada agent bagaimana suatu pekerjaan harus dilakukan. Misalnya, organisasi asuransi dapat memiliki prosedur review claim yang berisi validasi nomor polis, pemeriksaan status polis, pengambilan dokumen, analisis bukti medis, pengecekan exclusion, perhitungan keyakinan, hingga eskalasi ke manusia bila tingkat keyakinan rendah. LLM mungkin memahami konsep klaim asuransi secara umum, tetapi hanya organisasi tersebut yang mengetahui SOP internal, ambang risiko, terminologi operasional, dan alur persetujuan yang berlaku. Itulah jenis pengetahuan yang cocok dipaketkan sebagai skill.
Salah satu kekuatan penting Agent Skills adalah konsep progressive disclosure. Spesifikasi menjelaskan bahwa saat tahap penemuan, agent cukup memuat nama dan deskripsi skill. File SKILL.md lengkap baru dibaca ketika skill diaktifkan, sedangkan referensi atau skrip tambahan hanya dimuat bila benar-benar diperlukan [1]. Pendekatan ini penting karena masalah context window tidak mungkin diabaikan. Bila sebuah enterprise agent memiliki ratusan skill, memuat seluruh isi skill sekaligus akan sangat tidak efisien. Dengan kata lain, Agent Skills mendorong arsitektur mirip lazy loading untuk pengetahuan prosedural.
Spesifikasi juga memberi sinyal praktis tentang disiplin desain skill. Dokumen resmi merekomendasikan agar isi utama SKILL.md dijaga di bawah 5.000 token dan kurang dari 500 baris [1]. Rekomendasi ini memperlihatkan bahwa skill bukan ditujukan menjadi gudang dokumentasi tanpa batas, melainkan unit kemampuan yang fokus, ringkas, dan mudah diaktifkan sesuai konteks.
Perbedaan antara skill dan tool juga perlu diperjelas, karena keduanya sering disamakan. Tool menjawab pertanyaan: apa yang bisa dilakukan agent? Misalnya get_customer(), get_policy(), atau calculate_benefit(). Sebaliknya, skill menjawab pertanyaan: kapan dan bagaimana kemampuan itu dipakai? Sebuah claim review skill dapat mengorkestrasi beberapa tool sekaligus: mengambil data nasabah, memeriksa status polis, membaca dokumen medis, mengecek aturan pengecualian, lalu menghasilkan rekomendasi. Dengan rumusan yang lebih presisi: tool menyatakan kapabilitas tindakan, sedangkan skill menjelaskan prosedur penggunaan kapabilitas tersebut.
Pada titik ini, MCP atau Model Context Protocol masuk sebagai lapisan yang berbeda. MCP mendefinisikan cara aplikasi AI terhubung ke sistem eksternal melalui konsep seperti tools, resources, dan prompts [4]. Jadi, bila skill memberi know-how, MCP memberi kemampuan bertindak terhadap sistem nyata seperti basis data, CRM, dokumen, layanan API, atau file system. Itulah sebabnya skill dan MCP bukan pengganti satu sama lain, melainkan saling melengkapi.
Secara arsitektural, pembagian ini sangat membantu:
- Skill: menjelaskan bagaimana pekerjaan dilakukan.
- MCP: membuka akses ke alat dan sistem yang diperlukan.
- Agent: memilih langkah berikutnya berdasarkan tujuan dan konteks.
Ketika dua lapisan ini digabung, kita memperoleh fondasi agent yang jauh lebih rapi. Bayangkan ada tugas customer complaint analysis. Skill mendeskripsikan urutannya: cari pelanggan, ambil riwayat interaksi, ambil polis terkait, periksa komplain sebelumnya, analisis akar masalah, tentukan tingkat keparahan, lalu rekomendasikan tindakan. Agar semua itu berjalan, agent membutuhkan akses melalui MCP ke CRM, sistem polis, sistem keluhan, dan manajemen dokumen. Skill memberi alur, MCP memberi akses, agent menjalankan orkestrasi.
Namun setelah skill dan MCP tersedia, muncul masalah berikutnya: packaging. Sebelum ada format yang seragam, pengembang bisa saja perlu menata ulang komponen yang sebenarnya sama untuk setiap klien AI atau lingkungan agent yang berbeda. Situs resmi Agent Plugins secara eksplisit menyebut persoalan ini: penulis sering harus rearrange or duplicate komponen yang sama untuk memenuhi format plugin atau wrapper dari masing-masing klien [2]. Dengan kata lain, skill sudah cukup portabel, MCP juga cukup portabel, tetapi paket yang membawa keduanya belum tentu interoperabel.
Agent Plugins mencoba menjawab titik masalah tersebut. Dalam spesifikasi v1.0.0, plugin didefinisikan sebagai direktori dengan struktur tetap, termasuk plugin.json di akar, direktori skills/ untuk skill, dan mcp.json untuk konfigurasi MCP [2]. Ini penting karena klien yang kompatibel tidak perlu menebak lagi di mana skill berada atau bagaimana konfigurasi MCP ditemukan. Format tersebut membuat proses penemuan dan pemuatan kapabilitas menjadi konsisten.
Meski demikian, ada nuansa penting yang harus dijaga agar analisis tetap akurat. Agent Plugins 1.0.0 saat ini lebih tepat dipahami sebagai portable package specification, bukan sebagai package manager lengkap [2]. Spesifikasi secara eksplisit tidak menetapkan mekanisme instalasi, distribusi, model izin, sandboxing, verifikasi provenance, trust system, atau pengalaman pengguna lintas platform [2]. Karena itu, menyamakan Agent Plugins dengan npm untuk AI masih terlalu jauh. Analogi yang lebih tepat adalah: ia mulai menyediakan format paketnya, tetapi belum menyediakan seluruh ekosistem manajemen paketnya.
Status ini justru menarik. Dalam sejarah komputasi, banyak ekosistem besar berawal dari pembakuan format dan konvensi minimal sebelum berkembang menjadi registry, sistem distribusi, dan alat tata kelola yang lebih matang. Maka, klaim bahwa Agent Plugins dapat menjadi fondasi software ecosystem untuk AI agent adalah analisis yang masuk akal, tetapi tetap harus diposisikan sebagai implikasi, bukan fakta yang sudah selesai terwujud.
Bila seluruh komponen itu dirangkum, kita mulai melihat tumpukan arsitektur agent yang lebih jelas:
- LLM: kemampuan bahasa dan penalaran umum.
- Agent runtime: perencanaan, orkestrasi, memori, dan eksekusi.
- Skills: pengetahuan prosedural.
- MCP: akses ke tool, data, dan sistem eksternal.
- Plugins: lapisan pengemasan dan interoperabilitas.
Pemisahan concern semacam ini penting bagi enterprise. Ia memungkinkan organisasi memisahkan apa yang bersifat umum dari model, apa yang bersifat prosedural dari bisnis, apa yang terkait integrasi sistem, dan apa yang hanya menyangkut distribusi paket. Hasil akhirnya adalah kemampuan agent yang lebih dapat dikelola.
Salah satu implikasi bisnis paling kuat adalah perubahan SOP menjadi executable knowledge. Saat ini banyak prosedur organisasi hidup dalam bentuk PDF, dokumen Word, presentasi, wiki, atau email. Dokumen-dokumen itu dibaca manusia, tetapi belum siap digunakan langsung oleh AI. Ketika SOP diterjemahkan ke dalam skill, sebagian pengetahuan operasional dapat bergerak dari dokumentasi pasif menuju prosedur yang dapat diaktifkan oleh agent. Ini tidak berarti agent harus mengambil semua keputusan secara otomatis. Namun secara konseptual, ada perpindahan besar dari knowledge base menuju knowledge execution.
Dari sudut tata kelola, format berbasis folder juga membuka peluang agar skill dikelola seperti kode sumber. Situs Agent Skills menegaskan bahwa skill dirancang sebagai format yang portabel dan version-controlled [1]. Ini memberi dasar kuat bagi organisasi untuk menerapkan praktik rekayasa perangkat lunak yang sudah dikenal, seperti kontrol versi, pull request, peninjauan perubahan, riwayat revisi, dan rollback. Proses seperti persetujuan legal atau risiko atas perubahan prosedur dapat ditempatkan di alur kerja Git. Perlu ditegaskan, mekanisme PR atau review bukan aturan normatif dari spesifikasi, melainkan ekstrapolasi praktik engineering yang logis di atas format tersebut.
Skill juga tidak harus berdiri sendiri sebagai unit kecil yang datar. Dokumentasi MCP tentang Build with Agent Skills memberi contoh plugin referensi mcp-server-dev yang memiliki beberapa skill komposisi seperti build-mcp-server, build-mcp-app, dan build-mcpb. Salah satu skill berperan sebagai entry point yang menganalisis use case, memilih pola yang sesuai, lalu merutekan ke skill yang lebih spesifik [5]. Ini menunjukkan bahwa skill dapat berfungsi sebagai router atau composing capability, bukan sekadar instruksi prosedural linear. Dalam konteks bisnis, pola yang sama dapat dipakai untuk layanan pelanggan, underwriting, investigasi fraud, atau alur kepatuhan.
Pemisahan antara RAG, skill, MCP, dan agent juga layak diberi penekanan. RAG terutama menjawab: informasi apa yang relevan? Skill menjawab: prosedur apa yang harus dijalankan? MCP menjawab: sistem apa yang harus diakses? Agent menjawab: langkah berikutnya apa? Karena itu, skill bukan pengganti RAG. Keduanya bekerja di dimensi berbeda dan dapat saling menguatkan. Sebuah skill bisa memerintahkan agent untuk memeriksa aturan pengecualian, sementara RAG digunakan untuk mengambil wording polis atau pedoman medis yang relevan sebelum agent membuat penalaran akhir.
Dari sisi ekonomi produk, format yang portabel membuka kemungkinan lahirnya pasar kapabilitas. Penting untuk berhati-hati: sumber primer tidak memberikan data adopsi pasar atau bukti bahwa marketplace telah terbentuk luas. Namun sebagai proyeksi, bila skill dan plugin makin interoperabel, maka vendor atau pengembang independen dapat menjual kombinasi workflow, pengetahuan domain, template, integrasi MCP, dan dukungan implementasi sebagai produk. Dalam skenario itu, nilai tidak hanya terletak pada model AI yang dipakai, tetapi pada pustaka kapabilitas yang divalidasi dan siap diterapkan pada domain tertentu.
Di sinilah gagasan vertical AI menjadi semakin realistis. Membangun AI farmasi, perbankan, asuransi, atau legal tidak selalu harus dimulai dari satu aplikasi monolitik. Organisasi dapat menyusun kemampuan yang dapat dikomposisikan: peninjauan resep, edukasi pasien, analisis inventori, peninjauan KYC, investigasi fraud, analisis klaim, dan sebagainya. Plugin menjadi wadah yang membungkus skill dan integrasi sistem untuk domain tertentu. Model dapat berubah, tetapi lapisan kapabilitas tetap menjadi aset organisasi.
Meski menjanjikan, ada caveat besar: format yang portabel tidak identik dengan keamanan. Spesifikasi MCP menegaskan bahwa tool dapat merepresentasikan jalur menuju arbitrary code execution dan harus diperlakukan dengan sangat hati-hati [4]. Selain itu, spesifikasi Agent Plugins v1 secara eksplisit tidak membawa model izin portabel, tidak mewajibkan sandboxing, dan tidak mendefinisikan sistem trust maupun provenance [2]. Karena itu, asumsi plugin installed = plugin trusted adalah asumsi yang berbahaya.
Secara praktis, kepercayaan harus dibangun di lapisan klien dan tata kelola enterprise. Plugin idealnya melewati validasi, pembatasan izin, kebijakan akses, audit, dan pengawasan eksekusi. Untuk enterprise, ini berarti adopsi Agent Plugins tidak dapat dipisahkan dari diskusi tentang identity, authorization, pemisahan lingkungan, perlindungan data, dan observabilitas.
Ada juga permukaan serangan baru yang patut diperhatikan: skill injection. Karena skill pada dasarnya memuat instruksi prosedural untuk agent, perubahan kecil pada SKILL.md dapat mengubah perilaku operasional agent secara signifikan. Karena itu, praktik seperti protected branch, peninjauan wajib, validasi CI, penandatanganan artefak, dan pelabelan rilis layak dipertimbangkan sebagai best practice. Ini bukan persyaratan resmi spesifikasi, tetapi konsekuensi logis bila skill diperlakukan sebagai pengetahuan operasional yang dapat dieksekusi.
Aspek berikutnya adalah pengujian. Bila kemampuan agent benar-benar dipaketkan sebagai artefak, maka ia perlu diperlakukan seperti perangkat lunak: diuji sebelum digunakan. Skenario pengujian dapat dirancang untuk memverifikasi apakah suatu skill menghasilkan rekomendasi yang diharapkan pada kondisi polis aktif, dokumen tidak lengkap, atau pengecualian manfaat tertentu. Sumber primer tidak memberikan standar pengujian baku untuk skill, sehingga area ini masih terbuka. Namun secara analitis, kebutuhan akan skill linting, pengujian skenario, evaluasi regresi, dan pemeriksaan keamanan hampir pasti akan tumbuh bersama adopsi enterprise.
Dari sudut strategi teknologi, standar terbuka semacam Agent Skills, MCP, dan Agent Plugins juga berpotensi mengurangi biaya perpindahan antar-vendor. Pernyataan yang aman adalah ini: spesifikasi menyediakan portable core dan memungkinkan ekstensi khusus klien melalui namespace berbasis reverse-domain yang dapat diabaikan klien lain [2]. Dari fakta tersebut, dapat disimpulkan bahwa sebagian kapabilitas berpotensi tetap dipertahankan ketika organisasi berganti klien atau runtime agent. Namun ini tetap merupakan implikasi, bukan jaminan penuh bahwa vendor lock-in akan hilang.
Semua perkembangan ini mengarah pada perubahan pertanyaan utama dalam AI enterprise. Dulu, pertanyaan dominan adalah: model mana yang paling pintar? Kini, pertanyaannya mulai bergeser menjadi: kemampuan apa yang benar-benar dimiliki agent, bagaimana kemampuan itu dipaketkan, diuji, diawasi, dan diotorisasi? Dalam banyak kasus bisnis, keunggulan kompetitif mungkin tidak lagi terutama berasal dari memiliki model sendiri, melainkan dari memiliki pustaka kapabilitas yang kaya: skill milik sendiri, integrasi MCP internal, prosedur yang tervalidasi, dan evaluasi yang matang.
Dengan demikian, Agent Skills dan Agent Plugins memang tampak sederhana karena sebagian besar tersusun dari folder, Markdown, dan JSON. Tetapi justru kesederhanaan itu yang membuatnya kuat. Agent Skills menstandardisasi cara pengetahuan prosedural diberikan kepada agent [1]. MCP menstandardisasi cara agent terhubung ke tool dan sistem eksternal [4]. Agent Plugins menstandardisasi cara komponen-komponen tersebut dikemas menjadi paket yang portabel [2].
Kesimpulan besarnya adalah ini: kita mungkin sedang menyaksikan transisi dari prompt engineering menuju capability engineering. Dalam transisi tersebut, SOP dapat berubah menjadi skill, integrasi sistem menjadi MCP, dan gabungan keduanya menjadi plugin. Jika ekosistem ini berkembang matang, organisasi akan memiliki bukan hanya agent yang cerdas, tetapi juga perpustakaan kemampuan yang dapat dipindahkan, dikomposisikan, diaudit, dan dikembangkan lintas platform. Masa depan agent tampaknya bukan satu super-agent yang mengetahui semuanya, melainkan agent umum yang diperkuat oleh ribuan kapabilitas spesialis yang dipaketkan dengan baik.
Daftar sumber primer:
- [1] Agent Skills Specification — https://agentskills.io/specification
- [2] Agent Plugins Specification v1.0.0 — https://agent-plugins.org/specification
- [3] Google Developers Blog, “Agent Plugins package your skills, tools, and more” (6 Agustus 2026) — https://developers.googleblog.com/agent-plugins-package-your-skills-tools-and-more/
- [4] Model Context Protocol Specification (2025-03-26) — https://modelcontextprotocol.io/specification/2025-03-26
- [5] Build with Agent Skills — Model Context Protocol Docs — https://modelcontextprotocol.io/docs/develop/build-with-agent-skills