DEV Community

Cover image for Event Triggers บน Garudust
Garudust
Garudust

Posted on • Originally published at dev.to

Event Triggers บน Garudust

#rust #ai #agents #opensource

core ของ Garudust เปิดเผย primitive พื้นฐานตัวเดียว: agent.run(task) ทุก entry point — ไม่ว่าจะเป็นข้อความจากแชท, cron job, หรือ webhook call — ล้วนลงเอยที่ call เดียวกันนี้ทั้งสิ้น นั่นหมายความว่าระบบภายนอกใดก็ตามที่ส่ง HTTP POST ได้ ก็สามารถเป็น event trigger ให้ Garudust ได้เลย

บทความนี้จะอธิบายว่ามันทำงานอย่างไรในปัจจุบัน, pattern ที่ใช้งานได้จริงใน production และ use case ที่เป็นรูปธรรม

Webhook Adapter ทำงานอย่างไร

เมื่อ 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"
}
Enter fullscreen mode Exit fullscreen mode
Field Required คำอธิบาย
text ✅ Task prompt ที่ agent จะนำไปรัน
callback_url ✅ URL ที่ Garudust จะ POST คำตอบกลับมา
user_id optional ใช้สำหรับ role-based access control
session_key optional ตรึง conversation history ไว้; ถ้าไม่ระบุจะ default เป็น webhook:{callback_url}

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."
}
Enter fullscreen mode Exit fullscreen mode

HTTP response ที่ตอบกลับ POST ของคุณทันทีคือ 202 Accepted — agent ทำงานแบบ asynchronous

Security

Garudust ตรวจสอบ HMAC-SHA256 signature ทุก request ที่เข้ามา ตั้ง shared secret ใน config แล้ว sign ทุก POST ขาออกด้วย:

X-Hub-Signature-256: sha256=<hex(HMAC-SHA256(secret, raw_body))>
Enter fullscreen mode Exit fullscreen mode

Request ที่ไม่มี signature ถูกต้องจะถูกปฏิเสธด้วย 401 และ callback URL ที่ชี้ไป private IP (192.168.x.x, 10.x.x.x, localhost) ก็ถูก block โดย network guard ด้วย — agent ไม่สามารถถูกบังคับให้ call back หา internal infrastructure ได้

Core Pattern

การแบ่งหน้าที่ชัดเจนมาก:

ระบบภายนอก                   Garudust
─────────────────             ──────────────────────────
Event source (email,    →     Webhook adapter
  calendar, DB, queue)
Filter / match logic    →     โค้ดของคุณ (ก่อน POST)
Task description        →     agent.run(task)
Result handling         →     handler ที่ callback_url ของคุณ
Enter fullscreen mode Exit fullscreen mode

ระบบของคุณเป็นเจ้าของ filter — Garudust เป็นเจ้าของการรัน agent ทั้งสองฝั่งไม่จำเป็นต้องรู้โครงสร้างภายในของกันและกันเลย

Use Cases

1. Billing Email Monitor

บริการประมวลผลอีเมลคอยดักจับอีเมลจากผู้ส่งที่เป็นระบบ 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"
}
Enter fullscreen mode Exit fullscreen mode

Agent ใช้ tool ของมันอ่านไฟล์ expense report, เพิ่ม line item และโพสต์แจ้ง Slack บริการอีเมลทำแค่ match ผู้ส่งแล้วยิง — ไม่ต้องรู้อะไรเกี่ยวกับ expense report หรือ Slack เลย

2. GitHub PR Review Gate

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"
}
Enter fullscreen mode Exit fullscreen mode

webhook ของ GitHub ยิง workflow → workflow สร้าง task text → Garudust รีวิว และ session_key ที่ผูกกับเลข PR ทำให้ trigger ครั้งถัดไป (commit ใหม่, ขอรีวิวซ้ำ) ต่อเนื่องใน conversation thread เดิม

3. Database Anomaly Alert

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"
}
Enter fullscreen mode Exit fullscreen mode

Agent สามารถใช้ terminal หรือ database tool รัน query เพิ่มเติม, ตรวจ deploy ล่าสุด และสรุป incident แบบมีโครงสร้าง — monitoring job ทำแค่ตรวจ threshold breach เท่านั้น

4. Calendar External-Attendee Watch

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"
}
Enter fullscreen mode Exit fullscreen mode

Calendar integration เป็นเจ้าของ logic กรอง "external attendee" — Garudust เป็นเจ้าของการสร้าง briefing

5. Queue Worker Trigger

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"
}
Enter fullscreen mode Exit fullscreen mode

Queue worker dequeue, จัดรูป task text, ยิง webhook หลาย ticket สามารถรันเป็น concurrent agent session พร้อมกันได้

Session Keys และความต่อเนื่อง

session_key คือสิ่งที่ทำให้ event trigger มีประโยชน์เกินกว่างานแบบ one-shot เมื่อคุณตรึง key ไว้ webhook call ทั้งหมดที่ใช้ key เดียวกันจะแชร์ conversation history ร่วมกัน หมายความว่า:

  • PR review trigger บน commit 1 และ re-review trigger บน commit 2 คือ conversation เดียวกัน — agent จำสิ่งที่พูดไปก่อนหน้าได้
  • Incident trigger และ "ตอนนี้เป็นยังไงบ้าง?" ที่ on-call engineer ถามทีหลังใช้ context เดียวกัน
  • Billing session สะสม invoice ทั้งเดือนจากหลาย trigger ก่อนสร้าง monthly summary

ถ้าต้องการแยก session ออกจากกันสมบูรณ์ (แต่ละ event เป็นอิสระ) ก็ไม่ต้องระบุ session_key — Garudust จะใช้ callback_url เป็น key แทน ทำให้ได้ context ใหม่ต่อ callback target ที่ไม่ซ้ำกัน

สิ่งที่ Pattern นี้ยังไม่ครอบคลุม

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) สถาปัตยกรรมปัจจุบันรองรับได้ครบและการแบ่งหน้าที่ก็ชัดเจนดีอยู่แล้ว

Top comments (0)