DEV Community: tauchi Bahasa Indonesia

Cara Code, IDE, dan Wiki di osFoundry menjaga pekerjaan beberapa agen AI paralel tetap mudah di-review

tauchiii — Fri, 06 Nov 2026 16:23:22 +0000

Sekarang jam 4 sore, dan sejak makan siang ada tiga agen coding yang mengerjakan repository yang sama. Satu memperbaiki pembulatan total keranjang belanja, satu menambahkan kode diskon, satu lagi menulis test. Ketiganya bilang "done". Sebelum apa pun menyentuh main, kamu ingin tahu dua hal: apakah ada dua agen yang menulis ulang fungsi yang sama, dan apakah ketiga perubahan itu masih lolos test kalau digabung?

Tiga layar untuk satu codebase

osFoundry adalah aplikasi desktop yang menyatukan chat, agen, file, dan tools dalam satu jendela, dan untuk urusan kode ada tiga layar yang saling terhubung. Code adalah tempat kamu membagikan tugas ke beberapa agen sekaligus: setiap run punya branch Git dan folder kerjanya sendiri (worktree), lalu kamu me-review, menguji, dan melihat pratinjau merge sebelum memutuskan apa pun. Tidak ada yang ter-merge dengan sendirinya. IDE adalah editor kode untuk folder lokal, lengkap dengan explorer, source control, terminal, panel Problems dan Tests, serta kolom asisten yang bisa melihat file yang sedang kamu buka. Wiki membaca repository di komputermu dan menulis halaman dokumentasi yang mengutip path:line, lalu menandai halaman itu ketika kode yang dikutip berubah. Code dan Wiki ada sebagai tab di samping Maestro, Model chat, Multi chat, dan Research; IDE punya item sendiri di sidebar. Kalau kamu terbiasa dengan VS Code dan panel Git-nya, IDE ini akan terasa familier. Code lebih mirip inbox pull request, bedanya penulisnya adalah agen-agenmu dan branch-nya tidak pernah keluar dari laptopmu.

Melihat tab Code

Yang kamu lihat di layar ini (run-nya adalah data contoh):

Banner di bagian atas kolom. "3 agents finished · they disagree on 1 file" menyebutkan nama file-nya, di sini src/cart.js, bahkan sebelum kamu membuka satu diff pun. Tombol Review together memulai review bersama.
Kolom run. Run dikelompokkan berdasarkan apa yang mereka butuhkan darimu: Ready to review, Needs attention, dan History yang dilipat. Setiap baris menampilkan tugas, jumlah baris yang ditambah dan dihapus, berapa lama agen bekerja, dan branch-nya.
Percakapan di tengah. Klik sebuah run dan kamu bisa membaca apa yang diminta dari agen dan apa yang ia katakan selama bekerja.
Panel kanan. Tab Changes, Files, Commits, Review, dan PR menampilkan diff asli setiap run, dimulai dari pekerjaan yang belum di-commit, lalu apa yang sudah di-commit ke branch-nya.
Merge station di kanan bawah. Pilih run yang sudah selesai, dan di sinilah kamu menguji serta melihat pratinjau saat semuanya di-merge bersama.

Contoh kasus: tech lead dengan tiga agen di satu repo

Dana memimpin tim web kecil dan membagi sprint checkout ke tiga run agen: memperbaiki pembulatan total keranjang, menambahkan kode diskon di checkout, dan menulis test untuk formatter harga. Setiap run dimulai dari New run dengan tugas satu baris dan agen yang dipilih khusus untuknya, jadi masing-masing punya branch dan folder sendiri, dan tidak ada yang bisa mengganggu file milik yang lain selama bekerja.

Saat banner bilang mereka berbeda pendapat, ia mencentang ketiga run dan mengklik Review together. Panel Merge menampilkan "3 runs · conflicts not checked yet · 3 not yet tested", sebuah "kami belum tahu" yang jujur, bukan lampu hijau. Di bawahnya, src/cart.js ditandai contested, dan hunk dari setiap branch ditampilkan berdampingan: perbaikan pembulatan dan kode diskon sama-sama menulis ulang total().

Berikutnya ia menekan test di setiap run. Test berjalan di dalam worktree milik run itu sendiri, jadi checkout miliknya tidak pernah tersentuh. Secara default berlaku "Tests must pass before a branch can merge", dan aturan itu bisa diubah di Settings. Ketiganya lolos, tapi lolos sendiri-sendiri tidak sama dengan lolos bersama, jadi ia menekan Preview combined merge. Aplikasi lebih dulu me-merge branch-branch itu di salinan sementara lalu melaporkan hasilnya: dua ter-merge dengan bersih, satu konflik.

Ia me-merge dua branch yang bersih ke branch-nya saat ini. Baru pada saat itulah branch-nya berubah. Branch kode diskon tetap ada, sehingga agen bisa mengulang perubahannya di atas perbaikan pembulatan. Seandainya ia ingin mengambil bagian terbaik dari tiap percobaan alih-alih branch utuh, Combine into a branch memungkinkannya mencentang hunk satu per satu dan membuat branch baru dari situ.

Satu detail lagi yang penting di hari-hari panjang: kalau aplikasi berhenti saat sebuah run sedang bekerja, run itu kembali dengan status Interrupted, bukan "running", disertai catatan bahwa branch-nya tetap disimpan.

Contoh kasus: developer solo yang refactoring dengan asisten

Kenji mengurus front end sebuah toko online seorang diri. Pagi ini ia perlu mengubah formatPrice, dan ia tidak yakin siapa saja yang memanggilnya. Ia membuka folder proyek di IDE dari sidebar. Tata letak editornya seperti biasa: Explorer dan Source Control di kiri, tab di tengah, Terminal, Output, Problems, dan Tests di bawah, dan Assistant di kanan, tempat ia bisa memulai chat yang disinkronkan atau chat lokal yang tetap di perangkat.

Ia klik kanan pada formatPrice dan memilih Show Code Graph. Panel ini menampilkan Callers dan Calls. Titik penuh berarti pemanggilan itu dibaca langsung dari kodenya; titik kosong berarti hasil inferensi, jadi yang itu sebaiknya dicek manual. Impact of change menelusuri pemanggil dari pemanggil dan, dalam contoh ini, menampilkan "15 symbols · 14 files · 3 tests". Mengklik sebuah baris akan melompat ke baris tersebut, dan Send to chat mengirim seluruh graf ke asisten sebagai konteks.

Belakangan, asisten mengedit sebuah file konfigurasi untuknya. Di Source Control file itu tampil sebagai modified, dan saat dibuka, ikon robot kecil dan status line menunjukkan bahwa file itu terakhir ditulis oleh AI, lengkap dengan model dan alasan yang diberikannya. Review membuka diff berdampingan terhadap salinan yang disimpan tepat sebelum penulisan itu, jadi ia hanya melihat perubahan tersebut. Di sini terlihat timeout dipangkas dari 30 detik menjadi 3, tepat di bawah komentar yang bilang upload besar butuh 20 detik atau lebih. Ia menangkapnya sebelum commit.

Kalau ada agen yang menulis ke sebuah file sementara ia masih punya editan yang belum disimpan di file itu, editor memberi tahu bahwa file berubah di disk selama ia mengedit dan menawarkan Keep mine atau Use the disk version, bukannya diam-diam memilih salah satunya.

Contoh kasus: support engineer yang perlu memahami kode, bukan mengubahnya

Priya bekerja di customer support dan sering ditanya bagaimana perilaku suatu bagian produk. Ia bisa membaca kode, tapi tidak mau grep ke sana kemari di repository yang bukan miliknya. Di Wiki ia memakai Open a folder (atau Clone a public repository dengan URL https atau git@), lalu aplikasi membaca struktur proyek di komputernya.

Sebelum menulis apa pun ke dalam proyek, Wiki bertanya dulu. Sebuah dialog menyebutkan folder persis yang akan dibuatnya di dalam repo, dan kalau ia mengklik Not now, tidak ada yang ditulis. Setelah ia setuju, ia memakai Generate pages atau Write a page untuk satu topik. Pengaturan menentukan seberapa banyak source code yang dipakai untuk menulis setiap halaman (Depth: Quick, Standard, atau Deep) dan berapa banyak klaim yang diperiksa (Verification: Off, Sample, atau Full, di mana Full kira-kira menggandakan biayanya). Biaya ditampilkan sebelum halaman dibuat.

Setiap halaman mengutip path:line, dan mengklik kutipan akan membuka baris itu di IDE. Sebulan kemudian, sebuah halaman di kolom ditandai karena "a file this page cites has changed since it was written", yang memberi tahu dia untuk membuat ulang halaman itu sebelum memercayainya. Untuk pertanyaan cepat sekali jalan, ia memakai chat di samping halaman, yang jawabannya juga mengutip path:line dari proyek itu, dan di situ ia juga bisa meminta halaman baru dengan bahasa biasa, misalnya "write a page about the retry policy". Halaman-halamannya sendiri berupa file markdown di dalam repository, jadi tim bisa me-review-nya di pull request yang sama dengan kodenya.

Titik serah terima antara Code, IDE, dan Wiki

Ketiga layar ini saling mengoper pekerjaan, juga ke bagian lain aplikasi. Kutipan di Wiki membuka IDE tepat di baris yang dikutip, dan IDE punya tombol Wiki for this folder untuk arah sebaliknya. Assistant di IDE dan chat di samping halaman Wiki dibangun di atas Maestro, asisten yang sama yang kamu pakai di bagian lain osFoundry, jadi bertanya di sana bekerja sama seperti di chat Maestro mana pun. Untuk mencari di codebase berdasarkan makna, bukan kata yang persis sama, Indexes membangun indeks pencarian lokal yang bisa dipakai Maestro. Dan ketika sebuah run di Code siap keluar dari laptopmu, Open PR membuka pull request untuk branch-nya.

Halaman produk menampilkan demo interaktif masing-masing: Code dan IDE.

Pertanyaan yang paling sering muncul duluan

Apakah saya perlu aplikasi desktop?
Ya. Code, IDE, dan Wiki bekerja dengan folder lokal, Git worktree, shell, dan language server, jadi semuanya berjalan di aplikasi desktop osFoundry.

Apakah agen bisa me-merge ke branch saya sendiri tanpa izin?
Tidak. Run bekerja di branch dan folder masing-masing. Branch kamu saat ini hanya berubah ketika kamu menekan merge, dan secara default hanya untuk branch yang test-nya lolos.

Apakah Wiki itu wiki tim seperti Notion?
Bukan. Wiki menulis dokumentasi dari repository kode, mengutip file dan baris, dan menandai halaman ketika kode itu berubah. Fungsinya untuk dokumentasi codebase, seperti gambaran umum arsitektur atau catatan onboarding.

Apa yang terjadi pada branch yang konflik?
Branch itu tetap di tempatnya. Kamu bisa me-merge branch yang bersih sekarang dan membiarkan agen mengulang yang konflik di atasnya, atau memilih hunk satu per satu dengan Combine into a branch.

Aplikasi desktopnya bisa diunduh gratis di osfoundry.io/id/download.

Apa yang dilakukan Maestro di osFoundry, chat AI yang menampilkan setiap langkahnya

tauchiii — Fri, 06 Nov 2026 16:01:46 +0000

Hari Kamis pukul 4:40, dan Priya baru saja meminta asisten AI menambahkan tombol "Hapus akun" di halaman pengaturan aplikasinya. Balasannya: "Selesai, 4 file diubah." Sebelum merilisnya, ia ingin tahu empat file yang mana, apa saja yang dibaca asisten itu sampai mengambil keputusan tersebut, dan apakah ia sempat menyentuh kode billing. Jendela chat biasa hanya memberinya paragraf terakhir.

Maestro dalam satu paragraf

Maestro adalah ruang kerja AI dengan tool lengkap di aplikasi desktop osFoundry. Kamu mengetik permintaan seperti di chat mana pun, tapi jawabannya datang bersama jejak kerjanya: setiap file yang didaftar, setiap pencarian yang dijalankan, setiap file yang dibaca atau diedit, dan setiap perintah terminal, masing-masing di barisnya sendiri dengan durasi yang bisa kamu buka. Maestro bisa bekerja di dalam folder di komputermu, mengusulkan perubahan alih-alih menulisnya diam-diam, dan berhenti untuk menunjukkan rencana sebelum menyentuh apa pun. Kamu bisa menemukannya di menu Maestro pada sidebar. Kalau kamu pernah memakai ChatGPT atau Claude di browser, bayangkan percakapan yang sama, ditambah log aktivitas agen dan beberapa rem di sampingnya.

Melihat-lihat layarnya

Tab permukaan di bagian atas. Maestro, Model chat, Multi chat, Research, Wiki, dan Code semuanya ada di satu layar ini. Maestro adalah tab dengan set tool lengkap.
Tab detail di atas percakapan: Chat, Sources, Files, Changelog, Tools, Pipeline, dan Logs. Semuanya adalah tampilan berbeda dari satu run yang sama. Sources menyimpan dasar jawaban, Changelog mendaftar file yang ditulis chat ini, dan Logs menampilkan langkah-langkahnya serta, di bagian Costs, biaya setiap permintaan.
Baris proses di transkrip. Di sini Maestro mendaftar src/ (38 file), menjalankan grep untuk deleteUser, menemukan 0 hasil, lalu membaca account.ts dan users.ts. Klik sebuah baris dan ia akan terbuka, menampilkan input dan output persis dari pemanggilan tool tersebut.
Strip kontrol di atas kotak pesan: sakelar sandbox, Plan OFF/ON, Tools, dan Goal. Di bawah kotak ada pemilih folder, project, repo, Router, dan model.
Panel pratinjau di sebelah kanan, tempat file, diff, atau halaman web terbuka di samping percakapan tanpa menggantikannya (Open File / App / Page, Browse Files, Browser).

Tiga cara orang memakainya

Developer solo yang ingin melihat rencana sebelum ada perubahan

Kasus Priya di awal tadi. Perubahannya menyentuh akun dan sesi, jadi ia lebih memilih membaca rencana daripada mereview diff yang tiba-tiba muncul.

Ia mengklik Plan di strip kontrol sampai tertulis Plan ON.
Ia mengetik "Add a Delete account button to settings" lalu mengirimnya.
Maestro membaca enam file dan tidak mengubah satu pun. Selama mode plan aktif, aplikasi desktop itu sendiri menolak tool apa pun yang akan menulis file atau menjalankan perintah, jadi "hanya baca" bukan sekadar permintaan sopan di dalam prompt.
Sebuah kartu Plan muncul dengan tanda "Awaiting approval", lengkap dengan tombol Approve dan Cancel.

Rencana dalam contoh ini menyebut empat file, menyatakan bahwa src/billing/ tidak disentuh karena Stripe menyimpan catatannya sendiri, dan diakhiri dengan "Nothing has been changed yet." Mode plan mati sendiri begitu rencananya tiba. Priya mengklik Approve, dan baru saat itulah Maestro mengedit keempat file dan menjalankan test (npm test -- account, 3 passed), semuanya terlihat sebagai baris EDIT dan TERMINAL. Kalau ia tidak suka rencananya, Cancel akan membiarkan folder persis seperti semula.

Hasil akhirnya: perubahan yang sudah ia setujui sejak awal, dan transkrip yang menunjukkan di mana agen mencari dan apa yang ia jalankan.

Anggota tim baru yang sedang mengenali codebase

Dan baru bergabung dengan tim hari Senin. Ia perlu tahu di mana logika penguncian login berada, tapi di kode tidak ada yang menyebutnya "lockout", jadi pencarian teks tidak menemukan apa-apa.

Di Indexes, ia menambahkan folder project sekali saja supaya bisa dicari berdasarkan makna.
Di chat Maestro pada folder itu, ia bertanya di mana aplikasi mengunci pengguna setelah login gagal.
Ia memperhatikan baris prosesnya: pencarian folder yang mengembalikan 2 hasil, lalu READ pada throttle.ts.

Jawabannya menunjuk ke src/auth/throttle.ts (baris 1–46) dan src/routes/session.ts (baris 22–61), dan menjelaskan bahwa kodenya tidak pernah menyebut "lock out": setelah lima kali percobaan gagal, kode itu memasang jeda 15 menit ke depan dan mengembalikan 429 sebelum mengecek password. Karena jawabannya menyertakan path file dan barisnya menunjukkan apa yang dibaca, Dan bisa membuka baris yang sama di panel pratinjau dan memeriksa klaim itu sendiri, bukan sekadar percaya pada ringkasan. Di kasus ini tidak ada yang ditulis ke disk, jadi ia bisa membiarkan Approval Mode pada pengaturan default.

Hasil akhirnya: dua file yang penting, alasan pencarian kata kunci tidak menemukannya, dan chat yang bisa ia buka lagi dari daftar chat.

Marketer yang mengedit copy di repo milik tim lain

Sammy menulis copy untuk halaman peluncuran, tapi halamannya berupa file React di repo engineering. Ia ingin teks barunya sesuai panduan gaya bahasa di docs/, dan tidak mau ada yang di-commit sebelum ia melihatnya.

Ia membuka menu Approval Mode di composer dan memilih Permission & Approve, yang meminta izin sebelum pemanggilan tool. Pilihan lainnya adalah Auto Accept (default, tool langsung berjalan), Plan First (buat rencana sebelum eksekusi), dan Bypass (tanpa persetujuan sama sekali, termasuk untuk push dan submit form).
Ia menyalakan sandbox, sehingga penulisan file disiapkan di sebuah branch, bukan langsung masuk ke folder kerja.
Ia meminta Maestro membuat draf halaman peluncuran yang konsisten dengan docs. Maestro membaca docs/tone.md, mencari di source, lalu mengusulkan perubahan pada src/Launch.tsx.
Diff-nya terbuka di panel pratinjau. Ia menerimanya, lalu memakai Export to branch supaya engineer bisa mereviewnya seperti perubahan lain.

Hasil akhirnya: copy yang mengutip panduan gaya bahasa yang diikutinya (tab Sources menyimpannya), diff yang sudah direview, dan sebuah branch, bukan kejutan di main.

Posisi Maestro dibanding Model chat, Chat, dan Multi chat

Maestro berbagi layar dengan saudara-saudaranya yang lebih sederhana, dan memilih yang tepat menghemat waktu dan biaya.

Model chat adalah tab di layar yang sama yang mengirim setiap giliran ke satu model pilihanmu. Ini percakapan hanya-baca: tanpa folder, tanpa tool yang bertindak, tanpa persetujuan. Cocok untuk pertanyaan cepat.
Chat punya tempat sendiri di sidebar. Ia juga menjawab dengan satu model yang kamu pilih untuk seluruh percakapan, tapi tetap punya kemampuan atas file, jadi ia bisa mengusulkan perubahan yang kamu terima (Accept) atau tolak (Reject), tercatat di Changelog. Pakai ini kalau kamu ingin model tertentu yang mengerjakan, tanpa router yang memilihkan.
Multi chat mengajukan pertanyaan yang sama ke beberapa model sekaligus. Di Compare kamu membaca jawabannya berdampingan; di Council para model menjawab, saling menilai jawaban satu sama lain secara buta, lalu satu model menulis sintesis.

Dari Maestro, pekerjaan sering berlanjut ke bagian lain aplikasi. Research mengubah pertanyaan menjadi laporan bersumber, Code menjalankan coding agent di branch-nya sendiri, Indexes membuat folder bisa dicari berdasarkan makna (seperti di kasus Dan), dan Version → Merge Station adalah tempat perubahan dari sandbox di-merge. Kalau satu giliran berjalan salah, mengetik /rewind di chat akan memulihkan file yang diubah oleh giliran itu. Untuk penjelasan lebih dalam, halaman orkestrasi Maestro membahas tab-tab detail, dan halaman mode plan menjelaskan alur persetujuannya.

Pertanyaan yang biasanya muncul pertama kali

Apakah mode plan cuma instruksi di dalam prompt?
Bukan. Selama Plan dalam posisi ON, setiap tool yang tidak ada di daftar hanya-baca akan ditolak saat aplikasi menjalankannya, jadi agen bisa membaca, mencari, dan browsing, tapi tidak bisa mengedit atau menjalankan perintah sampai kamu menyetujui rencananya.

Apa bedanya sakelar Plan dengan Plan First di Approval Mode?
Plan adalah sakelar sekali pakai untuk permintaan berikutnya: selidiki, sajikan rencana, tunggu. Approval Mode adalah aturan tetap chat untuk pemanggilan tool, dari Auto Accept sampai Bypass. Plan First adalah salah satu dari empat pengaturannya.

Baris prosesnya banyak sekali. Bisa disembunyikan?
Bisa. Pengaturan Process Detail beralih antara Full dan Compact. Pengaturan ini hanya mengubah cara langkah-langkah ditampilkan, bukan cara giliran dijalankan.

Model apa yang dipakai Maestro?
Secara default Router memilih model di setiap giliran, dan baris proses menunjukkan model mana yang berjalan. Kamu bisa mengganti mode model (cloud, lokal, atau self-hosted) dari composer, atau memakai Chat kalau ingin satu model tetap untuk seluruh percakapan.

Aplikasi desktopnya bisa diunduh di osfoundry.io/id/download.

Apa itu osFoundry dan bagaimana ruang kerja AI desktop ini dibagi?

tauchiii — Fri, 06 Nov 2026 14:38:04 +0000

Senin pukul 9:40, ada empat tab browser yang terbuka: satu chatbot untuk bertanya, satu lagi karena kamu tidak sepenuhnya percaya yang pertama, satu editor dengan coding agent, dan satu aplikasi catatan berisi riset minggu lalu. Masing-masing tahu sebagian pekerjaanmu, tapi tidak ada yang tahu sisanya. Belum sampai jam makan siang, kamu sudah menyalin paragraf konteks yang sama ke tiga jendela berbeda.

Satu aplikasi, bukan lima tab

osFoundry adalah ruang kerja AI untuk desktop: satu aplikasi tempat kamu mengobrol dengan model AI, menyerahkan pekerjaan ke agent dan tim agent, menyimpan catatan dan pengetahuan yang bisa dicari, menjalankan model terbuka di komputer sendiri, dan membuat aplikasi kecil untuk dipakai tim. Modelnya bisa berasal dari tiga tempat: mesinmu sendiri, penyedia cloud lewat API key milikmu, atau GPU cloud sewaan. Aplikasinya dibagi menjadi beberapa kategori, dan setiap kategori berisi beberapa layar. Chat adalah tempat kamu berbicara dengan model (Maestro, Multi chat, Branchspace, dan lainnya). Workstation adalah tempat agent mengerjakan tugas yang lebih panjang (Code, Agent, Agent team, Loop, Terminal). Knowledge menyimpan tulisanmu dan apa yang diingat AI. Local Model dipakai untuk mencari, memasang, dan menguji model terbuka. Custom App untuk tool internal, dan Discover untuk riset web dan berita. Kalau kamu pernah memakai VS Code, perbandingan paling dekat adalah editor dengan activity bar yang setiap ikonnya membuka tool berbeda, bedanya di sini tool-tool itu adalah permukaan AI yang berbagi proyek, memori, dan model yang sama.

Seperti apa layar yang umum

Kebanyakan orang mulai dari kategori Chat, jadi ini tempat yang pas untuk memahami cara layar osFoundry disusun. Ini adalah Multi chat dalam mode Council, dengan data contoh: tiga model diberi pertanyaan yang sama, lalu saling menilai jawaban satu sama lain.

Deretan tab di atas (Maestro, Model chat, Multi chat, Research, Wiki, Code) berpindah di antara permukaan area Chat: agent Maestro lengkap, chat tanya-jawab sederhana dengan sumber yang dikutip, beberapa model sekaligus, riset mendalam, dokumentasi kode, dan coding agent.
Saklar Compare / Council menentukan cara model bekerja sama. Compare menampilkan jawaban berdampingan supaya kamu yang menilai. Council membuat mereka menjawab secara terpisah, saling memberi peringkat tanpa tahu siapa penulisnya, lalu menulis sintesis.
Setiap kolom adalah satu model dengan label penyedia: di sini Anthropic, Ollama (berjalan lokal), dan OpenAI. Kamu bisa mencampur model cloud dan lokal di layar yang sama.
Panel kanan menampilkan tahap-tahap proses (Answers, Ranking, Synthesis) dan tabel Peer review, jadi kamu bisa melihat siapa memberi skor apa, bukan hanya membaca jawaban akhirnya.
Tombol Run memberi tahu berapa panggilan model yang akan dilakukan sebelum kamu menekannya (di sini "Run · 7 calls"). Mematikan peer ranking akan menurunkan angka itu.

Banyak layar osFoundry mengikuti pola ini: daftar di kiri, pekerjaan di tengah, dan inspector di kanan yang menunjukkan bagaimana sebuah hasil didapat.

Minggu pertama seorang developer solo

Ken mengurus sebuah toko online kecil sendirian. Dia ingin AI yang paham codebase-nya, dan sebagian pekerjaan ingin dia simpan di laptopnya sendiri.

Hari Senin dia membuka Local Model, lalu Explore. Layar ini membaca spesifikasi mesinnya dulu (16 GB memori dalam contoh ini) lalu memberi badge pada setiap model terbuka: Fits, Tight, atau Too big. Dia memasang model dengan badge hijau dan mengajukan beberapa pertanyaan di Playground, yang menjalankan prompt yang sama di dua model berdampingan dan menunjukkan seberapa cepat masing-masing mulai menjawab.

Hari Selasa dia harus mengubah fungsi pemformat harga dan tidak yakin bagian mana saja yang bergantung padanya. Dia membuka proyek di IDE, klik kanan pada fungsi itu, dan memilih Show Code Graph.

Panel ini menampilkan semua pemanggil, menandai relasi mana yang dibaca langsung dari kode dan mana yang hanya disimpulkan, lalu merangkum Impact of change: berapa simbol, file, dan test yang bisa terdampak. Dia mengklik salah satu pemanggil untuk melompat ke baris itu, dan memakai Send to chat untuk membawa grafnya ke percakapan dengan Maestro.

Hari Kamis dia mulai menyerahkan tugas-tugas kecil ke coding agent. Di layar ADE, setiap tugas punya worktree sendiri, dan tab Changes menampilkan diff-nya. Dia mengklik gutter di samping baris yang tidak dia setujui, mengetik catatan, lalu mengirim semua catatan yang belum terkirim ke agent sekaligus. Dia menutup minggu itu dengan model lokal yang dia percaya untuk pertanyaan cepat dan kebiasaan mengecek dampak sebelum refactoring.

Minggu pertama seorang pemimpin tim kecil

Aiko memimpin empat orang dan merilis versi baru setiap dua minggu. Masalahnya bukan menulis kode, tapi tahu apa yang sedang dikerjakan semua orang, entah manusia atau agent.

Dia mulai dari Message, chat tim. Channel dan DM bekerja seperti di Slack, dengan satu perbedaan: agent AI adalah anggota channel. Seseorang me-mention agent dengan @ di #release, dan balasan serta run-nya muncul kembali di channel itu, tempat semua orang bisa melihatnya.

Berikutnya dia menyiapkan Agent team di Workstation. Agent pemimpin mengoordinasikan anggota spesialis, dan layarnya memisahkan Team mail, Handoffs, Sub-agents, dan Proposals ke tab masing-masing, jadi dia bisa mengaudit siapa menyerahkan apa ke siapa. Untuk pengecekan yang terjadi di setiap rilis, dia mengubah tim itu menjadi Loop: sebuah trigger (misalnya setiap pagi hari kerja), batas jumlah putaran dan percobaan ulang, serta kriteria keberhasilan. Loop berjalan per putaran sampai kriterianya terpenuhi dan mencatat kriteria mana yang lolos di setiap putaran.

Saat beberapa agent mengerjakan repository yang sama, dia memakai Code. Setiap agent punya branch dan worktree sendiri, dan tidak ada yang di-merge dengan sendirinya. Dia memilih dua run yang sudah selesai, menekan Preview combined merge, dan melihat file mana yang bentrok sebelum ada apa pun yang menyentuh branch utama.

Untuk review per baris, dia memakai catatan yang sama seperti Ken: catatan yang disematkan ke kode, dikirim ke agent lengkap dengan file, baris, dan kodenya. Di akhir minggu dia punya satu channel tempat pekerjaan agent muncul, pengecekan rilis yang berjalan sendiri, dan tahap review yang terjadi sebelum merge, bukan sesudahnya.

Minggu pertama seorang peneliti dan penulis

Lena menulis laporan panjang tentang kebijakan tempat kerja. Dia butuh sumber yang bisa dicek, dan dia sudah pernah kena batunya gara-gara jawaban AI yang terdengar sangat yakin.

Untuk pertanyaan yang tidak cukup dijawab oleh satu model, dia memakai Multi chat dalam mode Council, layar yang dibahas di atas. Kalau dua reviewer memberi skor rendah pada sebuah jawaban, dia tahu harus menggali lebih dalam.

Untuk pertanyaan yang lebih besar, dia membuka Agents, menekan New session, dan memilih Deep Research Team yang sudah siap pakai. Pemimpinnya memecah pertanyaan menjadi beberapa bagian dan memberikan masing-masing ke satu anggota, seperti Data Researcher dan Search Specialist.

Reviewer terpisah mengecek setiap langkah sebelum sampai ke dia, dan langkah tanpa sumber dikembalikan lalu dijalankan ulang. Jawaban akhirnya berupa tabel dengan sumber di setiap baris, ditambah catatan singkat tentang di mana sumber-sumbernya berbeda pendapat dan apa yang belum tercakup (data contoh di screenshot).

Proses menulisnya sendiri terjadi di Knowledge. Di Paper, dia menyorot satu kalimat di drafnya dan menempelkan ruang berpikir ke kalimat itu, dengan tab seperti Academic search, Browser, atau sesi Maestro yang hanya membahas bagian tersebut. File pendukung dan komentar disimpan di sebuah Note. Di Discover dia menyimpan pencarian di Browser dan mengikuti channel kata kunci di News, jadi bahan bacaan untuk satu laporan masih ada untuk laporan berikutnya.

Bagaimana area-area ini saling mengoper pekerjaan

Kategori-kategori ini bukan produk terpisah; mereka saling mengoper pekerjaan. Local Model adalah lapisan di bawahnya: model yang kamu pasang dari Explore akan muncul di pemilih model Maestro, Multi chat, dan sesi agent.

Knowledge memberi masukan ke Chat: Memory menunjukkan apa yang Maestro ketahui tentang pekerjaanmu, dan Indexed Folders memungkinkan kamu memilih folder mana yang boleh dicari agent. Sesi agent, run Agent team, dan Loop melapor ke channel di Message. Workstation (layar dengan nama itu) memungkinkan kamu membuka channel, catatan, file, dan sesi agent berdampingan dalam satu tata letak. Kalau sesuatu yang kamu bangun dengan agent perlu menjadi tool untuk tim, ia pindah ke Custom App, tempat sebuah Room menampung aplikasi milik tim di samping chat Maestro tim itu sendiri. Key dan penyedia untuk semua ini ada di Configuration. Ikhtisar platform mencantumkan setiap layar kalau kamu ingin peta lengkapnya.

Pertanyaan yang sering muncul di minggu pertama

Apakah saya harus memakai semuanya?
Tidak. Kebanyakan orang mulai dari satu area, biasanya Maestro di Chat atau Explore di Local Model, lalu menambah area lain saat ada tugas yang membutuhkannya. Kategori-kategori ini berbagi proyek dan memori, jadi apa pun yang kamu kerjakan di awal tidak perlu diulang nanti.

Apakah data saya keluar dari komputer?
Tidak, kalau kamu memakai model lokal; model itu berjalan di perangkatmu. Model cloud yang kamu hubungkan lewat API key milikmu bisa melihat apa yang kamu kirim, dan pemakaian itu ditagih oleh penyedianya. Halaman local-first menjelaskan bagaimana keduanya dipisahkan.

Apakah ini hanya untuk developer?
Tidak. Code, IDE, dan Terminal memang tool untuk developer, tapi Message, Paper, Note, Research, Multi chat, dan Discover juga dibuat untuk penulis, analis, dan pemimpin tim.

Berapa biayanya?
Aplikasi desktopnya gratis diunduh, dan menjalankan model lokal tidak dikenai biaya pemakaian dari osFoundry. Kamu bisa mendapatkannya di halaman unduhan.

Cara kerja Local Model di osFoundry, dari memilih model open sampai melatihnya di komputer sendiri

tauchiii — Fri, 06 Nov 2026 14:15:45 +0000

Kamis pukul 16.40, draf kontrak terbuka di satu jendela. Kamu ingin AI merapikan kalimatnya, tapi dokumen itu tidak boleh keluar dari laptop, dan kamu tidak yakin model open mana dari ratusan model di Hugging Face yang bahkan bisa jalan dengan memori 16 GB. Menghabiskan malam di terminal untuk mencari tahu juga bukan pilihan yang menarik.

Satu grup di sidebar untuk semua urusan model open

Local Model adalah bagian dari osFoundry yang mengurus model open-weight yang berjalan di hardware milikmu sendiri. Di sidebar aplikasi desktop, ia punya kategori sendiri yang dibagi menjadi tiga subjudul: Run (Explore, Providers, Servers, Playground, Deployments, Cloud GPU, GPU Endpoints), Build (My Models, Datasets, Training, Quantize, Notebooks), dan Measure (Eval, Benchmarks, Safety). Kalau pernah pakai Ollama atau LM Studio, bagian Run pasti terasa familier: cari model, unduh, lalu ajak ngobrol. Bedanya, grup yang sama juga bisa dipakai untuk mengecilkan model, melakukan fine-tuning dengan contohmu sendiri, dan mengujinya dengan pertanyaanmu sendiri, jadi seluruh siklus hidup model tetap ada di satu aplikasi. Inferensi di perangkat memakai server llama.cpp bawaan, jadi tidak perlu instalasi terpisah. Panduan ini membahas sembilan layar yang paling sering dipakai: Explore, Servers, Playground, My Models, Datasets, Training, Quantize, Eval, dan Benchmarks.

Sekilas tentang Explore

Kebanyakan orang mulai dari Explore, dan tata letaknya menunjukkan cara berpikir seluruh kategori ini: mesinmu dulu, baru modelnya.

Panel Filters di kiri mengelompokkan tugas Hugging Face (Text Generation, Summarization, Translation, Embeddings, plus grup Multimodal, Vision, dan Audio) dan punya kotak pencarian.
Banner di atas membaca mesinmu sebelum menampilkan apa pun. Pada contoh di atas tertulis 16 GB unified memory, sekitar 12 GB bisa dipakai untuk model, sekitar 9 GB sedang kosong, dan perkiraannya mengasumsikan Q4_K_M dengan konteks 4K.
Setiap kartu model punya label kecocokan: hijau Fits, kuning Tight, merah Too big, masing-masing dengan perkiraan kebutuhan memori. Tidak ada yang disembunyikan; model yang muat hanya ditampilkan lebih dulu.
Tombol Providers dan My Registry di kanan atas mengarah ke penyedia API cloud dan ke model yang sudah kamu punya.
Klik sebuah kartu untuk membuka detailnya. Di sana, Install Locally mengunduh satu versi model, biasanya GGUF terkuantisasi yang sesuai dengan labelnya.

Tiga orang, tiga cara memakainya

Developer solo dengan satu laptop

Maya mengerjakan proyek sampingan di MacBook 16 GB. Ia ingin model lokal untuk menulis pesan commit dan catatan singkat, terutama supaya bisa bekerja offline di kereta.

Ia membuka Explore, memfilter Text Generation, dan melewati semua yang berlabel merah. Dua kandidat berlabel hijau, jadi ia memasang keduanya dengan Install Locally. Lalu ia membuka Playground, mengetik satu prompt, dan menambahkan kedua model sebagai panel. Playground mengirim prompt yang sama ke dua sampai empat model sekaligus dan menampilkan jawabannya berdampingan, dengan waktu ke token pertama dan jumlah kata di bawah tiap panel.

Belakangan ia menemukan model yang ia suka, tapi hanya tersedia sebagai file F16 presisi penuh. Ukurannya sekitar 15 GB, terlalu besar untuk laptopnya. Di Quantize ia memilihnya di "The model to shrink", memilih Q4_K_M, level yang direkomendasikan aplikasi untuk kebanyakan orang, lalu menjalankannya. llama-quantize bawaan menulis ulang file itu di mesinnya; tidak ada yang diunggah.

Pada contoh di atas hasilnya 4.58 GiB, 3.3 kali lebih kecil dari aslinya. Sebelum memercayainya, ia mengeklik Measure quality, yang membandingkan file baru dengan file asli dan mengisi kolom "same top token" dan rata-rata KLD di tabel Compare, lalu Measure speed untuk melihat token per detik. Satu klik Try it in Playground menaruhnya lagi di samping dua model lainnya. Malam itu ia selesai dengan model yang muat, angka yang menunjukkan berapa harga dari pengecilan itu, dan tanpa riwayat terminal sama sekali.

Tim kecil dengan satu desktop kuat

Sebuah agensi berisi empat orang punya satu desktop bermemori besar di kantor dan beberapa laptop tipis. Model besar hanya muat di desktop, tapi semua orang ingin memakainya.

Di desktop, seseorang membuka Servers, memilih This Mac, lalu masuk ke tab Access. Ia mencentang "Allow access from other devices on the local network (LAN)" dan mengaktifkan Remote Access. Panel itu kemudian menampilkan semua model lokal yang akan dilayani mesin tersebut. Di bawah Device keys ia mengeklik New key, menamainya sesuai laptop seorang rekan, lalu Create key. Setiap key bisa dicabut sendiri-sendiri, dan key khusus inferensi bisa menjalankan model tapi tidak bisa mengakses sesi agen.

Di tiap laptop, rekannya membuka Servers, mengeklik Add Server, memasukkan alamat desktop, menempelkan key, lalu memakai Test Connection. Begitu tersambung, model-model di desktop muncul di pemilih model laptop seperti model lainnya. Aplikasinya sendiri mencatat bahwa lalu lintas ini memakai HTTP biasa, jadi memang ditujukan untuk jaringan tepercaya seperti LAN kantor.

Lalu seseorang membuka Benchmarks, mengeklik New Benchmark, memilih model, dan membiarkan suite Quick. Hasilnya mencatat token per detik, waktu ke token pertama, dan latensi, jadi tim bisa tahu apakah model bersama itu cukup cepat dipakai saat meeting atau hanya cocok untuk batch semalam. Kalau terasa lambat, Servers juga punya tab Config tempat model draf kecil bisa dipasang di Speculative Decoding, lalu Restart now, dan benchmark bisa dijalankan lagi untuk membandingkan.

Hasilnya, tim punya satu mesin yang mengerjakan tugas berat, satu key per laptop yang bisa dicabut tanpa mengganggu yang lain, dan jawaban terukur untuk pertanyaan "cukup cepat atau belum?".

Kepala operasional yang tidak menulis kode

Ken menangani layanan pelanggan sebuah toko online kecil. Ia punya dua pertanyaan: model mana yang membaca total invoice dengan benar, dan bisakah model belajar membalas dengan gaya bahasa toko?

Untuk yang pertama, ia membuka Eval dan mengeklik Custom Benchmark. Ia memberinya nama, menempelkan sepuluh invoice beserta total yang ia harapkan untuk masing-masing, membiarkan Exact Match, lalu mengeklik Create Benchmark. Berikutnya New Eval Run: ia mencentang dua model di komputernya, mencentang benchmark-nya, lalu mengeklik Start Evaluation. Pertanyaan dikirim ke tiap model di mesinnya sendiri.

Pada contoh ini satu model mendapat 90 dan yang lain 70, dan kolom Diff menunjukkan selisih 20 poin. Itu hasil dari dokumennya sendiri, bukan leaderboard milik orang lain.

Untuk soal gaya bahasa, ia mengumpulkan beberapa ratus pesan pelanggan lama beserta balasan yang benar-benar dikirim tim, satu pasang per baris. Di Datasets ia bisa memasukkan file itu, atau mencari data publik lewat tab Hub, lalu memakai "Use for Training" untuk meneruskannya. Di Training ia mengeklik New Job dan mengikuti empat langkah: Base Model, Dataset, Config, dan Review. Di Training Target ia memilih Local (This Device), yang menurut layar berjalan di GPU perangkat dan gratis, dengan LoRA sebagai metodenya.

Setelah Start Training, job menampilkan nilai loss selama berjalan. Begitu selesai, adapter hasil training muncul di My Models di samping model dasar asalnya, dan "Chat with your model" pada run yang selesai menyiapkannya untuk runtime di perangkat sehingga ia bisa bertanya sesuatu di Playground. Akhirnya ia punya model kecil yang privat dan benchmark yang bisa dijalankan ulang setiap kali mempertimbangkan model baru.

Di mana Local Model menyerahkan tongkat estafet

Kategori ini tidak berdiri sendiri. Model yang kamu pasang atau hubungkan muncul di daftar model yang sama dengan yang dipakai chat, jadi model lokal bisa menjawab percakapan biasa atau dibandingkan di Playground dengan model cloud yang kamu tambahkan di Providers. Dari Explore, "Use in Notebook" membuka notebook JupyterLab yang sudah disiapkan untuk model itu, baik secara lokal maupun di instance hosting. Saat model butuh GPU sungguhan alih-alih laptopmu, Deployments dan Cloud GPU mengambil alih dan menaruhnya di endpoint terkelola. Sebelum model dipakai pelanggan, Safety menjalankan rangkaian uji red team terhadap model yang sudah di-deploy. Halaman inferensi lokal membahas mesin di perangkat lebih dalam, dan halaman fine-tuning LoRA membahas sisi training-nya.

Pertanyaan yang paling sering muncul

Apakah saya butuh GPU atau PC gaming?
Tidak. Laptop yang cukup baru sudah bisa untuk model kecil dan menengah; label kecocokan di Explore memberi tahu apa yang muat di mesinmu sebelum mengunduh. Desktop yang lebih kuat atau server remote hanya memperpanjang daftarnya.

Apakah ada yang dikirim ke cloud?
Inferensi lokal, Quantize, dan training lokal berjalan di mesinmu. Training dengan Cloud GPU, endpoint Cloud GPU, dan Providers adalah bagian yang memakai layanan luar, dan layarnya diberi keterangan, misalnya "Managed cloud GPU · needs credits" di dialog training.

Apa bedanya Eval dan Benchmarks?
Eval menilai kualitas jawaban berdasarkan pertanyaan yang kamu tentukan. Benchmarks mengukur kecepatan dan memori: token per detik, waktu ke token pertama, dan latensi.

Di mana saya bisa mendapatkan aplikasinya?
Local Model berjalan di aplikasi desktop, yang bisa kamu unduh di osfoundry.io/id/download.

Apa yang dilakukan Agent team di osFoundry, dan kapan satu agen sudah cukup

tauchiii — Fri, 06 Nov 2026 12:57:00 +0000

Selasa pagi pukul 7:40, Priya punya pertanyaan yang harus dijawab sebelum makan siang karena direkturnya menunggu: apakah empat hari kerja seminggu benar-benar menjaga produktivitas? Dia bisa saja menempelkannya ke chatbot dan mendapat satu paragraf yang terdengar yakin. Tapi model yang mencari angkanya juga akan jadi model yang menilai apakah angka itu bisa dipercaya, dan model jarang membantah dirinya sendiri. Yang dia mau adalah satu orang mencari uji cobanya, orang lain menarik angkanya, dan orang ketiga mengembalikan apa pun yang tidak punya sumber.

Dua pintu masuk ke layar yang sama

osFoundry adalah aplikasi desktop untuk menjalankan pekerjaan AI di komputer kamu sendiri, dan ada dua cara yang mirip untuk menyerahkan pekerjaan ke agen. Agent (di sidebar tampil sebagai Single agent) adalah satu agen bernama dengan satu tujuan: kamu memberinya instruksi, ia mendapat ID sendiri seperti AG-0001L, dan setiap run yang dilakukannya tercatat sehingga bisa kamu telusuri nanti. Agent team menempatkan seorang leader di depan sekumpulan anggota spesialis. Leader merencanakan pekerjaan, memberikan tiap langkah ke satu anggota, lalu seorang reviewer memeriksa tiap langkah sebelum sampai ke kamu. Keduanya ada di sidebar di bawah Agents, bersebelahan, dan membuka layar yang sama. Bedanya hanya di jumlah anggota. Kalau kamu pernah ada di grup chat yang punya project manager, Agent team akan terasa familier. Bedanya, setiap pesan, serah terima, dan keputusan disimpan, dan kamu bisa scroll balik untuk melihatnya.

Melihat-lihat layar tim

Ini adalah sesi tim yang sudah selesai. Pertanyaan dan jawabannya adalah data contoh dari run demo.

Percakapan dengan leader (tengah). Header-nya bertuliskan "Leader · Orchestrate your team". Di sini kamu mengajukan pertanyaan sekali saja, dan di sini juga jawaban gabungannya muncul, dalam contoh ini berupa tabel dengan sumber di setiap baris, satu baris "Where sources disagree", dan satu baris "Not covered".
Tab sesi (bagian atas tengah). Chat, Team mail, Email, Handoffs, Sub-agents, Proposals, dan Files. Handoffs menunjukkan siapa menyerahkan pekerjaan ke siapa. Proposals berisi perubahan pada file atau pengaturan yang disarankan agen. Saran tidak diterapkan sampai disetujui.
Panel Agent session (kanan). Ada satu kartu per anggota, berisi apa yang diminta leader, tool yang dipanggil (web_fetch, web_search), dan hasilnya. Di bawah tiap hasil ada keputusan reviewer, misalnya "Approved". Di bagian atas ada pemilih run ("Run 1 · 07:40 AM") dan tombol Cards / Graph.
Tab Team roster. Ini daftar siapa saja yang boleh bertindak di sesi ini. Tim adalah daftar anggota, bukan workflow. Urutan kerjanya berasal dari rencana leader.
Rail sesi (kiri, disembunyikan di sini) dan inspector. Rail menampilkan semua sesi beserta ID-nya. Inspector punya tab Goal, Trigger, dan Hooks: untuk target akhir, apa yang memicu run, dan pengecekan di sekitar pekerjaan.

Tiga cara orang memakainya

Peneliti yang ingin setiap angka punya sumber

Priya membuka Agent team dan menekan New session. Di dialog New team session, dia membiarkan "Start from a team" terpilih dan memilih Deep Research Team dari daftar Team. Dialog memuat lima anggotanya (deep-research-agent, research-analyst, data-researcher, search-specialist, academic-researcher). Di bawah "Who leads" tampil Orchestrator, yang "plans the work up front, then delegates the steps to the agents below". Dia bisa menekan "make leader" di anggota mana pun untuk menjadikannya pemimpin.

Dia menekan Create, mengetik pertanyaannya di chat leader, lalu mengirimnya. Leader memecahnya jadi lima bagian: cari uji cobanya, studinya, angkanya, bukti yang berlawanan, lalu satu jawaban. Tiga anggota mulai bersamaan. Data Researcher menunggu daftar dari Search Specialist sebelum menarik angka. Saat Data Researcher melaporkan angka 40%, reviewer menandainya "Sent back" dengan alasan tidak ada sumber, tanggal, maupun ukurannya. Langkah itu dijalankan lagi, menemukan sumbernya, lalu disetujui.

Hasil akhirnya adalah satu jawaban di panel tengah, dan setiap angka di dalamnya sudah diperiksa oleh pihak lain selain agen yang menemukannya. Dia juga mendapat baris "Not covered" yang jujur, yang bisa langsung dia tempel ke catatan untuk direkturnya.

Developer solo yang terus menempelkan instruksi yang sama

Tom mengubah catatan rapat jadi daftar tugas beberapa kali seminggu, dan setiap kali dia harus menempelkan paragraf aturan yang sama ke chat lebih dulu. Pekerjaan ini tidak butuh tim. Yang dibutuhkan adalah satu agen yang ingat aturannya.

Dia membuka Single agent, menekan New session, dan tetap di tab Create in chat. Di kotak "New agent" dia menulis satu baris tentang apa yang dia butuhkan, lalu menekan Start. Chat yang terbuka adalah agen setup. Agen itu mengajukan beberapa pertanyaan, lalu mengusulkan nama, @handle, dan instruksi lengkap. Sebuah kartu muncul di atas kolom input berisi nama, handle, link Show instructions, dan tombol Create agent.

Dia membuka instruksinya dan memastikan aturan yang paling penting baginya ada di sana: jangan pernah menebak penanggung jawab atau tenggat. Lalu dia menekan Create agent. Chat yang sama sekarang menjadi agen itu. Saat dia menempelkan catatannya, penanggung jawab dan tanggal yang tidak ada ditandai sebagai kosong, tidak pernah ditebak. Sesi itu menyimpan Agent ID-nya di rail, dan lain kali dia cukup memilih agennya.

Release lead yang ingin tahu siapa mengerjakan apa

Dari mengurus rilis untuk tim produk kecil. Sesi timnya punya satu leader dan anggota bernama Release Drafter, Change Auditor, Docs Reviewer, QA Summarizer, dan Approval Prep. Masing-masing memegang satu bagian dari paket rilis.

Sebelum run, dia membuka tab Goal dan menekan Set a goal. Panel menjelaskan bahwa goal dipecah menjadi kriteria sukses yang awalnya gagal lalu berubah hijau saat agen memenuhinya. Sesi terus berjalan sampai semuanya lolos atau mencapai batas ronde. Dia menulis tiga kriteria, yang terakhir adalah paket persetujuan sudah lengkap. Selama anggota bekerja, dia mengecek Handoffs untuk mengikuti rantai dari leader ke tiap anggota dan kembali. Dia juga mengecek Proposals untuk perubahan konfigurasi yang disarankan anggota, dan tidak ada yang diterapkan tanpa dia. Dia bisa mengarahkan leader kapan saja dengan membalas di chat-nya, dan Pause di header panel menahan run selama dia meninjau.

Di akhir, dia punya paket rilis plus catatan siapa yang menyusun, mengaudit, dan menyetujui tiap bagian. Catatan itu bisa dia tunjukkan ke siapa pun yang bertanya bagaimana satu baris bisa masuk ke release notes.

Ke mana arahnya di bagian lain aplikasi

Agent dan Agent team adalah tempat pekerjaan dimulai. Sessions adalah tempat kamu memantaunya. Board itu menampilkan setiap sesi chat, agen, tim, dan terminal sebagai satu kartu, dikelompokkan ke Running, Needs you, Paused, Idle, Done, dan Failed sesuai apa yang benar-benar sedang dilakukan sesi itu.

Kalau pekerjaan tim yang sama harus dijalankan berulang kali, Loop membungkus sebuah tim dengan trigger, batasan, dan catatan per ronde tentang kriteria mana yang lolos. Graphs dipakai untuk pekerjaan yang jalurnya bergantung pada apa yang terjadi di tengah jalan. Percakapan dengan leader adalah chat Maestro, jadi jawaban tim bisa berlanjut ke pekerjaan Maestro kamu yang lain. Link Enable sync di sesi menghubungkannya ke channel pesan proyek, tempat orang dan agen bisa berbicara di satu tempat. Baca lebih lanjut di halaman fitur Agents dan ringkasan sesi agen.

Pertanyaan yang sering diajukan pengguna baru

Kapan sebaiknya pakai satu agen daripada tim?
Pakai satu agen kalau pekerjaannya satu tugas jelas dengan aturan tetap, seperti merapikan format catatan atau menulis balasan dengan satu gaya. Pakai tim kalau pekerjaannya punya bagian-bagian yang butuh tool berbeda, atau kalau kamu ingin ada reviewer terpisah yang memeriksa hasilnya sebelum kamu melihatnya.

Bisakah saya mengubah tim setelah sesi dimulai?
Tidak. Dialog New team session menyebutkan bahwa tim "is fixed for this session's life". Di dalam dialog kamu masih bisa menambah atau menghapus agen dan memilih siapa yang memimpin sebelum menekan Create. Untuk memakai susunan anggota lain, mulai sesi baru.

Apakah ada yang berjalan di cloud?
Form New session menawarkan run Local dan Isolated. Di sana disebutkan bahwa keduanya berjalan di komputer kamu dengan key milik kamu sendiri dan tidak ada yang dikirim ke cloud. Riwayat chat bersifat lokal secara default.

Bisakah agen menulis ulang instruksinya sendiri?
Mereka bisa menyarankan perubahan, yang muncul di Proposals. Proposal bukan konfigurasi yang sudah diterima. Apakah agen boleh mengubah prompt-nya sendiri adalah pengaturan terpisah.

Aplikasi desktopnya bisa kamu unduh di osfoundry.io/id/download.