Agent SDK Automation
Event-Driven Agents
Event-driven agents turn external signals into agent runs. Instead of waiting for a user prompt, the agent starts when a webhook arrives, a file changes, or a message queue delivers a job.
When to use event-driven agents
- A pull request is opened and you want an automatic code review.
- A ticket is created and you want the agent to investigate a repository.
- A monitoring alert fires and you want the agent to gather diagnostics.
- A file lands in cloud storage and you want the agent to process it.
Architecture
A typical event-driven deployment has three parts:
- Event source - a webhook, message queue, file system watcher, or pub/sub topic.
- Router - a lightweight worker that validates the event and starts an agent session.
- Agent - the Autohand SDK client that streams events and reports results.
The router should be stateless. It validates signatures, extracts identifiers, and hands the rest to the agent.
Webhook example
The following Cloudflare Worker validates a GitHub webhook signature and starts an Autohand agent to review the opened pull request.
File system and queue triggers
For local automation, watch a directory and start an agent when files change. For cloud deployments, consume a queue such as Cloudflare Queues, AWS SQS, or RabbitMQ. The pattern is the same: validate, extract context, run the agent, and acknowledge the message only after success.
Best practices
- Verify webhook signatures and authenticate queue consumers.
- Store event identifiers so you can deduplicate retries.
- Run agents in sandboxes when processing untrusted input.
- Return HTTP 200 quickly for webhooks and process the agent asynchronously if the work is long.
- Emit structured logs with the session ID so you can correlate events.