Event Triggers บน Garudust

The article explains that Garudust uses a single core primitive, `agent.run(task)`, to handle all event triggers, including chat messages, cron jobs, and webhooks, by converting external HTTP POST requests into tasks. It details the technical implementation, such as using an Axum HTTP server, HMAC-SHA256 signature verification for security, and asynchronous processing that returns a `202 Accepted` response. The article also provides concrete use cases, including email processing, GitHub Actions workflows, monitoring jobs, and calendar integrations, where external systems handle filtering and task creation while Garudust manages agent execution and result handling via callback URLs.

core ของ Garudust เปิดเผย primitive พื้นฐานตัวเดียว: agent.run task ทุก entry point — ไม่ว่าจะเป็นข้อความจากแชท, cron job, หรือ webhook call — ล้วนลงเอยที่ call เดียวกันนี้ทั้งสิ้น นั่นหมายความว่าระบบภายนอกใดก็ตามที่ส่ง HTTP POST ได้ ก็สามารถเป็น event trigger ให้ Garudust ได้เลย บทความนี้จะอธิบายว่ามันทำงานอย่างไรในปัจจุบัน, pattern ที่ใช้งานได้จริงใน production และ use case ที่เป็นรูปธรรม เมื่อ Garudust ถูกตั้งค่าให้ใช้ webhook platform มันจะเปิด Axum HTTP server และลงทะเบียน POST endpoint ไว้ที่ path ที่คุณกำหนด request ขาเข้าจะมีหน้าตาแบบนี้: { "text": "A new billing invoice has arrived from Acme Corp for $4,200.", "callback url": "https://your-system.example.com/garudust/reply", "user id": "billing-watcher", "session key": "billing-acme-corp" } Garudust จะห่อข้อมูลนี้เป็น InboundMessage , ส่งผ่าน GatewayHandler , spawn agent.run ขึ้นมา และเมื่อ agent ทำงานเสร็จก็จะ POST คำตอบกลับไปที่ callback url : { "text": "Invoice from Acme Corp for $4,200 — categorised as SaaS/Infrastructure. Flagged for approval above $3,000 threshold. Draft approval request sent to finance." } HTTP response ที่ตอบกลับ POST ของคุณทันทีคือ 202 Accepted — agent ทำงานแบบ asynchronous Garudust ตรวจสอบ HMAC-SHA256 signature ทุก request ที่เข้ามา ตั้ง shared secret ใน config แล้ว sign ทุก POST ขาออกด้วย: X-Hub-Signature-256: sha256=<hex HMAC-SHA256 secret, raw body Request ที่ไม่มี signature ถูกต้องจะถูกปฏิเสธด้วย 401 และ callback URL ที่ชี้ไป private IP 192.168.x.x , 10.x.x.x , localhost ก็ถูก block โดย network guard ด้วย — agent ไม่สามารถถูกบังคับให้ call back หา internal infrastructure ได้ การแบ่งหน้าที่ชัดเจนมาก: ระบบภายนอก Garudust ───────────────── ────────────────────────── Event source email, → Webhook adapter calendar, DB, queue Filter / match logic → โค้ดของคุณ ก่อน POST Task description → agent.run task Result handling → handler ที่ callback url ของคุณ ระบบของคุณเป็นเจ้าของ filter — Garudust เป็นเจ้าของการรัน agent ทั้งสองฝั่งไม่จำเป็นต้องรู้โครงสร้างภายในของกันและกันเลย บริการประมวลผลอีเมลคอยดักจับอีเมลจากผู้ส่งที่เป็นระบบ billing เมื่อเจออีเมลที่ match ก็ดึง subject, ผู้ส่ง และจำนวนเงิน แล้ว trigger Garudust: { "text": "New invoice received: Stripe — $1,840 for May 2026. Attach to this month's expense report and notify the finance channel if it exceeds the $1,500 alert threshold.", "callback url": "https://your-ops.example.com/hooks/garudust", "session key": "finance-inbox" } Agent ใช้ tool ของมันอ่านไฟล์ expense report, เพิ่ม line item และโพสต์แจ้ง Slack บริการอีเมลทำแค่ match ผู้ส่งแล้วยิง — ไม่ต้องรู้อะไรเกี่ยวกับ expense report หรือ Slack เลย GitHub Actions workflow เรียก Garudust หลังมี PR เปิดเข้ามาที่ branch main โดย workflow สร้าง payload จาก GitHub context: { "text": "PR 214 opened by @alice: 'feat: add OAuth2 PKCE flow'. Changed files: src/auth/oauth.rs, src/auth/pkce.rs, tests/auth integration.rs. Diff summary attached. Review for security issues in the auth flow and post a summary comment.", "callback url": "https://your-ci.example.com/garudust/pr-review", "session key": "pr-214" } webhook ของ GitHub ยิง workflow → workflow สร้าง task text → Garudust รีวิว และ session key ที่ผูกกับเลข PR ทำให้ trigger ครั้งถัดไป commit ใหม่, ขอรีวิวซ้ำ ต่อเนื่องใน conversation thread เดิม Monitoring job query ฐานข้อมูลตามตาราง schedule แล้วตรวจ aggregate metric เมื่อ metric ข้ามเกณฑ์ แทนที่จะส่ง static alert มันยิง Garudust แทน: { "text": "Anomaly detected: orders table insert rate dropped 94% in the last 10 minutes baseline 340/min, current 19/min . Last successful insert: 09:42 UTC. Investigate root cause and summarise for on-call.", "callback url": "https://ops.example.com/garudust/incidents", "session key": "incident-2026-05-23-orders" } Agent สามารถใช้ terminal หรือ database tool รัน query เพิ่มเติม, ตรวจ deploy ล่าสุด และสรุป incident แบบมีโครงสร้าง — monitoring job ทำแค่ตรวจ threshold breach เท่านั้น Integration layer poll Google Calendar หรือรับ push notification แล้วยิง Garudust เมื่อมี event ถูกสร้างขึ้นพร้อม attendee ที่ domain ไม่ตรงกับองค์กรของคุณ: { "text": "New calendar event: 'Q3 partnership discussion' on 2026-06-04 14:00 UTC. External attendees: jane@partner.com, bob@partner.com. Prepare a one-page briefing on Partner Corp using the CRM notes and recent email thread.", "callback url": "https://your-system.example.com/garudust/calendar", "session key": "meeting-prep-2026-06-04" } Calendar integration เป็นเจ้าของ logic กรอง "external attendee" — Garudust เป็นเจ้าของการสร้าง briefing Background worker ดึงงานออกจาก task queue SQS, Redis, RabbitMQ แล้วส่งแต่ละชิ้นให้ Garudust ทำ เหมาะกับงานที่ปริมาณผันแปรและต้องการให้ agent จัดการแต่ละชิ้นในแบบของตัวเอง: { "text": "Customer support ticket 8821 priority: high : User reports that export to CSV silently truncates rows above 10,000. Reproduce the scenario, identify the code path responsible, and draft a fix description for the engineering team.", "callback url": "https://support.example.com/garudust/tickets", "session key": "ticket-8821" } Queue worker dequeue, จัดรูป task text, ยิง webhook หลาย ticket สามารถรันเป็น concurrent agent session พร้อมกันได้ session key คือสิ่งที่ทำให้ event trigger มีประโยชน์เกินกว่างานแบบ one-shot เมื่อคุณตรึง key ไว้ webhook call ทั้งหมดที่ใช้ key เดียวกันจะแชร์ conversation history ร่วมกัน หมายความว่า: ถ้าต้องการแยก session ออกจากกันสมบูรณ์ แต่ละ event เป็นอิสระ ก็ไม่ต้องระบุ session key — Garudust จะใช้ callback url เป็น key แทน ทำให้ได้ context ใหม่ต่อ callback target ที่ไม่ซ้ำกัน Webhook adapter คือ push target — ระบบภายนอกต้องเป็นฝ่ายเริ่มการเชื่อมต่อ ถ้าต้องการให้ Garudust ดึงข้อมูลจากแหล่งต้นทางเอง ตรวจ inbox, poll API, เฝ้าดูไฟล์ โดยไม่ต้องมี scheduler นั้นต้องใช้ cron job ที่คอย poll หรือรอ primitive watch /filter ที่ยังไม่มีในปัจจุบัน สำหรับ use case ที่เป็น push-based จริงๆ GitHub webhook, queue worker, calendar push notification, email routing service สถาปัตยกรรมปัจจุบันรองรับได้ครบและการแบ่งหน้าที่ก็ชัดเจนดีอยู่แล้ว