trigger event → sandboxed agent run → code
Serverless agent graphs for coding.
A PR, Linear, or Slack event fires the trigger. Each run gets an isolated sandbox that executes your graph of custom agents end-to-end and ships the output back where work started. Every step streamed live, fully queryable after.
Build your own
Greptile
Full-context code review on every pull request.
Each of these is just a few nodes: a trigger, agents, version control. The difference is the agents are yours. Their instructions, skills, and tools are specialized to your codebase and your conventions, not a one-size-fits-all product you can't open up.
You are the team's merge doctor. Rebase onto the base branch, resolve conflicts preferring semantic intent over textual order, and never touch generated files. If both sides changed behavior, stop and describe the collision instead of guessing…
Agents that know
your codebase.
A custom agent is standing instructions, skills, and tools packaged under a name. Skills teach it your conventions, from commit style to how your modules are laid out. Tools define exactly what it's allowed to do: built-in actions like posting a PR review or replying in Slack, plus commands you author yourself.
Each agent also picks its runtime: which harness executes it and which model it thinks with, metered through the platform or running on your own Claude subscription. Define it once and drop it into any workline, as a pipeline step or live in a Slack session. Its knowledge, permissions, and runtime travel with it.
Agents that meet you
where you work.
Drop an agent into a Slack channel and talk to it like a teammate. It checks in when it starts, streams its progress as it works, and pauses to ask when a call is yours to make — then picks right back up with the whole thread in context.
Because it lives in the thread, it's multiplayer by default: anyone can jump in, steer it, or sign off with a ✓. No new tab, no lost context. The same custom agent that ships code in your pipelines is one @mention away.
@worklines add rate-limiting to the upload endpoint before we open the beta 🙏
On it — reading how the API middleware is wired up. I'll check back as I go.
Found the middleware chain. Adding a token-bucket limiter + tests, keyed per user.
make it per-org, not per-user — 100 req/min
Good call — re-keying the bucket on org.id at 100/min. Tests green, branch pushed.↳ Reply to keep iterating · ✅ approve → open a pull request · 🛑 stop
✅ Approved — next up: open a pull request.
Opened pull request #248: Add per-org rate limiting to uploadsgithub.com/acme/api/pull/248
Put your agents to work.
Wire a trigger to an agent and ship your first workline in minutes. Free while in beta.