Company Detector Bot - AI Company Detection Agent

Overview

Company Detector Bot adalah sistem investigasi otomatis untuk membantu tim Komerce membedakan user personal, pemilik bisnis, perusahaan, agency/freelancer, dan akun suspicious dari data register minimal seperti email, nama, brand, dan nomor HP. Project ini menggabungkan deterministic Go pipeline dengan reasoning loop berbasis OpenClaw AI agar hasilnya tetap evidence-based, auditable, dan tidak bergantung pada tebakan model semata.

Output investigasi disimpan sebagai file evidence dan row PostgreSQL, lalu bisa direview lewat dashboard internal. Sistem juga menyediakan webhook queue untuk integrasi platform register dan Slack daily digest jam 09:00 Asia/Jakarta untuk menyerahkan prospect siap follow-up ke tim sales.

Tech & Libraries

Teknologi dan library yang dipakai atau disentuh di project ini:

Problem

Platform register membutuhkan cara cepat untuk mengenali user yang sebenarnya mewakili bisnis atau perusahaan, tanpa mengganggu flow user personal. Jika seluruh pengecekan dilakukan manual, tim harus membaca email/domain, mencari jejak bisnis, dan menilai confidence satu per satu.

Risiko lainnya adalah false positive: AI bisa terlalu percaya diri jika tidak dipaksa memakai evidence. Karena itu sistem perlu memisahkan evidence collection, scoring deterministik, persistence, dan delivery supaya setiap klasifikasi bisa ditelusuri ulang.

My Role & Ownership

End-to-end owner: Go pipeline, OpenClaw workflow, PostgreSQL schema, dashboard, webhook queue, worker, Slack digest, deployment, and docs.

Technical Approach

Saya membangun pipeline investigasi hybrid. Layer pertama adalah Go CLI yang menjalankan email intelligence, domain check, crawler, search cascade, scraper, brand hint, social link extraction, role signal, scoring, dan evidence/report generation. Layer kedua adalah OpenClaw reasoning loop yang memakai tool output sebagai evidence tambahan saat sinyal awal belum cukup.

Untuk integrasi operasional, saya menambahkan Express webhook API yang hanya melakukan enqueue ke PostgreSQL sehingga request register tetap cepat. Sequential worker kemudian memproses job satu per satu, menjalankan investigasi, memanggil finalizer, menulis hasil ke database/dashboard, mengirim report ke Telegram, dan membiarkan Slack digest membaca data final dari PostgreSQL.

Architecture Notes

Boundary sistem dibuat eksplisit agar AI tidak menjadi satu-satunya sumber kebenaran. Go service bertanggung jawab pada check deterministik dan scoring, OpenClaw bertanggung jawab pada reasoning dan pemilihan tool, finalizer bertanggung jawab menutup investigasi, sedangkan db_writer.js menjadi boundary persistence ke PostgreSQL.

Keputusan arsitektur kunci:

1. Webhook tidak menjalankan investigasi di request HTTP, hanya enqueue ke register_intake_jobs.
2. Worker berjalan sequential by default untuk menjaga limit search/API dan biaya AI.
3. Slack digest membaca row final dan digest tables, bukan pesan realtime dari Telegram.
4. Evidence file tetap dipertahankan untuk audit/debug, sementara PostgreSQL menjadi source of truth operasional.

Trade-offs

Saya memilih PostgreSQL-backed queue dan worker sequential daripada Redis/RabbitMQ atau parallel worker karena volume target sekitar 100 register payload per hari dan prioritasnya adalah reliability, auditability, serta cost control. Konsekuensinya throughput tidak maksimal, tetapi operasional lebih mudah dipahami dan failure state bisa dilihat dari database.

Dashboard internal belum memakai auth aplikasi penuh karena akses MVP dikontrol dari VPS/network. Ini mempercepat validasi produk, tetapi sebelum exposure yang lebih luas perlu ditambah authentication layer dan audit trail yang lebih lengkap.

Implementation Highlights

• Go deterministic pipeline untuk email/domain/crawler/search/scraper/scoring agar hasil repeatable dan auditable
• OpenClaw AI reasoning loop hanya boleh menyimpulkan dari tool output dan wajib finalisasi lewat finish_investigation.sh
• PostgreSQL 16 menyimpan investigation_jobs, final_reports, llm_calls, register_intake_jobs, dan digest tracking
• Webhook API dibuat enqueue-only supaya request platform register cepat dan investigasi berat diproses worker
• Slack digest harian membaca data final dari database, bukan raw AI report, sehingga output lebih aman untuk sales

Results

• Mengubah investigasi akun bisnis dari proses manual menjadi pipeline evidence-based dengan dashboard, queue register, Telegram delivery, dan Slack prospect digest harian.
• Manual/Telegram investigation path validated
• Webhook queue -> sequential worker -> OpenClaw -> finalizer -> PostgreSQL/dashboard path implemented
• Slack daily prospect digest at 09:00 Asia/Jakarta implemented with test-run mode
• One-command VPS deploy available through deploy.sh
• Dashboard exposes list, filter, search, detail, review status, and LLM cost visibility
• Around 100 register submissions per day targeted by sequential queue design
• 75-100 confidence mapped as Hot prospect and 60-74 as Warm prospect
• Daily Slack digest runs at 09:00 Asia/Jakarta
• 3-table MVP investigation storage plus queue/digest tracking tables

Links

• Live Demo
• GitHub Repository