DEV Community

Cover image for Perangkat Lunak Tanpa Kepala: API Anda Adalah Produk Utama
Walse
Walse

Posted on • Originally published at apidog.com

Perangkat Lunak Tanpa Kepala: API Anda Adalah Produk Utama

Singkatnya: Agen AI diam-diam menghilangkan UI dari perangkat lunak perusahaan. Lapisan data, yang terekspos melalui API dan MCP, menjadi permukaan produk baru. Berikut lima perubahan yang perlu dilakukan tim API pada kuartal ini, plus satu masalah yang belum benar-benar terselesaikan.

Antarmuka pengguna dulu adalah benteng utama perangkat lunak B2B. Sales bekerja di Salesforce. Support bekerja di Zendesk. Procurement bekerja di SAP. Frekuensi akses, memori otot, dan formulir UI yang memaksa kebersihan data membuat pengguna tetap berada di dalam produk. Data hanya menjadi hasil samping dari aktivitas tersebut.

Coba Apidog hari ini

Era itu sedang berubah. Agen AI sekarang dapat membaca dan menulis data perusahaan langsung melalui API tanpa membuka browser. Salesforce telah mengumumkan produk headless yang mengekspos lapisan datanya ke agen. Sistem pencatat lain kemungkinan hanya tertinggal beberapa minggu, bukan bertahun-tahun. Jika UI bukan lagi benteng, API-lah bentengnya. Itu mengubah cara API harus dirancang, diuji, dan diamankan.

Apa arti "perangkat lunak tanpa kepala" dalam praktik

Perangkat lunak tanpa kepala adalah perangkat lunak perusahaan yang mengekspos lapisan datanya melalui API sehingga agen dapat membaca dan menulis secara langsung. UI tidak hilang, tetapi berhenti menjadi satu-satunya pintu masuk.

Ini berbeda dari "API-first" dan "headless CMS".

  • API-first adalah metodologi desain.
  • Headless CMS adalah arsitektur konten.
  • Perangkat lunak tanpa kepala adalah perubahan konsumen: yang membaca dan menulis data bukan lagi manusia dengan browser, melainkan agen dengan akses MCP dan sebuah tujuan.

Tiga hal membuat perubahan ini terjadi bersamaan:

  1. LLM mampu merencanakan dan memilih tool.
  2. MCP menstandardisasi cara agen menemukan sistem eksternal.
  3. Ekstraksi data menjadi murah, sehingga membatasi API tidak lagi cukup untuk melindungi lapisan data.

Jika API Anda masih dirancang dengan asumsi "developer menulis client sekali, lalu manusia menggunakannya setiap hari", ada pekerjaan yang harus dilakukan.

Lima faktor daya rekat yang mulai melemah

Secara historis, sistem perusahaan menjadi "lengket" karena lima hal. Dilihat dari perspektif agen, sebagian besar faktor ini melemah.

1. Frekuensi akses

Manusia terkunci oleh kebiasaan. Sales masuk ke Salesforce berkali-kali sehari selama bertahun-tahun.

Agen tidak memiliki memori otot. Mengganti tool bagi agen sering kali hanya berarti mengubah konfigurasi.

{
  "crm_provider": "salesforce",
  "fallback_provider": "hubspot",
  "workflow": "create_opportunity"
}
Enter fullscreen mode Exit fullscreen mode

Jika kontrak API stabil, agen tidak peduli UI mana yang ada di belakangnya.

2. Alur kerja baca-tulis

Migrasi sistem enterprise dulu berisiko karena data terus bergerak melalui UI.

Agen membaca dan menulis pada kecepatan mesin. Selama API menjaga kontrak, database di belakangnya bisa berubah tanpa memengaruhi workflow agen.

3. SOP yang tidak terdokumentasi

Contoh aturan bisnis:

"Deal di atas $100K memerlukan approval VP."

Aturan seperti ini masih sulit untuk agen. Ini memberi ruang bagi sistem lama untuk bertahan. Namun, setiap workflow agen yang berjalan akan mendorong aturan tersebut dikodekan di tempat yang dapat dibaca mesin.

4. Lingkaran kebiasaan internal

Tim sering membentuk rutinitas di sekitar tool yang sama. Daily workflow mengikuti UI.

Saat pekerjaan harian mengalir melalui agen, pusat aktivitas berpindah dari UI ke kontrak API, event, dan policy.

5. Kritikalitas kepatuhan

Ini satu-satunya faktor yang tetap kuat.

Regulasi tidak peduli apakah data dipindahkan oleh manusia atau agen. Audit trail tetap wajib. Karena itu, pertahanan baru akan tumbuh di sekitar identitas agen, permission, policy, dan audit.

Lima hal yang perlu diubah tim API pada kuartal ini

Jika API menjadi permukaan produk baru, tim API perlu mengubah cara mendesain dan mengoperasikannya.

1. Perlakukan API sebagai permukaan produk, bukan pipa internal

Endpoint REST yang dibuat hanya "agar frontend bisa memanggilnya" berbeda dari endpoint yang akan dipilih dan dipanggil agen.

API untuk frontend internal masih bisa punya inkonsistensi. API untuk agen tidak bisa.

Jika Anda mendesain API untuk agen AI, kontrak harus menjadi antarmuka utama:

  • nama endpoint harus deskriptif;
  • skema request dan response harus konsisten;
  • field tidak boleh punya arti ganda;
  • error harus bisa ditindaklanjuti oleh model;
  • dokumentasi harus cukup jelas tanpa membaca source UI lama.

Contoh error yang buruk:

{
  "error": "Bad Request"
}
Enter fullscreen mode Exit fullscreen mode

Contoh error yang lebih berguna untuk agen:

{
  "error": {
    "code": "missing_required_field",
    "message": "Field wajib customer_id belum dikirim.",
    "action": "Kirim customer_id pelanggan yang memiliki invoice ini.",
    "field": "customer_id"
  }
}
Enter fullscreen mode Exit fullscreen mode

Uji lakmusnya sederhana:

Bisakah agen yang kompeten memanggil API Anda dengan benar hanya dari spesifikasi OpenAPI dan deskripsi field?

Jika jawabannya "harus baca source frontend dulu", API Anda masih berupa pipa internal.

2. Kirim MCP bersama REST dan GraphQL

REST adalah cara agen memanggil API setelah mereka tahu API tersebut ada.

MCP adalah cara agen menemukan kemampuan sistem sejak awal.

API REST tanpa server MCP mirip situs web tanpa robots.txt dan sitemap. Secara teknis bisa diakses, tetapi sulit ditemukan oleh sistem yang ingin menggunakannya.

Anda tidak perlu mengganti REST atau GraphQL. Pertahankan keduanya. Tambahkan MCP sebagai dialek ketiga yang mengekspos kemampuan yang sama melalui protokol yang dipahami agen.

Contoh mapping konseptual:

tools:
  - name: create_invoice
    description: Membuat invoice baru untuk customer.
    input_schema:
      type: object
      required:
        - customer_id
        - line_items
      properties:
        customer_id:
          type: string
        line_items:
          type: array
Enter fullscreen mode Exit fullscreen mode

REST endpoint-nya tetap bisa seperti ini:

POST /invoices
Content-Type: application/json
Authorization: Bearer <agent_token>
Enter fullscreen mode Exit fullscreen mode

Jika Anda butuh pengantar MCP untuk tim API, baca penyelaman mendalam kami.

3. Desain skema berdasarkan maksud dan hasil, bukan hanya objek CRUD

Model data enterprise biasanya berisi objek seperti:

  • Opportunity
  • Lead
  • Account
  • Contact
  • Ticket
  • Invoice

Agen tidak berpikir dalam bentuk objek CRUD. Agen berpikir dalam tujuan:

  • "Temukan akun yang berisiko churn."
  • "Susun proposal untuk deal yang ditutup kemarin."
  • "Eskalasi akun yang membuka tiket P0 semalam."

Generasi berikutnya dari sistem pencatat akan lebih banyak mengekspos tugas, maksud, policy, thread, dan outcome.

Artinya, Anda tidak harus menulis ulang semua skema malam ini. Mulailah dengan menambahkan lapisan intent di atas CRUD.

Contoh endpoint CRUD tradisional:

POST /opportunities
POST /activities
POST /tasks
Enter fullscreen mode Exit fullscreen mode

Untuk agen, lebih baik sediakan endpoint berbasis maksud:

POST /intents/capture-purchase-signal
Enter fullscreen mode Exit fullscreen mode

Request:

{
  "lead_id": "lead_123",
  "signal": "Prospek menyatakan siap membeli paket enterprise",
  "source": "sales_call_transcript"
}
Enter fullscreen mode Exit fullscreen mode

Response:

{
  "created": {
    "opportunity_id": "opp_456",
    "activity_id": "act_789",
    "task_id": "task_101"
  },
  "next_action": "schedule_follow_up"
}
Enter fullscreen mode Exit fullscreen mode

Agen cukup menyatakan maksud. Sistem Anda yang memutuskan objek internal apa saja yang perlu dibuat.

Panduan tentang mempersiapkan API Anda untuk agen AI membahas pola ini lebih dalam.

4. Selesaikan identitas agen dan izin berlingkup

Ini bagian yang belum sepenuhnya terselesaikan.

Setiap panggilan agen membutuhkan:

  • identitas agen;
  • identitas pengguna yang didelegasikan;
  • scope yang jelas;
  • audit trail terpisah;
  • policy yang dapat diuji.

Jika API Anda tidak bisa membedakan ini:

"Alice mengklik tombol refund."

dari ini:

"Agen milik Alice menjalankan refund atas namanya pada jam 3 pagi."

maka sistem Anda belum siap untuk workflow agen.

Minimal, setiap request agen perlu membawa metadata seperti:

X-Acting-On-Behalf-Of: user_123
X-Agent-Identity: billing-agent@1.4.2
X-Agent-Run-Id: run_abc_789
Enter fullscreen mode Exit fullscreen mode

Lihat kebijakan keamanan MCP untuk pola yang bisa digunakan saat ini.

5. Bangun lapisan tindakan dengan audit dan feedback loop

Pertahanan baru bukan sekadar menyimpan data. Pertahanan baru ada pada kemampuan mengambil tindakan, merekam hasil, lalu menggunakan hasil tersebut untuk memperbaiki keputusan berikutnya.

Untuk tim API, ini berarti tiga hal.

Endpoint tindakan harus punya callback atau webhook hasil

Agen perlu tahu apakah tindakan berhasil, gagal, atau perlu eskalasi.

POST /actions/refund
Enter fullscreen mode Exit fullscreen mode

Request:

{
  "invoice_id": "inv_123",
  "amount": 25,
  "reason": "duplicate_charge",
  "callback_url": "https://example.com/agent-callbacks/refund-result"
}
Enter fullscreen mode Exit fullscreen mode

Setiap tindakan harus bisa diputar ulang

Jika agen melakukan sesuatu yang salah, Anda perlu merekonstruksi input, output, dan konteksnya.

{
  "agent_run_id": "run_abc_789",
  "action": "refund_invoice",
  "input": {
    "invoice_id": "inv_123",
    "amount": 25
  },
  "output": {
    "refund_id": "refund_456",
    "status": "processed"
  }
}
Enter fullscreen mode Exit fullscreen mode

Setiap tindakan perlu audit row

Audit row minimal:

{
  "timestamp": "2026-05-26T10:30:00Z",
  "actor_type": "agent",
  "agent_identity": "billing-agent@1.4.2",
  "acting_on_behalf_of": "user_123",
  "action": "refund_invoice",
  "resource": "invoice:inv_123",
  "policy_version": "billing-policy@2026-05-01",
  "result": "success"
}
Enter fullscreen mode Exit fullscreen mode

Jika Anda bisa menyimpan reasoning trace dengan aman, tambahkan. Jika tidak, simpan input, output, policy, dan decision point.

Untuk sisi operasional, baca Menguji alur kerja agen tanpa kehilangan data.

Bagian yang belum terpecahkan: pemberian izin agen

Dari semua celah dalam perangkat lunak siap agen, permission adalah yang paling penting dan paling belum matang.

Pertanyaannya:

Agen mana yang boleh melakukan apa, atas nama siapa, dengan auditabilitas apa?

Jawaban jujur pada 2026: hampir belum ada yang menyelesaikan ini dengan baik.

  • OAuth dibangun untuk akses pengguna yang didelegasikan, bukan agen otonom.
  • RBAC dibangun untuk peran manusia.
  • Audit log dibangun untuk aktivitas pengguna, bukan aktivitas agen di bawah policy tertentu.

Namun, ada empat pola yang bisa diterapkan sekarang.

1. Gunakan token berlingkup per identitas agen

Jangan gunakan ulang session token pengguna untuk agen.

Buat token terpisah:

{
  "sub": "agent:billing-agent",
  "acting_on_behalf_of": "user_123",
  "scopes": [
    "invoice:read",
    "refund:create:under_50"
  ],
  "expires_in": 3600
}
Enter fullscreen mode Exit fullscreen mode

Jika token bocor, Anda mencabut agen, bukan akun pengguna.

2. Tambahkan metadata delegasi pada setiap request

Header sederhana sudah meningkatkan audit secara signifikan:

X-Acting-On-Behalf-Of: user_123
X-Agent-Identity: billing-agent@1.4.2
X-Agent-Run-Id: run_abc_789
X-Policy-Version: billing-policy@2026-05-01
Enter fullscreen mode Exit fullscreen mode

Ini tidak harus mengubah seluruh logic endpoint. Tetapi log, alert, dan audit akan menjadi jauh lebih jelas.

3. Pisahkan audit log agen dari audit log manusia

Aktivitas agen memiliki pola query berbeda.

Tim compliance akan bertanya:

  • "Agen apa saja yang aktif minggu ini?"
  • "Refund apa saja yang dibuat oleh agen?"
  • "Policy versi mana yang mengizinkan tindakan itu?"
  • "Tindakan mana yang dilakukan di luar jam kerja pengguna?"

Simpan audit agen di tabel atau stream yang dapat dianalisis terpisah.

CREATE TABLE agent_audit_log (
  id TEXT PRIMARY KEY,
  timestamp TIMESTAMP NOT NULL,
  agent_identity TEXT NOT NULL,
  acting_on_behalf_of TEXT NOT NULL,
  action TEXT NOT NULL,
  resource TEXT NOT NULL,
  policy_version TEXT NOT NULL,
  result TEXT NOT NULL
);
Enter fullscreen mode Exit fullscreen mode

4. Jadikan policy sebagai code

Jangan simpan permission agen hanya di wiki.

Gunakan file konfigurasi berversi:

agents:
  billing-agent:
    version: "1.4.2"
    allowed_actions:
      - invoice:read
      - refund:create
    constraints:
      refund:create:
        max_amount: 50
        requires_human_approval_above: 50
    denied_actions:
      - account:delete
      - payment_method:update
Enter fullscreen mode Exit fullscreen mode

Dengan policy sebagai code, Anda bisa:

  • review via pull request;
  • test di CI;
  • rollback;
  • membandingkan perubahan antar versi;
  • mengaitkan audit log ke policy tertentu.

Tidak ada pola di atas yang sudah menjadi standar final. Namun semuanya bisa dikirimkan sekarang.

Di mana Apidog cocok

Jika API akan diperlakukan sebagai produk, Anda memerlukan workflow yang mencakup desain, kontrak, mocking, MCP, pengujian, dan audit. Itulah alasan kami membangun Apidog.

Lima perubahan di atas bisa dipetakan ke workflow API yang konkret:

  • API sebagai produk: gunakan desain berbasis skema dan dokumentasi otomatis agar kontrak menjadi sumber kebenaran bagi manusia dan agen.
  • MCP bersama REST: gunakan alat pengujian server MCP untuk memverifikasi server MCP sebelum dirilis.
  • API berbentuk maksud: gunakan mocking dengan respons dinamis untuk membuat prototipe endpoint intent sebelum backend selesai.
  • Permission agen: gunakan environment management untuk memisahkan token agen dari token pengguna, lalu tambahkan assertion test untuk policy.
  • Lapisan tindakan dan audit: gunakan AI Agent Debugger dan A2A Debugger untuk melacak, memutar ulang, dan memvalidasi panggilan API yang digerakkan agen.

Jika Anda belum mencobanya, unduh Apidog dan jalankan spesifikasi OpenAPI yang sudah ada. Mulai dari mock server, lalu lanjutkan ke pengujian kontrak, skenario agen, dan validasi MCP.

Taruhan untuk tim API

Taruhannya sederhana: API itu sendiri sekarang adalah produk.

Jika API hanya pipa internal, ia akan menjadi komoditas. Jika API menjadi permukaan tempat agen memahami kemampuan, memilih tindakan, menjalankan policy, dan meninggalkan audit trail, API menjadi benteng baru.

Tim yang bergerak pada kuartal ini akan membangun permukaan API yang berbeda dari API lima tahun lalu:

  • lebih eksplisit;
  • lebih terdokumentasi;
  • lebih mudah ditemukan agen;
  • lebih aman untuk delegasi;
  • lebih mudah diaudit;
  • lebih siap untuk workflow tanpa UI.

Tim yang menunggu akan menulis ulang di bawah tekanan saat pelanggan utama mulai bertanya mengapa integrasi agen mereka "tidak berfungsi dengan baik."

Top comments (0)