Arsitektur Agentic Work System dengan Codex untuk Perusahaan

Jawaban singkat

Arsitektur Codex untuk perusahaan sebaiknya berupa pipeline sembilan tahap: trigger terotorisasi, snapshot input, plan dengan stop condition, transformasi di workspace versioned, acceptance test, review packet, approval berbasis hash, eksekusi lewat adaptor terbatas, lalu rekonsiliasi dan audit evidence. Codex bekerja di tengah pipeline. Ia tidak menjadi sumber kebenaran, approver, atau pemegang credential produksi.

Reference architecture sembilan tahap

1. Trigger terotorisasi

Jangan memulai dari prompt bebas untuk pekerjaan material. Gunakan issue, tiket, folder, jadwal, atau request form yang mempunyai owner dan status approved. Trigger menyebut tujuan, scope, deadline, klasifikasi data, serta expected output. Permintaan yang tidak lengkap masuk queue, bukan ditebak oleh agent.

2. Acquire minimum data

Ambil hanya data yang dibutuhkan. Ekspor ERP dan HRIS bersifat read-only. API memakai field dan endpoint allowlist. File diberi ID run, timestamp, checksum, serta sumber. Dataset sensitif ditokenisasi atau disanitasi. Snapshot memungkinkan test diulang pada bahan yang sama.

3. Plan dan stop condition

Codex menyusun daftar file, command, aturan, dan test. Plan menyebut asumsi serta approval. Stop condition konkret: schema berubah, total kontrol berbeda, dokumen tak tepercaya meminta akses baru, dependency belum disetujui, atau output menyentuh path di luar scope. Agent berhenti dan membuat exception, bukan berimprovisasi.

4. Transform di branch

Skrip, template, mapping, dan AGENTS.md berada dalam repository. Satu run membuat branch atau workspace sendiri. Input mentah tidak ditimpa. Output dipisahkan dari log. Perubahan rule dan hasil transaksi tidak digabung dalam satu approval agar reviewer dapat melihat mana perubahan sistem dan mana hasil kerja.

5. Verify

Jalankan checks dari yang murah ke yang mahal: schema, required field, row count, totals, duplicate, referential integrity, unit test, lint, type-check, integration test, dan policy rule. Test gagal menghentikan pipeline. Override hanya boleh dilakukan approver bernama dengan alasan tercatat.

6. Review packet

Paket review berisi ringkasan satu halaman, diff, exception, bukti test, provenance, asumsi, dan keputusan yang diminta. Jangan membanjiri reviewer dengan seluruh log tanpa navigasi. Namun log mentah harus tetap tersedia untuk audit atau investigasi.

7. Approval berbasis hash

Approver memeriksa artefak dengan identitas pasti. Sistem mencatat hash, versi input, versi ruleset, identitas approver, scope, dan expiry. Edit satu karakter setelah approval berarti hash berubah. Paket kembali ke review, bukan tetap dianggap sah.

8. Controlled execution adapter

Adaptor eksekusi dipisahkan dari workspace agent. Ia hanya menerima format yang telah divalidasi dan token approval yang masih berlaku. Untuk banyak kasus, manusia tetap melakukan upload atau submit. Jika API dipakai, service account dibatasi pada satu aksi, threshold, dan periode tertentu.

9. Reconciliation, monitoring, rollback

Setelah eksekusi, baca kembali hasil dari sistem resmi. Cocokkan ID, jumlah, total, dan status terhadap paket approval. Simpan evidence dan ukur exception, rework, rejection, serta incident. Rollback dirancang sebelum pilot, bukan ketika produksi sudah bermasalah.

Contoh: rekonsiliasi invoice tanpa auto-payment

Trigger berasal dari close calendar. Sistem mengambil snapshot invoice, PO, dan BAST dari ekspor read-only. Codex menjalankan parser, normalisasi vendor, duplicate check, tax-field check, serta three-way match. Outputnya daftar matched dan exception beserta bukti baris sumber. AP reviewer memeriksa. Hanya kandidat yang disetujui masuk payment proposal. Treasury tetap menggunakan proses bank dan maker-checker yang berlaku.

Acceptance checks: semua file mempunyai checksum; total invoice input sama dengan matched plus exception; tidak ada duplicate ID; PO dan BAST dapat ditelusuri; rekening vendor tidak diubah; ruleset tercatat; output hash cocok dengan approval; hasil payment proposal direkonsiliasi. Satu kegagalan memblokir status "ready".

Repository workflow yang dapat dirawat

Struktur minimum dapat berisi folder inputs/snapshots, rules, templates, scripts, tests, outputs, dan evidence. AGENTS.md menjelaskan command yang diizinkan, path tulis, format output, serta larangan. CODEOWNERS atau kontrol sejenis menetapkan reviewer untuk rules dan connector. Jangan menaruh secrets dalam repository.

Pisahkan konfigurasi per lingkungan. Data dummy untuk development, salinan tersanitasi untuk benchmark, dan akses terbatas untuk pilot. Setiap perubahan mapping atau template mempunyai test regresi. Dengan begitu, pengetahuan proses tidak hanya hidup di prompt seseorang.

Rencana implementasi 30 hari

Hari 1-5: pilih satu workflow, dokumentasikan baseline, sumber data, owner, dan larangan. Hari 6-10: siapkan repository, data dummy, tests, serta threat model. Hari 11-15: bangun transformasi di sandbox dan kumpulkan kasus edge. Hari 16-20: bentuk review packet dan kalibrasi reviewer. Hari 21-25: jalankan shadow mode tanpa eksekusi. Hari 26-30: pilot terbatas dengan stop condition dan rollback.

Keputusan go/no-go tidak didasarkan pada demo terbaik. Lihat seluruh benchmark: true exception, false alarm, kasus terlewat, selisih rekonsiliasi, rework, reviewer minutes, dan kelengkapan evidence. Nol insiden data adalah guardrail, bukan klaim bahwa sistem bebas risiko.

Arsitektur ini perlu dipasangkan dengan threat model security dan UU PDP serta approval matrix yang eksplisit. Untuk menyiapkan tim lintas fungsi, lihat program pelatihan Codex.

Dasar faktual: apa yang memang dapat dilakukan Codex

[Fakta produk] OpenAI menjelaskan Codex sebagai agen software engineering. Ia dapat menerima tugas, membaca dan mengubah file di lingkungan kerja, menjalankan command, serta memakai hasil test, linter, atau type-check sebagai bukti. Pekerjaannya tetap perlu ditinjau dan divalidasi manusia sebelum perubahan diintegrasikan atau dijalankan. Dokumentasi dan repositori resmi Codex menjadi rujukan yang lebih tepat daripada demo singkat di media sosial.

Dari fakta itu, ada empat kemampuan yang relevan bagi perusahaan. Pertama, Codex bekerja pada artefak, bukan hanya percakapan. Kedua, ia dapat menjalankan langkah berurutan. Ketiga, hasilnya dapat diperiksa dengan alat yang deterministik. Keempat, ia dapat menyerahkan diff dan log agar reviewer tidak menebak apa yang berubah.

[Rekomendasi workflow] Penggunaan untuk finance, HR, legal, procurement, sales, atau operasi bukan fitur kepatuhan siap pakai dari OpenAI. Ini desain implementasi: tim menaruh skrip, template, aturan, data uji, dan instruksi kerja dalam repositori terkontrol; Codex mengolah ekspor read-only atau salinan tersanitasi; sistem resmi tetap menjadi sumber kebenaran. ERP, HRIS, Coretax, portal bank, portal regulator, dan tanda tangan pejabat tidak digantikan.

Pemisahan ini penting. Kemampuan mengedit CSV tidak berarti agent memahami kebijakan akuntansi perusahaan. Kemampuan membuat draft kontrak tidak menjadikannya penasihat hukum. Kemampuan menghasilkan file impor tidak memberinya wewenang untuk mengunggah, menandatangani, membayar, atau mengirim. Kewenangan selalu mengikuti struktur perusahaan, bukan kemampuan teknis model.

Pola kerja yang direkomendasikan

[Rekomendasi workflow] Pola yang aman dimulai dari trigger yang jelas: issue yang telah disetujui, folder masuk, jadwal closing, tiket, atau permintaan dengan pemilik. Sistem mengambil data minimum melalui path, tabel, atau domain yang diizinkan. Input dibekukan sebagai snapshot dan diberi checksum agar reviewer tahu persis bahan yang diproses.

Agent lalu membuat rencana singkat: tujuan, file yang akan disentuh, asumsi, pemeriksaan yang akan dijalankan, approval yang dibutuhkan, dan kondisi berhenti. Setelah itu barulah transformasi dilakukan di branch atau workspace terbatas. Semua template, aturan, dan instruksi seperti AGENTS.md diberi versi. Perubahan terhadap aturan tidak boleh menyelinap bersama hasil operasional.

Tahap verifikasi memakai pemeriksaan yang cocok dengan pekerjaan. Untuk data: schema, jumlah baris, total kontrol, duplikat, referential integrity, dan rekonsiliasi ke source. Untuk dokumen: kelengkapan field, nomor versi, tanggal berlaku, kutipan sumber, link, dan perbandingan dengan template. Untuk kode: unit test, integration test, lint, type-check, security scan, dan CI. Output yang lolos dikemas sebagai review packet berisi diff, exception, bukti test, hal yang belum terjawab, dan instruksi rollback.

Approval diberikan kepada artefak tertentu, bukan kepada instruksi samar. Identitas file, versi input, dan hash output dicatat. Jika isi berubah setelah approval, persetujuan batal dan harus diminta ulang. Eksekusi ke sistem resmi memakai adaptor terpisah dan service account terbatas. Setelah aksi, sistem merekonsiliasi hasil dan menyimpan evidence: siapa menyetujui, kapan, versi apa, hasil apa, serta apakah rollback diperlukan.

Acceptance checks yang layak dipakai

Acceptance check harus dapat menjawab "lulus atau gagal" tanpa bergantung pada rasa percaya kepada agent. Pemeriksaan minimum berikut dapat disesuaikan:

• input berasal dari snapshot yang teridentifikasi dan tidak berubah selama run;
• hanya path, tabel, command, dan domain allowlist yang diakses;
• schema, tipe data, jumlah baris, serta total kontrol cocok dengan sumber;
• exception tidak disembunyikan dalam output sukses;
• dokumen memakai template dan versi aturan yang berlaku;
• setiap klaim faktual memiliki sumber yang dapat dibuka;
• seluruh test wajib berstatus lulus dan log mentah tersedia;
• diff hanya menyentuh file yang tercantum dalam rencana;
• review packet menyebut asumsi, limitasi, dan item yang perlu keputusan;
• output yang disetujui mempunyai hash, approver, waktu kedaluwarsa, dan rollback instruction;
• aksi pada sistem resmi direkonsiliasi terhadap paket yang disetujui;
• data sementara dan log mengikuti jadwal retensi serta penghapusan.

Jangan memakai skor "confidence 95%" sebagai pengganti bukti. Angka tanpa kalibrasi pada kasus lokal tidak membantu approver. Tampilkan sumber, perbedaan, dan exception. Biarkan orang yang berwenang memutuskan.

Tindakan yang tetap di tangan manusia

Ada tindakan yang tidak layak diserahkan kepada agent, sekalipun output awalnya sering benar. Transfer uang, payroll release, perubahan rekening vendor atau pegawai, kredit, dan refund material harus melewati otorisasi manusia. Filing pajak atau regulator, deklarasi kepatuhan, token, sertifikat, serta tanda tangan elektronik juga tetap human-gated.

Kontrak, PO, offer letter, PHK, disiplin, rating kinerja, promosi, dan kompensasi final membutuhkan pejabat yang berwenang. Begitu pula pemilihan vendor, penyelesaian konflik kepentingan, publikasi eksternal, pernyataan media, production deploy, privileged command, account disable, tindakan containment destruktif, opini hukum, penerimaan risiko, opini audit, dan keputusan berdampak pada individu berdasarkan profiling.

Atur maker-checker secara nyata. Agent tidak boleh menjadi maker sekaligus checker hanya karena dua prompt dijalankan terpisah. Approver harus berbeda dari pemilik konfigurasi agent untuk aksi berisiko tinggi. Approval memiliki batas nilai, ruang lingkup, dan waktu. Sediakan kill switch serta jalur manual bila sistem gagal.

Security dan privasi minimum

Data perusahaan tidak otomatis aman hanya karena workflow berada di balik login. Petakan alirannya: dari mana input berasal, data apa yang ikut, di mana diproses, siapa yang dapat membaca log, berapa lama disimpan, dan ke mana output dikirim. Klasifikasikan data sebelum memilih tool. Terapkan purpose limitation, minimization, redaction atau tokenization, dan larang secrets masuk ke prompt, file kerja, screenshot, maupun log.

Gunakan SSO dan MFA bila tersedia, least privilege, service account terpisah, vault untuk secrets, serta elevasi berbatas waktu. Sandbox adalah default. Hak tulis dibatasi ke workspace yang memang dibutuhkan. Network deny-by-default lalu buka domain yang disetujui. Catat egress. Jangan menaruh credential produksi di lingkungan agent.

Dokumen, email, issue, dan halaman web adalah input tak tepercaya. Isinya dapat memuat instruksi yang mencoba mengubah perilaku agent. Pisahkan konten dari instruksi sistem, hilangkan active content, batasi ekstraksi, tandai provenance, dan minta review sebelum konten memicu aksi. Pin dependency, pindai package, tinjau connector pihak ketiga, dan gunakan branch terproteksi untuk konfigurasi penting.

[Konteks resmi Indonesia] UU Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi mengatur pemrosesan data pribadi, hak subjek data, kewajiban pengendali dan prosesor, perlindungan, serta penanganan pelanggaran. PP Nomor 71 Tahun 2019 memberi baseline penyelenggaraan sistem dan transaksi elektronik. Implementasi konkret tetap perlu diperiksa terhadap aturan pelaksana dan regulator sektor. Untuk HR, payroll, pelanggan, kesehatan, keuangan, monitoring, atau profiling, lakukan pemetaan data dan penilaian dampak yang proporsional sebelum pilot.

Cara menjalankan review mingguan

Tinjau sepuluh run secara acak dan seluruh run yang gagal. Bandingkan input, output, diff, serta keputusan reviewer. Kelompokkan kegagalan menjadi masalah data, aturan, tool, akses, atau judgment. Jangan langsung memperbaiki prompt bila sumbernya adalah master data yang buruk atau SOP yang bertentangan. Tetapkan owner dan tanggal perbaikan.

Periksa juga perilaku reviewer. Approval yang selalu lolos dalam hitungan detik adalah sinyal kontrol semu. Gunakan calibration case: dua reviewer menilai paket yang sama, lalu membahas perbedaan. Hasilnya dapat dipakai untuk memperjelas acceptance criteria dan escalation path.

Kondisi berhenti yang sering terlupakan

Agent harus berhenti ketika input tidak lengkap, schema berubah, total kontrol selisih, sumber tidak dapat ditelusuri, instruksi dokumen bertentangan dengan policy, akses baru diperlukan, atau aksi keluar dari scope. Status berhenti harus informatif: apa yang gagal, bukti, risiko bila diteruskan, dan siapa yang dapat menyelesaikannya.

Jangan mengubah stop menjadi warning hanya agar demo tampak mulus. Dalam operasi, kemampuan menolak pekerjaan yang tidak aman sama pentingnya dengan kemampuan menyelesaikan kasus normal. Ukur jumlah stop yang benar, stop palsu, serta kasus berisiko yang lolos.

Handover ke operasi

Handover mencakup repository, inventory akses, diagram data flow, runbook, benchmark, hasil test, known limitations, approval matrix, incident contact, rollback, dan jadwal review. Tetapkan siapa yang merawat ruleset ketika template, regulator, sistem, atau organisasi berubah. Tanpa owner, workflow akan tetap berjalan dengan aturan kedaluwarsa.

Cabut akses sementara milik trainer dan developer setelah handover. Uji pemulihan dari backup dan jalur manual. Minta operator baru menjalankan satu kasus normal dan satu kasus gagal tanpa bantuan pembuat. Bila mereka tidak dapat menjelaskan evidence, operasi belum siap.

Sumber primer

• OpenAI -- Introducing Codex
• OpenAI -- Codex documentation
• OpenAI -- Agent approvals and security
• OpenAI -- Codex Security
• OpenAI -- Codex CLI repository
• UU Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi
• PP Nomor 71 Tahun 2019 tentang Penyelenggaraan Sistem dan Transaksi Elektronik
• UU Nomor 11 Tahun 2008 tentang ITE dan UU Nomor 1 Tahun 2024
• UU Nomor 40 Tahun 2007 tentang Perseroan Terbatas

Regulasi dan dokumentasi produk dapat berubah. Periksa versi terbaru serta aturan sektor sebelum implementasi.

Langkah berikutnya

Jika tim Anda ingin mengubah satu use case menjadi workflow yang dapat diuji, direview, dan dihentikan dengan aman, diskusikan Pelatihan AI untuk Perusahaan. Fokus awalnya bukan demo sebanyak mungkin, melainkan satu pilot yang punya owner, acceptance checks, approval, dan evidence yang jelas.