Automations
Coding agents that start before you ask
Put Hoplite on a schedule, or wake it when something happens in GitHub, Sentry, Linear, Slack or a webhook. Every run is an ordinary thread your team can open, steer and review.
Definition
What Is A Coding Agent Automation?
A coding agent automation is a prompt with a trigger. When the trigger fires, an agent starts work in your repository without anyone typing the request, whether that's a nightly check, a new Sentry issue or a failed CI run.
In Hoplite, an automation belongs to a project. Each run creates a thread with the automation's prompt and the event that fired it, runs in its own sandbox like any other thread, and can open a pull request. Everything it does stays visible to the workspace.
On a schedule
Every Morning, Every Hour, Every Friday
Pick every hour, every day, weekdays, chosen days each week, a fixed interval, or write your own cron expression. Schedules run in the timezone you set, and the editor shows when the next run will start.
When something happens
Triggered By The Tools You Already Use
Start runs from GitHub pull request and CI events, Sentry issues and regressions, Linear issue changes, Slack messages or reactions, finished Hoplite threads, or any request to the automation's webhook URL. Filters on the event data decide which ones count.
Every run is a thread
Runs You Can Open, Steer And Review
A run starts a new thread with the prompt and the triggering event, marked as untrusted data, using the automation's model or the project default and an optional spend limit. It can also post into a pinned thread instead, and Sentry keeps one thread per issue.
Start from a template
A Working Automation In One Click
Begin with a daily digest, issue triage, dependency patrol, or Sentry alert triage, which runs a five-whys root-cause pass, fixes the problem, opens a pull request and updates the Sentry issue. Edit the prompt and triggers to fit.
Comparison
Cron Script Vs. Hoplite Automation
| Question | Hand-rolled cron script | Hoplite automation |
|---|---|---|
| What runs | A fixed script you maintain | A coding agent with your repository in a sandbox |
| Triggers | A timer, plus glue for anything else | Schedules, GitHub, Sentry, Linear, Slack and webhooks |
| Output | Log lines somewhere | A thread with the diff, tests and pull request |
| Duplicate events | Whatever you remembered to guard | Repeat deliveries don't fire twice |
| Runaway loops | Possible | No self-triggers, chains stop after 16 hops |
| Control | Edit the crontab and redeploy | Run now, pause, and a run history |
FAQ
Automations, Answered
- What can trigger an automation?
A schedule; GitHub pull requests being opened, updated, closed, merged or getting changes requested, and failed CI checks; new or regressed Sentry issues; Linear issues being created, changing status or getting a label; Slack messages or reactions; a Hoplite thread finishing; or a request to the automation's webhook URL.
- Can an automation open a pull request?
Yes. Each run is an ordinary coding thread, so it can do anything a thread can, including opening a pull request. Whether it does is up to the prompt.
- Who can create and edit automations?
Workspace owners, admins and members can create, edit, run and delete automations. Viewers can see them but not change them.
- What happens if the same event arrives twice?
Repeat deliveries of the same event don't start a second run. Automations also can't trigger themselves, and chains of automations stop after 16 hops.
- What if a run fails to start?
It is retried for up to 30 minutes. If the workspace is out of credits, the automation backs off for an hour before trying again.
- Can I test an automation without waiting for its trigger?
Yes. Use Run now on the automation's page, and pause or re-enable it from the same place. The run history shows each run's thread, status and duration.
Let the agent take the first shift
Connect a GitHub repository, pick a template and turn it on. Try Pro free for 14 days.