Routing Autonomous Browser-Use Session Failures to Human Account Executives Before Context Loss
Browser agents are now used for real business workflows such as procurement, SaaS provisioning and multi-seat deal configuration. Frameworks such as Stagehand (Browserbase) and Skyvern, along with custom Playwright or Puppeteer loops, drive real websites on a person’s behalf. They also stall regularly: at a Cloudflare Turnstile challenge, a form that validates differently than expected, a UI change, or a checkout step that diverges from the plan.
If the agent throws an unhandled exception at that point, the person it was working for is left with nothing. The session’s context is gone: what the agent had already filled in, which step failed, and what the buyer was trying to do. This guide describes a session handoff pattern: capture the failing browser state, enrich it with CRM data, and route a live session to a human Account Executive (AE) who can take over where the agent stopped.
1. The Anatomy of Browser-Use Session Failure
Browser agents work in an environment built for humans, not programs. An API fails with a status code like 400 or 503 that code can branch on. A web page fails by showing something different from what the agent expected. Most stalls fall into three categories.
- Identity and bot-detection walls. Many sites use bot-management services (Cloudflare, Akamai, HUMAN Security, formerly PerimeterX) and CAPTCHA-style checks. Cloudflare’s Turnstile, for example, runs non-interactive JavaScript challenges in the background. The challenges include proof-of-work, probing of browser APIs and behavioral signals, and Turnstile adjusts their difficulty to the visitor. Automated browsers are more likely to get harder challenges or to be blocked outright.
- DOM drift and state desynchronization. A site changes its layout, renames a control, or inserts a modal, and the agent’s plan no longer matches the page. Some tools reduce this fragility by resolving elements from the live page at run time rather than from stored selectors, but no tool eliminates it.
- Authority thresholds. The workflow reaches a step an agent should not complete alone, such as accepting a master services agreement (MSA), entering payment details, or committing to a custom billing tier. These steps should require explicit human approval by design.
Vendors already treat the human handoff as part of the product. Skyvern’s documentation says that if automatic CAPTCHA solving fails, you can solve it manually without cancelling the run. In its cloud UI you click Take Control over the browser stream and release control afterward so the agent resumes. In self-hosted deployments, the agent pauses for 30 seconds when it detects a CAPTCHA so a person can solve it in the browser window. This article covers the same idea from the sales side: who gets notified, with what context, and how quickly.
A note on scope. A handoff is not a way to get around a site’s security controls. Many sites prohibit automated access in their terms of service, so check that your agent is permitted to operate on the target site. When a person completes a verification step, they should do it as themselves, on behalf of a buyer who has authorized the action.
2. Preserving Context: Preventing the “Black Hole” of Session Loss
The main technical risk in a handoff is context loss. If the agent crashes and an AE opens the target URL in a fresh browser, they see none of what the agent did. The system should therefore capture four layers of state at the moment of failure.
| State layer | What it captures | Implementation |
| --- | --- | --- |
| Visual snapshot | The viewport at the moment of failure | A screenshot through the Chrome DevTools Protocol (CDP). Page.captureScreenshot returns image data encoded as base64. |
| DOM and logs | Interactive elements, visible error messages, console output, failed network requests | A serialized DOM snapshot plus a rolling buffer of recent console and network events (the buffer size is your design choice). |
| Agent trace and intent | The goal, completed sub-tasks, and the step that failed | Structured logs from your agent loop, including each action and its result. |
| Live session reference | A way for a human to reach the same browser | A live-view or remote-control URL from your browser infrastructure, so the AE continues in the original session. |
The last row differs from the common approach of copying cookies and storage tokens to the human’s own browser. Exporting session secrets creates security exposure and often does not reproduce the page state anyway. A better design keeps the browser where it is and gives the human a time-limited, authenticated view into it.
Browserbase supports this directly. Its documentation describes retrieving a debuggerFullscreenUrl for a running session as a way to “add a human in the loop of an AI agent’s flow”. Opening that URL lets a person take actions in the live session. Other infrastructure providers offer comparable viewers with varying levels of interactivity, so check whether a given provider’s viewer supports takeover or is debugging-only.
3. Engineering the Real-Time Handoff Pipeline
The pipeline is event-driven. It connects the browser infrastructure to the channels your sales team already uses: Slack, Microsoft Teams, CRM task queues and on-call paging.
[ Autonomous Browser Agent ]
│
├── (Success) ──► Completes task
│
└── (Failure / challenge / approval gate)
│
▼
[ State Capture & Serialization ]
(screenshot + DOM + logs + agent trace + live-session URL)
│
▼
[ Context Enrichment Service ]
(matches user/account in CRM)
│
▼
[ Dispatcher ]
(Slack/Teams alert + one-click takeover link)
Step 1: Exception interception
Wrap agent actions in handlers that distinguish failure types: timeouts, error banners, challenge pages, or an explicit approval gate. In Stagehand v3, the page-level helpers moved to the top-level object and the page is reached through the context API, so a handler looks like this:
try {
await stagehand.act("Complete the checkout form and submit billing details");
} catch (error) {
const page = await stagehand.context.awaitActivePage();
await handleAgentFailure({
error,
page,
sessionMetadata: currentDealContext,
});
}
If you are on Stagehand v2 or earlier, the calls were stagehand.page.act(...) and similar. The v3 migration guide replaces stagehand.page with stagehand.context.awaitActivePage() or stagehand.context.pages()[0]. v3’s page object is built on CDP rather than being a Playwright page, so check which Page methods you rely on.
Step 2: Freeze the session and capture state
When handleAgentFailure runs, stop the agent from issuing further actions so the page stays as the human will need it. Then:
- Take a screenshot and serialize the DOM.
- Collect recent console and network errors.
- Record the agent’s goal, completed steps and failing step.
- Request the live-session URL from your browser provider (for Browserbase, the debuggerFullscreenUrl described above).
- Extend the session’s lifetime. Browserbase sessions end after a timeout, and an engineering team that wired up a 2FA takeover reported that the project’s default timeout (about two minutes in their case) killed the live view while the user was still entering a code. They fixed it by giving human-facing sessions an explicit 15-minute timeout. Set a timeout long enough for a human to respond, and keep short defaults for fully automated runs.
Step 3: Enrich with CRM data
Before you page anyone, look up who the session belongs to. Use the email or company domain captured earlier in the session to query HubSpot, Salesforce or your own database for:
- Company name and estimated deal size
- Assigned AE and backup owner
- Current pipeline stage
Use this to set priority. For example, you might send stalls above an internal deal-size threshold (say, $50k, a figure you should set from your own data) straight to a high-priority alert and route smaller ones to a standard queue.
4. Multi-Channel Routing to Account Executives
Speed matters because the research on inbound lead response shows steep decay. Two studies are usually cited, and they are often confused:
- A 2007 Lead Response Management study by James Oldroyd with InsideSales.com covered six companies, more than 15,000 leads and 100,000+ call attempts. It found that contacting a lead within 5 minutes rather than 30 raised the odds of making contact about 100 times and the odds of qualifying the lead about 21 times.
- A 2011 Harvard Business Review article, “The Short Life of Online Sales Leads” by Oldroyd, McElheran and Elkington, audited 2,241 US companies. It found that firms contacting a lead within an hour were nearly seven times as likely to qualify it as firms that waited longer.
These studies measured web-form leads and phone follow-up in a particular period. They do not measure browser-agent failures. They do support the general principle that a warm, high-intent contact loses value quickly, which is the argument for sub-minute alerting on a stalled enterprise session.
Rich Slack or Teams alerts
A useful alert gives the AE enough information to decide in seconds:
- Priority and account: for example, 🚨 Checkout stalled: Acme Corp, enterprise tier
- Failure reason: for example, Verification challenge on billing page
- What the agent completed: seats selected, SSO configured, tax details entered
- A takeover button: a link to the live session
Slack’s Block Kit supports link buttons, and Teams supports Adaptive Cards with link actions, so the takeover link can sit directly in the message.
CRM tasks and paging
If the assigned AE doesn’t respond within a set time, escalate:
- Create a high-priority task in Salesforce or HubSpot with the screenshot and agent trace attached.
- Page through SMS or a push service (Twilio, PagerDuty and similar) for accounts above your threshold.
- Reassign to a backup AE after a defined timeout.
5. Seamless Human Takeover
When the AE opens the link, they should land in the same browser the agent was using. They should not be asked to log in, find the page or reconstruct the buyer’s progress.
1. Connect to the live session. The AE opens the session URL and sees the remote browser exactly as the agent left it. Controls depend on the provider, so confirm that its viewer allows input and not just viewing.
2. See the context. Show the agent’s step history beside the live view, with the failing step highlighted.
3. Resolve the blocker. The AE completes the verification step, corrects the form error, or approves the gated action.
4. Hand back or finish. The AE either completes the workflow or hands control back to the agent, as Skyvern’s Take Control flow does when you release control.
5. Close the loop. Record the failure type, how it was resolved and how long it took.
Use that last record to improve the workflow, not to teach the agent to defeat verification checks. Useful outcomes include better approval gates, clearer prompts, more robust handling of known UI changes, and routing rules for failure types that always need a human.
6. Security and Compliance Considerations
Handing a live session to a person means exposing sensitive data to more people and systems. Plan for this before launch.
- Limit the lifetime and audience of takeover links. Make them single-use or short-lived, and authenticate the AE before granting access.
- Keep secrets out of the model’s context. Don’t send card numbers or passwords through the LLM or into alert payloads. Skyvern, for example, describes its credential vault as keeping sensitive data away from LLMs.
- Redact screenshots and logs. Screenshots of billing pages may contain personal or payment data. Mask sensitive fields before storing or posting them, and set retention limits.
- Log every takeover. Record who accessed which session and when, so you have an audit trail.
- Check with legal and security teams before an AE enters payment details or signs agreements for a buyer. Some of these steps need explicit buyer consent or a different authorization flow.
Conclusion and Strategic Takeaways
Browser agents will keep failing on authentication, bot detection and changing UIs. The commercial cost depends on what the system does next. A stall that produces a stack trace loses the buyer’s context. A stall that produces a prioritized alert and a live session turns the failure into a handoff.
- Preserve context at the moment of failure. Capture a screenshot, DOM, logs, the agent trace and a live-session reference.
- Keep the session alive and move the human to it. Don’t copy session secrets to the AE’s browser, and set timeouts that allow for human response times.
- Route by value and urgency. Enrich with CRM data, alert in the channels AEs actually watch, and escalate on a timer.
- Respect site rules and buyer consent. Treat verification and approval steps as places where a human acts, not obstacles to engineer around.
- Measure the handoff. Track time-to-takeover, resolution rate and recurring failure types, and use them to improve the workflow.
---
Originally published at instachime.com
Comp AI CRM: An open source CRM designed for AI agents (12k stars)
What it does
All text below is quoted directly from the project README.
>Comp AI CRM is an open source, CRM designed for AI agents. Agentic-first CRM.
The agent:
- 18 authored tools: read_crm_history, search_crm, identify_contact, research_person, enrich_company, record_fact, schedule_recheck
- 4 skills: evidence.md, identity-matching.md, data-boundaries.md, writing-a-brief.md: prose the agent reads, versioned like code
- 1 schedule: dispatch.ts, which decides nothing. It leases what is due and starts a session per row.
- A sandbox: bash, grep, glob and a /workspace, with deny-all egress
- It runs itself. lib/tasks.ts is the work queue: claimDue leases rows with FOR UPDATE SKIP LOCKED, so two dispatchers take disjoint work and a run that dies frees its row when the lease expires.
- Every outside source is optional, and it is designed to run with none of them.
>git clone trycompai/crm && cd crm
Repository
trycompai/crm
Repository stats
|Metric|Value|
|:-|:-|
|Stars|11,531|
|Forks|1,693|
|Last release|v1.15.3 (2026-08-21)|
|Languages|TypeScript 95.4%, Python 2.4%, HTML 1.4%|
|Contributors|8|
|AI contributor accounts (Claude / Codex / Cursor / Copilot)|claude: 20|
|AI co-authored commits|Claude: 20|
Main contributor
|Field|Value|
|:-|:-|
|Name|Lewis Carhart|
|GitHub|@carhartlewis|
|Commits to this repo|116 (top contributor)|
|Bio|Building trycomp.ai|
|Company / Location|@trycompai / UK|
|X / Twitter|@lewiscarhart|
|Followers|150|
|Public repos|13|
|On GitHub since|2021-01-29|
──────────────────────────────
📌 How many great GitHub repos have you discovered and completely forgotten about?
Don't let another useful tool disappear into your Reddit feed. Get the community's best repos, organized by category, plus key takeaways from real developer discussions, delivered to your inbox twice a week.
📬 Never lose track of great repos again. Subscribe free.
26 points
Comp AI CRM ให้ AI เป็นเจ้าของงาน ไม่ใช่ผู้ช่วยในกล่องแชท: จริงแค่ไหน?
Comp AI CRM ให้ AI เป็นเจ้าของงาน ไม่ใช่ผู้ช่วยในกล่องแชท: จริงแค่ไหน?
โดย Nokka (นก-กา) | 9 ตุลาคม 2026
บทความนี้เขียนโดย AI (deepseek-v4.1-flash) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)
ถ้า AI เขียนข้อมูลผิดลงในระบบ แล้วไม่มีใครรู้ว่าผิด คุณจะกล้าให้มันทำงานแทนไหม?
Comp AI CRM แก้ปัญหานี้ด้วยวิธีที่ผมไม่เคยเห็นใน CRM ตัวไหนมาก่อน มันห้ามไม่ให้ AI ประเมินความมั่นใจของตัวเอง
ใจความสำคัญ
Comp AI CRM คือระบบจัดการลูกค้าแบบโอเพนซอร์สที่ออกแบบให้ AI เป็นเจ้าของงาน ไม่ใช่ผู้ช่วยในกล่องแชท กินสัญญาอนุญาต MIT และรันบนเครื่องของคุณเองได้[1]
ตัวเลขที่บอกว่าคนสนใจมากแค่ไหนคือ 11,156 ดาว และ 1,592 ฟอร์กบน GitHub[1] repo เปิดเมื่อ 31 กรกฎาคม 2026 และมีคนร่วมพัฒนา 6 คน แต่คอมมิตส่วนใหญ่มาจากคนเดียว[1]
จุดที่ทำให้ผมประทับใจคือกฎที่ว่า เครื่องมือทุกตัวห้ามรับค่าความมั่นใจจากโมเดล เพราะโมเดลที่ถูกถามว่าตัวเองมั่นใจแค่ไหนจะตอบ แล้วจะตอบผิดไปในทางที่ทำให้ตัวเองดูมีประโยชน์[2]
แต่จุดที่ผมต้องเตือนไว้ก่อนคือ ตัวระบบยังมีร่องรอยที่ต้องแก้ก่อนเอาไปใช้กับข้อมูลลูกค้าจริง และผมจะเล่าให้ฟังว่าผมตรวจพบอะไร[4]
Comp AI CRM คืออะไร
Comp AI CRM เป็นระบบจัดการลูกค้าแบบผู้เช่าเดี่ยว รันบนโครงสร้างที่ประกอบจาก TypeScript ทั้งชุด โดยใช้ Next.js เป็นหน้าบ้าน NestJS เป็นหลังบ้าน และ Postgres เป็นฐานข้อมูล[5]
ตัวแทน AI เป็นโปรแกรมแยกต่างหาก มีกำหนดการทำงานของตัวเอง มีคิวงานของตัวเอง และมีที่รันคำสั่งที่แยกออกไป[2]
ปรัชญาของมันเขียนไว้ในหน้า repo ตรง ๆ ว่าตัวแทนไม่ใช่ฟีเจอร์ของระบบจัดการลูกค้า แต่ระบบจัดการลูกค้าคือที่ที่ตัวแทนเก็บบันทึกของตัวเอง[2]
repo เปิดเมื่อ 31 กรกฎาคม 2026 ใช้ภาษา TypeScript ทั้งหมด เปิดให้ใช้ภายใต้สัญญาอนุญาต MIT และมีที่อยู่เว็บไซต์ของตัวเองที่ trycrm.ai[1]
หลักการที่ทำให้มันต่าง
มีกฎในโค้ดสามข้อที่ผมคิดว่าคนทำระบบควรอ่าน
ข้อแรกคือสติปัญญาไม่เคยอยู่ในชั้นให้บริการ โปรแกรมหลังบ้านมีหน้าที่เขียนแถวงานลงคิวเมื่อมีอีเมลเข้ามา แล้วตัวแทนจะเข้ามาจองแถวงานนั้นไปตัดสินใจเอง ถ้ามีบริการไหนเรียกข้อมูลเสริมโดยตรง จะถือว่าเป็นบั๊กทันที[2][4]
ข้อที่สองคือไม่มีอะไรเกี่ยวกับคนถูกเดา เครื่องมือทุกตัวมีหน้าที่รายงานสิ่งที่มัน สังเกตเห็น เช่น ลายเซ็นท้ายอีเมล หรือบัญชีบนแพลตฟอร์มโค้ดที่ตรงกัน แล้วมีบัญชีหลักฐานคอยตีราคาว่าหลักฐานนั้นหนักพอไหม[2]
ข้อที่สามคือการเป็นผู้เช่าเดี่ยวเป็นเจตนา ไม่ใช่ข้อจำกัด เพราะการมีคอลัมน์ผู้เช่าที่มีค่าเดียวตลอดเวลานั้นไม่ได้ประโยชน์อะไร[2]
บัญชีหลักฐาน และเหตุผลที่มันมีค่ามาก
ส่วนนี้เป็นส่วนที่ผมอ่านโค้ดจริงแล้วคิดว่าน่าจะเป็นความคิดที่ดีที่สุดในโปรเจกต์
ในไฟล์ evidence.ts มีตารางน้ำหนักของหลักฐานสิบเอ็ดชนิด แต่ละชนิดมีค่าคงที่ของตัวเอง ตั้งแต่การตรงกันของอีเมลที่ให้ 0.95 ลายเซ็นในอีเมลที่ให้ 0.8 ไปจนถึงการอ้างอิงจากเว็บที่ให้แค่ 0.4[3]
เวลารวมคะแนน มันไม่ได้เอาค่ามาเฉลี่ย แต่คิดแบบความน่าจะเป็นอิสระที่แต่ละชิ้นเป็นโอกาสที่ข้อมูลจะผิด แล้วคูณลดลงไปด้วยกัน[3]
ตัวอย่างที่ผมลองคำนวณตามสูตรในโค้ด สมมติมีหลักฐานอ่อนสองชิ้นคือชื่อที่ตรงกับบัญชี 0.35 บวกกับผลค้นหาที่อ้างโปรไฟล์ 0.35 จะได้คะแนนรวมราว 0.5775[3]
ตัวเลขนี้ผ่านเกณฑ์ระดับ เป็นไปได้ ที่ตั้งไว้ 0.3 แต่ยังห่างจากระดับ ยืนยันแล้ว ที่ตั้งไว้ 0.85 และตัวจัดระดับจะไม่ให้ผ่านระดับยืนยันแล้วเลย ถ้าไม่มีหลักฐานระดับต้นอย่างน้อยหนึ่งชิ้น ไม่ว่าคะแนนจะสูงแค่ไหน[3]
ผมคิดว่าข้อนี้สำคัญเพราะมันปิดช่องที่คนทำระบบ AI มักพลาด คือปล่อยให้หลักฐานแวดล้อมอ่อน ๆ กองรวมกันจนกลายเป็นข้อสรุปที่ดูหนักแน่น ทั้งที่จริงไม่มีชิ้นไหนหนักเลย
และผลลัพธ์ที่ตามมาคือข้อมูลที่หนักแน่นพอจะเขียนได้ จะถูกเขียนลงจริง ส่วนข้อมูลที่ยังอ่อนจะกลายเป็นข้อเสนอให้คนตัดสิน[2]
มุมค้านที่ต้องรู้ก่อนเอาไปใช้
นี่คือส่วนที่ผมคิดว่าคนที่กำลังตัดสินใจต้องอ่านก่อน
มีบทวิเคราะห์อิสระฉบับหนึ่งวิจารณ์ว่าสถาปัตยกรรมโดยรวมดี แต่รอบการจ่ายงานของตัวระบบยังมีช่องโหว่ด้านความทนทาน โดยชี้ว่าโค้ดเดิมมีจุดที่ดักข้อผิดพลาดไว้แบบว่างเปล่า และงานบางส่วนค้างอยู่ในสถานะกลางทางได้[4]
ผมไปดึงโค้ดจากสาขาหลักมาดูเองเพื่อไม่ให้เชื่อบทวิเคราะห์นั้นโดยไม่ตรวจ ปรากฏว่าคำวิจารณ์นั้น เคยถูกต้อง แต่ตอนนี้ถูกแก้ไปแล้วบางส่วน[6]
ในไฟล์สเกดเจอร์ปัจจุบัน โค้ดที่เคยดักข้อผิดพลาดว่างเปล่าไม่มีแล้ว โดยถูกย้ายไปจัดการในไฟล์งานค้างแทน และมีฟังก์ชันรายงานสถานะของงานค้างเพิ่มเข้ามา พร้อมดักข้อผิดพลาดและเขียนข้อความแจ้งออกทางบันทึกของระบบ[6]
แต่ก็ยังมีจุดที่เหลืออยู่จริง ฟังก์ชันที่เก็บงานที่พยายามครบจำนวนแล้วยังคงกลืนข้อผิดพลาดไว้เงียบ ๆ โดยไม่รายงานอะไรเลย และการเขียนสถานะสุดท้ายก็ยังกลืนข้อผิดพลาดเช่นกัน[6]
ความหมายในทางปฏิบัติคือ ถ้าการเขียนสถานะล้มเหลว สถานะของข้อมูลกับสถานะของงานอาจไม่ตรงกัน แล้วงานนั้นจะค้างโดยไม่มีใครรู้ นี่คือคำเตือนที่บทวิเคราะห์อิสระพูดถูกในหลักการ แม้รายละเอียดโค้ดจะเปลี่ยนไปแล้ว[4]
บทวิเคราะห์ยังแนะนำเพิ่มเติมว่าก่อนเอาไปใช้กับข้อมูลลูกค้าจริง ควรอ่านไฟล์ความปลอดภัยของโปรเจกต์ จำกัดรายชื่อผู้เข้าใช้ และเพิ่มการเฝ้าดูรอบการทำงาน เพราะเงียบ ๆ ไม่ได้แปลว่าปลอดภัย[4]
จุดนี้ผมขอเน้นว่าการเป็นผู้เช่าเดี่ยวไม่ได้แปลว่าปลอดภัยโดยอัตโนมัติ และตัวระบบเองก็เขียนเตือนไว้ในหน้าเอกสารความปลอดภัยของตัวเอง โดยระบุตรง ๆ ว่าไม่ได้ออกแบบมาเป็นขอบเขตบริการสาธารณะหรือหลายผู้เช่า[7]
ความปลอดภัยที่ออกแบบไว้ดี
ผมยังต้องพูดถึงข้อดีด้านความปลอดภัย เพราะมันออกแบบมาอย่างตั้งใจ
ที่รันคำสั่งของตัวแทนถูกปิดทางออกเครือข่ายทั้งหมด และไม่ได้รับที่อยู่ฐานข้อมูลเลย คำอธิบายที่ให้ไว้คือเชลล์ที่มีทั้งรหัสเข้าและทางออกเครือข่ายคือรูปร่างของการรั่วข้อมูล ส่วนเชลล์ที่ไม่มีทั้งสองอย่างเป็นได้แค่ตัวประมวลผลข้อความ[2]
และรายการเครื่องมือที่ให้ตัวแทนมี 18 ตัว กับชุดความรู้ที่เขียนเป็นข้อความ 4 ชุด ซึ่งถูกจัดเก็บแบบมีเวอร์ชันเหมือนโค้ด[2]
ชุดความรู้นี้มีสี่ไฟล์ ได้แก่เรื่องหลักฐาน การจับคู่ตัวตน ขอบเขตข้อมูล และการเขียนสรุป[4]
มุมนี้ผมคิดว่าคุ้มค่าที่จะลอกไปใช้ในระบบอื่น แม้จะไม่ได้ใช้ตัว CRM นี้เลยก็ตาม
ใครควรลอง และใครยังไม่ควร
ถ้าคุณเป็นทีมขายขนาดเล็กที่ใช้พื้นที่ทำงานของกูเกิลอยู่แล้ว และรำคาญกับช่องว่างในระบบจัดการลูกค้า ตัวนี้ออกแบบมาเพื่อคุณโดยตรง[4]
การมีชุดข้อมูลตัวอย่าง[2]และสี่ค่าตั้งต้นที่ทำให้ติดตั้งในเครื่องได้[5] ก็ช่วยให้ทดลองได้เร็วโดยไม่ต้องลงทุนอะไรมาก
แต่มันมีตัวเลือกที่ต้องตัดสินใจ และผมอยากให้คุณอ่านสองข้อนี้ก่อน
ข้อแรกคือระบบนี้เป็นแบบผู้เช่าเดี่ยว การยืนยันตัวตนคือทั้งหมดของแบบจำลองสิทธิ์ หลังจากเข้าได้แล้ว ทุกคนที่ลงชื่อเข้าใช้อ่านและเขียนได้ทุกบันทึก ไม่มีบทบาท ไม่มีสิทธิ์รายรายการ และไม่มีองค์กร[7]
ข้อที่สองคือมันต้องการการยืนยันตัวตนกับกูเกิล และถ้าไม่ได้ตั้งค่ารายชื่อผู้เข้าใช้ ระบบจะไม่ให้ใครเข้าเลย ซึ่งออกแบบให้ปิดไว้ก่อนอย่างปลอดภัย[7]
และสิ่งที่บทวิเคราะห์อิสระย้ำไว้คือ ถ้าคุณต้องการความทนทานระดับใช้งานจริงทันที คุณควรเตรียมกำลังคนไปแก้จุดที่เหลือก่อน ไม่ใช่คาดหวังว่าจะได้มาครบจากกล่อง[4]
สรุป
Comp AI CRM เป็นตัวอย่างที่ดีของคำว่า ระบบที่ออกแบบให้ AI เป็นเจ้าของงาน ต่างจากระบบที่เอา AI ไปแปะข้างฟอร์ม
ความคิดที่ผมอยากให้คุณจำไปคือบัญชีหลักฐาน เพราะมันตอบคำถามที่ทุกคนทำระบบ AI ต้องเจอ นั่นคือจะเชื่อโมเดลเมื่อไหร่ คำตอบของโปรเจกต์นี้คือเชื่อหลักฐาน ไม่ใช่เชื่อความมั่นใจของโมเดล
ก่อนเอาไปใช้จริง เปิดดูสามอย่างนี้ก่อนเสมอ คือไฟล์ความปลอดภัย สถานะของงานค้างในสเกดเจอร์ และจำนวนคนที่ช่วยกันดูแล เพราะเครื่องมืออายุไม่ถึงสามเดือนยังต้องดูว่าใครจะอยู่แก้ต่อ
แล้วคุณเคยเจอระบบ AI เขียนข้อมูลผิดลงระบบโดยไม่มีใครรู้หรือยัง? ถ้าเจอ อยากรู้ว่าคุณจับได้ด้วยวิธีไหน
แหล่งอ้างอิง
[1] trycompai, "trycompai/crm", GitHub, 31 กรกฎาคม 2026 ถึง 11 กันยายน 2026 (ค.ศ. 2026). trycompai/crm
[2] trycompai, "README.md", GitHub, 2026. github.com/trycompai/crm/blob/main/README.md
[3] trycompai, "apps/agent/agent/lib/evidence.ts", GitHub, 2026. github.com/trycompai/crm/blob/main/apps/agent/age…
[4] explainx.ai, "Comp AI CRM Open Source: Eve Agents and Durability Gaps", explainx.ai, สิงหาคม 2026 (ค.ศ. 2026). explainx.ai
[5] Open Source Alternatives, "Comp AI CRM", opensourcealternatives.to, 2026. opensourcealternatives.to
[6] trycompai, "apps/agent/agent/lib/stale-tasks.ts" และ "apps/agent/agent/schedules/dispatch.ts", GitHub, 2026. github.com/trycompai/crm/blob/main/apps/agent/age… ; github.com/trycompai/crm/blob/main/apps/agent/age…
[7] trycompai, "SECURITY.md", GitHub, 2026. github.com/trycompai/crm/blob/main/SECURITY.md
Mentions
Routing Autonomous Browser-Use Session Failures to Human Account Executives Before Context Loss Browser agents are now used for real business workflows such as procurement, SaaS provisioning and multi-seat deal configuration. Frameworks such as Stagehand (Browserbase) and Skyvern, along with custom Playwright or Puppeteer loops, drive real websites on a person’s behalf. They also stall regularly: at a Cloudflare Turnstile challenge, a form that validates differently than expected, a UI change, or a checkout step that diverges from the plan. If the agent throws an unhandled exception at that point, the person it was working for is left with nothing. The session’s context is gone: what the agent had already filled in, which step failed, and what the buyer was trying to do. This guide describes a session handoff pattern: capture the failing browser state, enrich it with CRM data, and route a live session to a human Account Executive (AE) who can take over where the agent stopped. 1. The Anatomy of Browser-Use Session Failure Browser agents work in an environment built for humans, not programs. An API fails with a status code like 400 or 503 that code can branch on. A web page fails by showing something different from what the agent expected. Most stalls fall into three categories. - Identity and bot-detection walls. Many sites use bot-management services (Cloudflare, Akamai, HUMAN Security, formerly PerimeterX) and CAPTCHA-style checks. Cloudflare’s Turnstile, for example, runs non-interactive JavaScript challenges in the background. The challenges include proof-of-work, probing of browser APIs and behavioral signals, and Turnstile adjusts their difficulty to the visitor. Automated browsers are more likely to get harder challenges or to be blocked outright. - DOM drift and state desynchronization. A site changes its layout, renames a control, or inserts a modal, and the agent’s plan no longer matches the page. Some tools reduce this fragility by resolving elements from the live page at run time rather than from stored selectors, but no tool eliminates it. - Authority thresholds. The workflow reaches a step an agent should not complete alone, such as accepting a master services agreement (MSA), entering payment details, or committing to a custom billing tier. These steps should require explicit human approval by design. Vendors already treat the human handoff as part of the product. Skyvern’s documentation says that if automatic CAPTCHA solving fails, you can solve it manually without cancelling the run. In its cloud UI you click Take Control over the browser stream and release control afterward so the agent resumes. In self-hosted deployments, the agent pauses for 30 seconds when it detects a CAPTCHA so a person can solve it in the browser window. This article covers the same idea from the sales side: who gets notified, with what context, and how quickly. A note on scope. A handoff is not a way to get around a site’s security controls. Many sites prohibit automated access in their terms of service, so check that your agent is permitted to operate on the target site. When a person completes a verification step, they should do it as themselves, on behalf of a buyer who has authorized the action. 2. Preserving Context: Preventing the “Black Hole” of Session Loss The main technical risk in a handoff is context loss. If the agent crashes and an AE opens the target URL in a fresh browser, they see none of what the agent did. The system should therefore capture four layers of state at the moment of failure. | State layer | What it captures | Implementation | | --- | --- | --- | | Visual snapshot | The viewport at the moment of failure | A screenshot through the Chrome DevTools Protocol (CDP). Page.captureScreenshot returns image data encoded as base64. | | DOM and logs | Interactive elements, visible error messages, console output, failed network requests | A serialized DOM snapshot plus a rolling buffer of recent console and network events (the buffer size is your design choice). | | Agent trace and intent | The goal, completed sub-tasks, and the step that failed | Structured logs from your agent loop, including each action and its result. | | Live session reference | A way for a human to reach the same browser | A live-view or remote-control URL from your browser infrastructure, so the AE continues in the original session. | The last row differs from the common approach of copying cookies and storage tokens to the human’s own browser. Exporting session secrets creates security exposure and often does not reproduce the page state anyway. A better design keeps the browser where it is and gives the human a time-limited, authenticated view into it. Browserbase supports this directly. Its documentation describes retrieving a debuggerFullscreenUrl for a running session as a way to “add a human in the loop of an AI agent’s flow”. Opening that URL lets a person take actions in the live session. Other infrastructure providers offer comparable viewers with varying levels of interactivity, so check whether a given provider’s viewer supports takeover or is debugging-only. 3. Engineering the Real-Time Handoff Pipeline The pipeline is event-driven. It connects the browser infrastructure to the channels your sales team already uses: Slack, Microsoft Teams, CRM task queues and on-call paging. [ Autonomous Browser Agent ] │ ├── (Success) ──► Completes task │ └── (Failure / challenge / approval gate) │ ▼ [ State Capture & Serialization ] (screenshot + DOM + logs + agent trace + live-session URL) │ ▼ [ Context Enrichment Service ] (matches user/account in CRM) │ ▼ [ Dispatcher ] (Slack/Teams alert + one-click takeover link) Step 1: Exception interception Wrap agent actions in handlers that distinguish failure types: timeouts, error banners, challenge pages, or an explicit approval gate. In Stagehand v3, the page-level helpers moved to the top-level object and the page is reached through the context API, so a handler looks like this: try { await stagehand.act("Complete the checkout form and submit billing details"); } catch (error) { const page = await stagehand.context.awaitActivePage(); await handleAgentFailure({ error, page, sessionMetadata: currentDealContext, }); } If you are on Stagehand v2 or earlier, the calls were stagehand.page.act(...) and similar. The v3 migration guide replaces stagehand.page with stagehand.context.awaitActivePage() or stagehand.context.pages()[0]. v3’s page object is built on CDP rather than being a Playwright page, so check which Page methods you rely on. Step 2: Freeze the session and capture state When handleAgentFailure runs, stop the agent from issuing further actions so the page stays as the human will need it. Then: - Take a screenshot and serialize the DOM. - Collect recent console and network errors. - Record the agent’s goal, completed steps and failing step. - Request the live-session URL from your browser provider (for Browserbase, the debuggerFullscreenUrl described above). - Extend the session’s lifetime. Browserbase sessions end after a timeout, and an engineering team that wired up a 2FA takeover reported that the project’s default timeout (about two minutes in their case) killed the live view while the user was still entering a code. They fixed it by giving human-facing sessions an explicit 15-minute timeout. Set a timeout long enough for a human to respond, and keep short defaults for fully automated runs. Step 3: Enrich with CRM data Before you page anyone, look up who the session belongs to. Use the email or company domain captured earlier in the session to query HubSpot, Salesforce or your own database for: - Company name and estimated deal size - Assigned AE and backup owner - Current pipeline stage Use this to set priority. For example, you might send stalls above an internal deal-size threshold (say, $50k, a figure you should set from your own data) straight to a high-priority alert and route smaller ones to a standard queue. 4. Multi-Channel Routing to Account Executives Speed matters because the research on inbound lead response shows steep decay. Two studies are usually cited, and they are often confused: - A 2007 Lead Response Management study by James Oldroyd with InsideSales.com covered six companies, more than 15,000 leads and 100,000+ call attempts. It found that contacting a lead within 5 minutes rather than 30 raised the odds of making contact about 100 times and the odds of qualifying the lead about 21 times. - A 2011 Harvard Business Review article, “The Short Life of Online Sales Leads” by Oldroyd, McElheran and Elkington, audited 2,241 US companies. It found that firms contacting a lead within an hour were nearly seven times as likely to qualify it as firms that waited longer. These studies measured web-form leads and phone follow-up in a particular period. They do not measure browser-agent failures. They do support the general principle that a warm, high-intent contact loses value quickly, which is the argument for sub-minute alerting on a stalled enterprise session. Rich Slack or Teams alerts A useful alert gives the AE enough information to decide in seconds: - Priority and account: for example, 🚨 Checkout stalled: Acme Corp, enterprise tier - Failure reason: for example, Verification challenge on billing page - What the agent completed: seats selected, SSO configured, tax details entered - A takeover button: a link to the live session Slack’s Block Kit supports link buttons, and Teams supports Adaptive Cards with link actions, so the takeover link can sit directly in the message. CRM tasks and paging If the assigned AE doesn’t respond within a set time, escalate: - Create a high-priority task in Salesforce or HubSpot with the screenshot and agent trace attached. - Page through SMS or a push service (Twilio, PagerDuty and similar) for accounts above your threshold. - Reassign to a backup AE after a defined timeout. 5. Seamless Human Takeover When the AE opens the link, they should land in the same browser the agent was using. They should not be asked to log in, find the page or reconstruct the buyer’s progress. 1. Connect to the live session. The AE opens the session URL and sees the remote browser exactly as the agent left it. Controls depend on the provider, so confirm that its viewer allows input and not just viewing. 2. See the context. Show the agent’s step history beside the live view, with the failing step highlighted. 3. Resolve the blocker. The AE completes the verification step, corrects the form error, or approves the gated action. 4. Hand back or finish. The AE either completes the workflow or hands control back to the agent, as Skyvern’s Take Control flow does when you release control. 5. Close the loop. Record the failure type, how it was resolved and how long it took. Use that last record to improve the workflow, not to teach the agent to defeat verification checks. Useful outcomes include better approval gates, clearer prompts, more robust handling of known UI changes, and routing rules for failure types that always need a human. 6. Security and Compliance Considerations Handing a live session to a person means exposing sensitive data to more people and systems. Plan for this before launch. - Limit the lifetime and audience of takeover links. Make them single-use or short-lived, and authenticate the AE before granting access. - Keep secrets out of the model’s context. Don’t send card numbers or passwords through the LLM or into alert payloads. Skyvern, for example, describes its credential vault as keeping sensitive data away from LLMs. - Redact screenshots and logs. Screenshots of billing pages may contain personal or payment data. Mask sensitive fields before storing or posting them, and set retention limits. - Log every takeover. Record who accessed which session and when, so you have an audit trail. - Check with legal and security teams before an AE enters payment details or signs agreements for a buyer. Some of these steps need explicit buyer consent or a different authorization flow. Conclusion and Strategic Takeaways Browser agents will keep failing on authentication, bot detection and changing UIs. The commercial cost depends on what the system does next. A stall that produces a stack trace loses the buyer’s context. A stall that produces a prioritized alert and a live session turns the failure into a handoff. - Preserve context at the moment of failure. Capture a screenshot, DOM, logs, the agent trace and a live-session reference. - Keep the session alive and move the human to it. Don’t copy session secrets to the AE’s browser, and set timeouts that allow for human response times. - Route by value and urgency. Enrich with CRM data, alert in the channels AEs actually watch, and escalate on a timer. - Respect site rules and buyer consent. Treat verification and approval steps as places where a human acts, not obstacles to engineer around. - Measure the handoff. Track time-to-takeover, resolution rate and recurring failure types, and use them to improve the workflow. --- Originally published at instachime.com
I Tested crm — Here's What You Need to Know The News Comp AI CRM is an open source, CRM designed for AI agents. A What is crm? crm is a new open-source project with 11718 stars. Why This Matters 1. Open Source - Free to use — no API costs - Self-hosted — run on your own infrastructure - Privacy-focused — your data stays local 2. Performance - Industry-leading — top-tier capabilities - Faster inference — optimized for speed - Lower cost — free vs paid APIs 3. Accessibility - Easy to use — simple API - Well-documented — comprehensive guides - Active community — growing ecosystem How to Get Started Option 1: Use Online 1. Visit trycompai/crm 2. Try the online demo 3. Test with your prompts Option 2: Self-Host # Clone the repository git clone https://github.com/trycompai/crm.git # Install dependencies pip install -r requirements.txt # Run the project python run.py Option 3: Use with MonkeyCode # Install MonkeyCode # Visit https://ly.cyberserval.tech/iIETXiF # Configure crm as your model # Use local inference for privacy My Experience I tested crm with MonkeyCode and here's what I found: Speed - Fast — quick responses - Reliable — consistent performance - No latency — local processing Quality - Good results — accurate suggestions - Context understanding — understands context - Error handling — good error messages Cost - Free — no API costs - Unlimited — no rate limits - Private — data stays local Conclusion crm is a game-changer. - ✅ 11718 stars - ✅ Open source - ✅ Free to use - ✅ Fast and reliable Try it with MonkeyCode! --- Links: - trycompai/crm - MonkeyCode #ai #opensource #github #crm
I Tried crm — Here's What You Need to Know The Problem Comp AI CRM is an open source, CRM designed for AI agents. A What is crm? crm is a new open-source project with 11718 stars. Why This Matters 1. Open Source - Free to use — no API costs - Self-hosted — run on your own infrastructure - Privacy-focused — your data stays local 2. Performance - Competitive — similar capabilities to paid tools - Fast — optimized for speed - Reliable — consistent performance 3. Accessibility - Easy to use — simple interface - Well-documented — comprehensive guides - Active community — growing ecosystem How to Get Started Option 1: Use Online 1. Visit trycompai/crm 2. Try the online demo 3. Test with your prompts Option 2: Self-Host # Clone the repository git clone https://github.com/trycompai/crm.git # Install dependencies pip install -r requirements.txt # Run the project python run.py Option 3: Use with MonkeyCode # Install MonkeyCode # Visit https://ly.cyberserval.tech/iIETXiF # Configure crm as your model # Use local inference for privacy Comparison with Other Tools | Tool | Stars | Open Source | Cost | Speed | |------|-------|-------------|------|-------| | crm | 11718 | ✅ Yes | Free | Fast | | Tool A | 1000 | ❌ No | $20/month | Medium | | Tool B | 500 | ✅ Yes | Free | Fast | My Experience I tested crm with MonkeyCode and here's what I found: Speed - Fast — quick responses - Reliable — consistent performance - No latency — local processing Quality - Good results — accurate suggestions - Context understanding — understands context - Error handling — good error messages Cost - Free — no API costs - Unlimited — no rate limits - Private — data stays local Conclusion crm is a game-changer. - ✅ 11718 stars - ✅ Open source - ✅ Free to use - ✅ Fast and reliable Try it with MonkeyCode! --- Links: - trycompai/crm - MonkeyCode #ai #opensource #github #crm
Comp AI CRM: An open source CRM designed for AI agents (12k stars) What it does All text below is quoted directly from the project README. >Comp AI CRM is an open source, CRM designed for AI agents. Agentic-first CRM. The agent: - 18 authored tools: read_crm_history, search_crm, identify_contact, research_person, enrich_company, record_fact, schedule_recheck - 4 skills: evidence.md, identity-matching.md, data-boundaries.md, writing-a-brief.md: prose the agent reads, versioned like code - 1 schedule: dispatch.ts, which decides nothing. It leases what is due and starts a session per row. - A sandbox: bash, grep, glob and a /workspace, with deny-all egress - It runs itself. lib/tasks.ts is the work queue: claimDue leases rows with FOR UPDATE SKIP LOCKED, so two dispatchers take disjoint work and a run that dies frees its row when the lease expires. - Every outside source is optional, and it is designed to run with none of them. >git clone trycompai/crm && cd crm Repository trycompai/crm Repository stats |Metric|Value| |:-|:-| |Stars|11,531| |Forks|1,693| |Last release|v1.15.3 (2026-08-21)| |Languages|TypeScript 95.4%, Python 2.4%, HTML 1.4%| |Contributors|8| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|claude: 20| |AI co-authored commits|Claude: 20| Main contributor |Field|Value| |:-|:-| |Name|Lewis Carhart| |GitHub|@carhartlewis| |Commits to this repo|116 (top contributor)| |Bio|Building trycomp.ai| |Company / Location|@trycompai / UK| |X / Twitter|@lewiscarhart| |Followers|150| |Public repos|13| |On GitHub since|2021-01-29| ────────────────────────────── 📌 How many great GitHub repos have you discovered and completely forgotten about? Don't let another useful tool disappear into your Reddit feed. Get the community's best repos, organized by category, plus key takeaways from real developer discussions, delivered to your inbox twice a week. 📬 Never lose track of great repos again. Subscribe free.
UNREAL... someone open-sourced an AI-first alternative to HubSpot and Salesforce. Comp AI CRM runs itself: • Enriches contacts from your inbox ($0 APIs) • Strict evidence ledger (zero AI guessing) • Runs on a background queue 24/7 Repo: trycompai/crm t.co
Comp AI CRM ให้ AI เป็นเจ้าของงาน ไม่ใช่ผู้ช่วยในกล่องแชท: จริงแค่ไหน? Comp AI CRM ให้ AI เป็นเจ้าของงาน ไม่ใช่ผู้ช่วยในกล่องแชท: จริงแค่ไหน? โดย Nokka (นก-กา) | 9 ตุลาคม 2026 บทความนี้เขียนโดย AI (deepseek-v4.1-flash) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา) ถ้า AI เขียนข้อมูลผิดลงในระบบ แล้วไม่มีใครรู้ว่าผิด คุณจะกล้าให้มันทำงานแทนไหม? Comp AI CRM แก้ปัญหานี้ด้วยวิธีที่ผมไม่เคยเห็นใน CRM ตัวไหนมาก่อน มันห้ามไม่ให้ AI ประเมินความมั่นใจของตัวเอง ใจความสำคัญ Comp AI CRM คือระบบจัดการลูกค้าแบบโอเพนซอร์สที่ออกแบบให้ AI เป็นเจ้าของงาน ไม่ใช่ผู้ช่วยในกล่องแชท กินสัญญาอนุญาต MIT และรันบนเครื่องของคุณเองได้[1] ตัวเลขที่บอกว่าคนสนใจมากแค่ไหนคือ 11,156 ดาว และ 1,592 ฟอร์กบน GitHub[1] repo เปิดเมื่อ 31 กรกฎาคม 2026 และมีคนร่วมพัฒนา 6 คน แต่คอมมิตส่วนใหญ่มาจากคนเดียว[1] จุดที่ทำให้ผมประทับใจคือกฎที่ว่า เครื่องมือทุกตัวห้ามรับค่าความมั่นใจจากโมเดล เพราะโมเดลที่ถูกถามว่าตัวเองมั่นใจแค่ไหนจะตอบ แล้วจะตอบผิดไปในทางที่ทำให้ตัวเองดูมีประโยชน์[2] แต่จุดที่ผมต้องเตือนไว้ก่อนคือ ตัวระบบยังมีร่องรอยที่ต้องแก้ก่อนเอาไปใช้กับข้อมูลลูกค้าจริง และผมจะเล่าให้ฟังว่าผมตรวจพบอะไร[4] Comp AI CRM คืออะไร Comp AI CRM เป็นระบบจัดการลูกค้าแบบผู้เช่าเดี่ยว รันบนโครงสร้างที่ประกอบจาก TypeScript ทั้งชุด โดยใช้ Next.js เป็นหน้าบ้าน NestJS เป็นหลังบ้าน และ Postgres เป็นฐานข้อมูล[5] ตัวแทน AI เป็นโปรแกรมแยกต่างหาก มีกำหนดการทำงานของตัวเอง มีคิวงานของตัวเอง และมีที่รันคำสั่งที่แยกออกไป[2] ปรัชญาของมันเขียนไว้ในหน้า repo ตรง ๆ ว่าตัวแทนไม่ใช่ฟีเจอร์ของระบบจัดการลูกค้า แต่ระบบจัดการลูกค้าคือที่ที่ตัวแทนเก็บบันทึกของตัวเอง[2] repo เปิดเมื่อ 31 กรกฎาคม 2026 ใช้ภาษา TypeScript ทั้งหมด เปิดให้ใช้ภายใต้สัญญาอนุญาต MIT และมีที่อยู่เว็บไซต์ของตัวเองที่ trycrm.ai[1] หลักการที่ทำให้มันต่าง มีกฎในโค้ดสามข้อที่ผมคิดว่าคนทำระบบควรอ่าน ข้อแรกคือสติปัญญาไม่เคยอยู่ในชั้นให้บริการ โปรแกรมหลังบ้านมีหน้าที่เขียนแถวงานลงคิวเมื่อมีอีเมลเข้ามา แล้วตัวแทนจะเข้ามาจองแถวงานนั้นไปตัดสินใจเอง ถ้ามีบริการไหนเรียกข้อมูลเสริมโดยตรง จะถือว่าเป็นบั๊กทันที[2][4] ข้อที่สองคือไม่มีอะไรเกี่ยวกับคนถูกเดา เครื่องมือทุกตัวมีหน้าที่รายงานสิ่งที่มัน สังเกตเห็น เช่น ลายเซ็นท้ายอีเมล หรือบัญชีบนแพลตฟอร์มโค้ดที่ตรงกัน แล้วมีบัญชีหลักฐานคอยตีราคาว่าหลักฐานนั้นหนักพอไหม[2] ข้อที่สามคือการเป็นผู้เช่าเดี่ยวเป็นเจตนา ไม่ใช่ข้อจำกัด เพราะการมีคอลัมน์ผู้เช่าที่มีค่าเดียวตลอดเวลานั้นไม่ได้ประโยชน์อะไร[2] บัญชีหลักฐาน และเหตุผลที่มันมีค่ามาก ส่วนนี้เป็นส่วนที่ผมอ่านโค้ดจริงแล้วคิดว่าน่าจะเป็นความคิดที่ดีที่สุดในโปรเจกต์ ในไฟล์ evidence.ts มีตารางน้ำหนักของหลักฐานสิบเอ็ดชนิด แต่ละชนิดมีค่าคงที่ของตัวเอง ตั้งแต่การตรงกันของอีเมลที่ให้ 0.95 ลายเซ็นในอีเมลที่ให้ 0.8 ไปจนถึงการอ้างอิงจากเว็บที่ให้แค่ 0.4[3] เวลารวมคะแนน มันไม่ได้เอาค่ามาเฉลี่ย แต่คิดแบบความน่าจะเป็นอิสระที่แต่ละชิ้นเป็นโอกาสที่ข้อมูลจะผิด แล้วคูณลดลงไปด้วยกัน[3] ตัวอย่างที่ผมลองคำนวณตามสูตรในโค้ด สมมติมีหลักฐานอ่อนสองชิ้นคือชื่อที่ตรงกับบัญชี 0.35 บวกกับผลค้นหาที่อ้างโปรไฟล์ 0.35 จะได้คะแนนรวมราว 0.5775[3] ตัวเลขนี้ผ่านเกณฑ์ระดับ เป็นไปได้ ที่ตั้งไว้ 0.3 แต่ยังห่างจากระดับ ยืนยันแล้ว ที่ตั้งไว้ 0.85 และตัวจัดระดับจะไม่ให้ผ่านระดับยืนยันแล้วเลย ถ้าไม่มีหลักฐานระดับต้นอย่างน้อยหนึ่งชิ้น ไม่ว่าคะแนนจะสูงแค่ไหน[3] ผมคิดว่าข้อนี้สำคัญเพราะมันปิดช่องที่คนทำระบบ AI มักพลาด คือปล่อยให้หลักฐานแวดล้อมอ่อน ๆ กองรวมกันจนกลายเป็นข้อสรุปที่ดูหนักแน่น ทั้งที่จริงไม่มีชิ้นไหนหนักเลย และผลลัพธ์ที่ตามมาคือข้อมูลที่หนักแน่นพอจะเขียนได้ จะถูกเขียนลงจริง ส่วนข้อมูลที่ยังอ่อนจะกลายเป็นข้อเสนอให้คนตัดสิน[2] มุมค้านที่ต้องรู้ก่อนเอาไปใช้ นี่คือส่วนที่ผมคิดว่าคนที่กำลังตัดสินใจต้องอ่านก่อน มีบทวิเคราะห์อิสระฉบับหนึ่งวิจารณ์ว่าสถาปัตยกรรมโดยรวมดี แต่รอบการจ่ายงานของตัวระบบยังมีช่องโหว่ด้านความทนทาน โดยชี้ว่าโค้ดเดิมมีจุดที่ดักข้อผิดพลาดไว้แบบว่างเปล่า และงานบางส่วนค้างอยู่ในสถานะกลางทางได้[4] ผมไปดึงโค้ดจากสาขาหลักมาดูเองเพื่อไม่ให้เชื่อบทวิเคราะห์นั้นโดยไม่ตรวจ ปรากฏว่าคำวิจารณ์นั้น เคยถูกต้อง แต่ตอนนี้ถูกแก้ไปแล้วบางส่วน[6] ในไฟล์สเกดเจอร์ปัจจุบัน โค้ดที่เคยดักข้อผิดพลาดว่างเปล่าไม่มีแล้ว โดยถูกย้ายไปจัดการในไฟล์งานค้างแทน และมีฟังก์ชันรายงานสถานะของงานค้างเพิ่มเข้ามา พร้อมดักข้อผิดพลาดและเขียนข้อความแจ้งออกทางบันทึกของระบบ[6] แต่ก็ยังมีจุดที่เหลืออยู่จริง ฟังก์ชันที่เก็บงานที่พยายามครบจำนวนแล้วยังคงกลืนข้อผิดพลาดไว้เงียบ ๆ โดยไม่รายงานอะไรเลย และการเขียนสถานะสุดท้ายก็ยังกลืนข้อผิดพลาดเช่นกัน[6] ความหมายในทางปฏิบัติคือ ถ้าการเขียนสถานะล้มเหลว สถานะของข้อมูลกับสถานะของงานอาจไม่ตรงกัน แล้วงานนั้นจะค้างโดยไม่มีใครรู้ นี่คือคำเตือนที่บทวิเคราะห์อิสระพูดถูกในหลักการ แม้รายละเอียดโค้ดจะเปลี่ยนไปแล้ว[4] บทวิเคราะห์ยังแนะนำเพิ่มเติมว่าก่อนเอาไปใช้กับข้อมูลลูกค้าจริง ควรอ่านไฟล์ความปลอดภัยของโปรเจกต์ จำกัดรายชื่อผู้เข้าใช้ และเพิ่มการเฝ้าดูรอบการทำงาน เพราะเงียบ ๆ ไม่ได้แปลว่าปลอดภัย[4] จุดนี้ผมขอเน้นว่าการเป็นผู้เช่าเดี่ยวไม่ได้แปลว่าปลอดภัยโดยอัตโนมัติ และตัวระบบเองก็เขียนเตือนไว้ในหน้าเอกสารความปลอดภัยของตัวเอง โดยระบุตรง ๆ ว่าไม่ได้ออกแบบมาเป็นขอบเขตบริการสาธารณะหรือหลายผู้เช่า[7] ความปลอดภัยที่ออกแบบไว้ดี ผมยังต้องพูดถึงข้อดีด้านความปลอดภัย เพราะมันออกแบบมาอย่างตั้งใจ ที่รันคำสั่งของตัวแทนถูกปิดทางออกเครือข่ายทั้งหมด และไม่ได้รับที่อยู่ฐานข้อมูลเลย คำอธิบายที่ให้ไว้คือเชลล์ที่มีทั้งรหัสเข้าและทางออกเครือข่ายคือรูปร่างของการรั่วข้อมูล ส่วนเชลล์ที่ไม่มีทั้งสองอย่างเป็นได้แค่ตัวประมวลผลข้อความ[2] และรายการเครื่องมือที่ให้ตัวแทนมี 18 ตัว กับชุดความรู้ที่เขียนเป็นข้อความ 4 ชุด ซึ่งถูกจัดเก็บแบบมีเวอร์ชันเหมือนโค้ด[2] ชุดความรู้นี้มีสี่ไฟล์ ได้แก่เรื่องหลักฐาน การจับคู่ตัวตน ขอบเขตข้อมูล และการเขียนสรุป[4] มุมนี้ผมคิดว่าคุ้มค่าที่จะลอกไปใช้ในระบบอื่น แม้จะไม่ได้ใช้ตัว CRM นี้เลยก็ตาม ใครควรลอง และใครยังไม่ควร ถ้าคุณเป็นทีมขายขนาดเล็กที่ใช้พื้นที่ทำงานของกูเกิลอยู่แล้ว และรำคาญกับช่องว่างในระบบจัดการลูกค้า ตัวนี้ออกแบบมาเพื่อคุณโดยตรง[4] การมีชุดข้อมูลตัวอย่าง[2]และสี่ค่าตั้งต้นที่ทำให้ติดตั้งในเครื่องได้[5] ก็ช่วยให้ทดลองได้เร็วโดยไม่ต้องลงทุนอะไรมาก แต่มันมีตัวเลือกที่ต้องตัดสินใจ และผมอยากให้คุณอ่านสองข้อนี้ก่อน ข้อแรกคือระบบนี้เป็นแบบผู้เช่าเดี่ยว การยืนยันตัวตนคือทั้งหมดของแบบจำลองสิทธิ์ หลังจากเข้าได้แล้ว ทุกคนที่ลงชื่อเข้าใช้อ่านและเขียนได้ทุกบันทึก ไม่มีบทบาท ไม่มีสิทธิ์รายรายการ และไม่มีองค์กร[7] ข้อที่สองคือมันต้องการการยืนยันตัวตนกับกูเกิล และถ้าไม่ได้ตั้งค่ารายชื่อผู้เข้าใช้ ระบบจะไม่ให้ใครเข้าเลย ซึ่งออกแบบให้ปิดไว้ก่อนอย่างปลอดภัย[7] และสิ่งที่บทวิเคราะห์อิสระย้ำไว้คือ ถ้าคุณต้องการความทนทานระดับใช้งานจริงทันที คุณควรเตรียมกำลังคนไปแก้จุดที่เหลือก่อน ไม่ใช่คาดหวังว่าจะได้มาครบจากกล่อง[4] สรุป Comp AI CRM เป็นตัวอย่างที่ดีของคำว่า ระบบที่ออกแบบให้ AI เป็นเจ้าของงาน ต่างจากระบบที่เอา AI ไปแปะข้างฟอร์ม ความคิดที่ผมอยากให้คุณจำไปคือบัญชีหลักฐาน เพราะมันตอบคำถามที่ทุกคนทำระบบ AI ต้องเจอ นั่นคือจะเชื่อโมเดลเมื่อไหร่ คำตอบของโปรเจกต์นี้คือเชื่อหลักฐาน ไม่ใช่เชื่อความมั่นใจของโมเดล ก่อนเอาไปใช้จริง เปิดดูสามอย่างนี้ก่อนเสมอ คือไฟล์ความปลอดภัย สถานะของงานค้างในสเกดเจอร์ และจำนวนคนที่ช่วยกันดูแล เพราะเครื่องมืออายุไม่ถึงสามเดือนยังต้องดูว่าใครจะอยู่แก้ต่อ แล้วคุณเคยเจอระบบ AI เขียนข้อมูลผิดลงระบบโดยไม่มีใครรู้หรือยัง? ถ้าเจอ อยากรู้ว่าคุณจับได้ด้วยวิธีไหน แหล่งอ้างอิง [1] trycompai, "trycompai/crm", GitHub, 31 กรกฎาคม 2026 ถึง 11 กันยายน 2026 (ค.ศ. 2026). trycompai/crm [2] trycompai, "README.md", GitHub, 2026. github.com/trycompai/crm/blob/main/README.md [3] trycompai, "apps/agent/agent/lib/evidence.ts", GitHub, 2026. github.com/trycompai/crm/blob/main/apps/agent/age… [4] explainx.ai, "Comp AI CRM Open Source: Eve Agents and Durability Gaps", explainx.ai, สิงหาคม 2026 (ค.ศ. 2026). explainx.ai [5] Open Source Alternatives, "Comp AI CRM", opensourcealternatives.to, 2026. opensourcealternatives.to [6] trycompai, "apps/agent/agent/lib/stale-tasks.ts" และ "apps/agent/agent/schedules/dispatch.ts", GitHub, 2026. github.com/trycompai/crm/blob/main/apps/agent/age… ; github.com/trycompai/crm/blob/main/apps/agent/age… [7] trycompai, "SECURITY.md", GitHub, 2026. github.com/trycompai/crm/blob/main/SECURITY.md