Hoplites series, Part 1 of 3: Why we built it

From March roughly 15% of all merged pull requests at Paxos have started with someone dispatching a hoplite, our one-shot cloud-based coding agent. Over 2,000 pull requests, with just over half of those being merged, spread across more than 20 repositories. The whole thing was built in under a month, and on a per-PR basis costs us 5x less than an engineer running the same task locally with an AI assistant.

Hoplites are our trusty cloud-based agents to execute grunt work - the name inspired by the ancient Greek footsoldiers of Leslie Lamport’s Paxon (our company’s namesake), because of course every council attempting to get consensus needs their grunts to do the real work! But seriously, Hoplites has changed the way we think about collaboration cross-function, shifting from backlogs of tickets to real pull requests being shipped rapidly by technical and non-technical teammates alike. 

This is the first in a series of blogs covering how agentic engineering is reshaping how we ship products at Paxos, this first post covering what Hoplites can do and why we built it.

How hard can it be?

We saw a handful of other companies (Stripe’s Minions, Ramp’s Inspect and Spotify’s Honk just to name a few) ship one-shot agent platforms, and knew we needed our own cloud-based agents immediately.

Across all four, the same patterns showed up: Slack as the universal entry point, pre-warmed ephemeral sandboxes, async fire-and-forget that produces PRs, human review as the merge gate, directory-scoped context files (CLAUDE.md / AGENTS.md), bounded CI retries, and MCP as the tool-integration standard.

We first looked hard at buying, when we evaluated the offerings back in March (Anthropic’s Claude Slack adapter, Cursor Agents, GitHub Agent HQ) we found various limitations, ranging from lack of self-hosting preventing the agent from running our testing stack to lack of extensibility meaning we couldn’t build the slack-rich experiences we wanted. Things have come a long way in the months since, with Cursor shipping cloud agents and Anthropic Claude Tag, which we’re currently re-evaluating. 

However, in the new world of AI - building it ourselves turned out to be a lot cheaper and allowed us to customize the tooling exactly to our requirements and iterate fast. We also had a head start: an earlier Slack bot that handled small frontend tasks in our admin web app. It was a single-process, single-repo prototype that nonetheless proved the loop worked. 

We decided to build, the first Hoplites MVP was running end-to-end within a week and a key cornerstone of the design was to keep the agent execution platform swappable, but own the interfaces (slack, cli) so if in the future we do choose to buy we’d make that migration easier and keep a lot of the handy tooling we’ve built on top of those interfaces. 

Kicking off a hoplite

Paxos lives in slack, it’s where ideation, feedback and deep technical and product discussions often begin - we knew Hoplites had to have a slack interface - where it has full visibility into that context. 

Hoplites is conversational, so simply @hoplites in a thread with a task, and the bot creates a job, claims a worker, and streams its progress back into the same thread - to continue with the conversation simply continue in the thread, like the conversation below.

Example Slack interaction: freeze deploys on identity-api

What we’ve found really powerful is pulling in additional context from the thread, spawning a Hoplite in an existing thread will pull in that thread to the agent’s context - we liked this so much we even gave the ability to pull in latest channel history for additional context, this is what really makes the tool so powerful - the user doesn’t need to point their local agent to the correct thread or attempt to curate the context themselves.

Steering, Planning and Scheduling

We also wanted much of the same features that come out-of-the-box with local agent platforms, so we asked Hoplites to self-improve and build in steering, planning and scheduling.

Steering gives us the ability to provide additional context to an already running agent, it’s as natural as following up directly in thread

Mid-flight nudge in Slack

Planning is as simple as prompting the agent to create a plan, Hoplites will create a draft PR with the plan document and come back directly in slack asking any follow up questions and give you the ability to submit and execute.

Hoplite responded with question in Slack

Scheduling directly in slack has been a huge unlock for building repeatable loops that are visible to everyone in the team, simply providing options directly in slack to start a schedule and Hoplites will automatically be re-triggered with the same prompt on the cron schedule specified. We’ve found this to be super powerful for things like recurring dead-feature flag audits or compiling full reports of alerting monitors (including raising PRs to auto-tune noise away) for the previous period.

Zero-touch green PRs

Opening a PR is not the finish line. A green CI run is. An agent that hands off a red PR and walks away isn't much better than an autocomplete with extra steps; the whole point of a one-shot agent is that the output is done. So we gave Hoplites the ability to automatically dispatch a follow-up fix job in the same conversation, with the failing check names, log URLs, and repo-specific debug guidance attached to the prompt. 

Pending PR checks with Skip PR Autofix button

This is really the piece of magic that makes this tool truly useful and allows for non-engineers to actively contribute.

Next in this series: we dig deep into our key workflows using hoplites, how we get a broad range of non-technical members of the team contributing and what loops we’re finding work at Paxos.

If you like these kinds of problems, you might like working with us: Paxos Careers.