AgentRail - A local control plane for AI coding agents

Hey Product Hunt 👋

I'm Onyeka, and I've been obsessed with one problem: coding agents can write great code, but they can't close a ticket.

They miss CI failures. They don't know which issue to pick up next. They lose context on review comments. You end up babysitting them instead of letting them ship.

That's after spending a couple hours of your day setting this all up.

**The problem** 👀
Every agent integration I saw was the same: dump GitHub webhooks at your agent and hope for the best. Raw log walls. No structure. No routing. The agent burns context just parsing noise.

What we built ⚡
AgentRail is an open-source task lifecycle API that gives coding agents a real dev loop:
- 📥 GitHub Issues and Linear tickets become routable tasks automatically
- 🔁 CI results come back as structured summaries — not raw log walls
- 🔍 PR review comments are ranked by severity (blocking vs. advisory)
- 🔑 Per-agent scoped API keys — each agent only touches what it needs
- 🏠 Runs entirely locally, no account required

**How to try it** 🚀
npm install @agentrail-core/cli — that's it.

Completey free for self-hosted, contributions are more than welcome!

Agentrail is in the very early stages, and actually launched earlier than planned to make it for Vercel Day! So please, break it, roast the hell out of it, all feedback is welcome/

Would love to hear from anyone running Claude Code, Codex, or Cursor agents at scale. What's the first thing that breaks when you have more than one task running? 🙏

@AgentRail First off, props to the AgentRail team. This is a really thoughtful system, and the core idea is strong: a local control plane for coding agents with task lifecycle, scoped agent keys, event delivery, blocker handling, and GitHub workflow support. We tested `@agentrail-core/cli@0.1.3` in a Windows lab environment with a disposable GitHub repo. What worked well: - Local AgentRail lifecycle API worked cleanly with a redirected `AGENTRAIL_HOME`. - Agent auth was solid: scoped keys, rotation, rate limits, and permission checks behaved well. - Event delivery and blocker handling worked nicely for “agent needs user input” flows. - Direct GitHub adapter testing worked against a disposable repo: - created a PR - merged the PR - created a rollback PR A few things we ran into during testing: 1. GitHub submit wiring in the stock server runtime It looks like `buildRuntime` passes AgentRail’s `publicBaseUrl` into `GitHubSubmitAdapter` as the GitHub API base URL. In local server mode, that appears to point GitHub submit calls at the AgentRail server URL instead of `https://api.github.com`. 2. Ship/merge state persistence The GitHub merge operation itself worked, but `AgentTaskQueue.shipTask` did not appear to persist the final task state as `done` or retain the merge metadata without a small wrapper around it. 3. Windows runner command output The generated runner command uses POSIX-style syntax like: `source && cd && codex` On Windows/PowerShell, that needs a platform-specific version. Overall: really promising project. The architecture is solid, and several pieces tested better than expected. For our workflow, we’re keeping AgentRail in a lab/partial-adoption state for now, mainly because of the Windows runner command and the stock runtime/persistence issues above. With those tightened up, this could be very useful as a real multi-agent task control layer.

A local control plane for coding agents is a huge win for security-conscious teams. Does AgentRail support fine-grained permissions for what files an agent can actually modify?

Honestly, the babysitting part is the biggest bottleneck with coding agents right now. Most tools just dump webhooks and hope for the best. I am curious about how does the structured CI summary handle complex logs from something like a massive monorepo without losing the specific error context for the agent?

the webhook → raw json → custom parser loop is the part of agent infra i hate most. how heavy is the setup?