Depot CI Says It Rebuilt CI for Agents. Here's Tenki's Take.

Depot launched Depot CI at KubeCon EU on March 24, 2026, with a bold pitch: CI was designed for humans, agents are faster than humans, so CI needs to be rebuilt from scratch. A week later, Kyle Galbraith (Depot's CEO) followed up with a deeper post outlining exactly why the mismatch between agent speed and CI latency is the biggest bottleneck in agentic engineering.

He's right about the problem. Agents push code in seconds. CI takes minutes to respond. The agent sits idle, burning tokens and time. That feedback loop is the critical path now.

Where we disagree is the solution. Depot's answer is: migrate to our new CI engine. Tenki's answer is: swap one label in your YAML and keep everything else.

Depot's thesis: CI is the bottleneck

Depot's framing is straightforward. Traditional CI systems assume a human pushes code, context-switches to something else, and checks back in ten minutes. That assumption breaks down when an agent writes code, commits, monitors CI, reads logs, fixes regressions, and pushes again in a tight loop. The agent doesn't context-switch. It just waits.

Galbraith's argument is that the speed of CI now directly gates the speed of development. A single engineer running ten agents simultaneously means ten branches all needing CI feedback at the same time. Queue times, cold starts, and per-job runtimes compound fast in that world.

This isn't a hypothetical scenario. Teams using Claude Code, Cursor, Copilot Workspace, and similar tools are already hitting this wall. The code gets written in seconds. The PR sits in CI for five to fifteen minutes. Multiply that across a dozen agent-driven branches and you've got a real throughput problem.

What Depot built

Give them credit: Depot didn't ship a wrapper around GitHub Actions. They built a genuinely new system. The core is something they call Switchyard, a durable function-based orchestrator with checkpoint replay and snapshotting. On top of it sits a frontend layer that currently speaks GitHub Actions YAML as its first syntax.

The feature set is aimed directly at agent workflows:

• Targeted reruns. Run a single job within a workflow instead of restarting the entire pipeline. An agent debugging one failing step doesn't have to wait for all fifteen steps to finish.
• Local patch execution. Run CI against uncommitted changes without pushing. The agent validates locally, then commits only when CI passes. No more commit-and-pray loops.
• SSH debugging. Drop into a running job mid-step via SSH. Agents (or humans) can inspect state, test fixes, and continue without starting over.
• API-first design. Trigger runs, poll status, pull logs, all via CLI or API. No dashboard clicking required.
• Per-second billing. $0.0001/second for a 2-vCPU sandbox. No one-minute minimums. Quick validation runs cost pennies.

This is real engineering work. The local execution model alone is something GitHub Actions simply can't do today. Depot has raised $10M (YC-backed), and they're clearly investing it in infrastructure.

The migration cost Depot doesn't advertise

Here's where the pitch gets complicated. Depot CI isn't GitHub Actions. It speaks GitHub Actions YAML, but your workflows run on Depot's orchestrator, on Depot's compute, through Depot's CLI. The migration command (depot ci migrate) copies your workflows from .github to a .depot directory with "compatibility fixes." That phrasing alone tells you the YAML isn't perfectly portable.

What you're actually signing up for:

• A new orchestration layer. Your CI no longer runs on GitHub's infrastructure. It runs on Depot's Switchyard engine. Every GitHub Actions action you use needs to work in Depot's runtime. Most will. Some won't. You'll find out in production.
• New CLI tooling. Triggering runs, checking status, pulling logs all go through the Depot CLI. Your team needs to learn it. Your agents need to be configured to use it. Your existing GitHub-native integrations (status checks, required checks, PR gates) may need rewiring.
• Platform dependency on an early-stage company. Depot is YC-backed and has $10M in funding, but they're still small. You're betting your CI pipeline on a startup's new product that launched weeks ago. That's a real risk calculation for an engineering leader.
• Two CI systems during transition. Depot suggests running both in parallel while you validate. That means maintaining two sets of workflow configs, two sets of debugging procedures, and two mental models for your team.

None of this is hidden, exactly. Depot's docs are honest about the migration path. But their marketing frames it as "a single command," which undersells the operational surface area.

Tenki's approach: same speed, no migration

Tenki solves the same speed problem Depot identified, but without asking you to leave GitHub Actions.

Tenki Runners are bare-metal-backed GitHub Actions runners. You change one line in your workflow YAML:

# Before
runs-on: ubuntu-latest

# After
runs-on: tenki-ubuntu-latest

That's it. Same workflow file. Same .github directory. Same GitHub-native status checks, PR gates, and required checks. Same Actions marketplace. Your team doesn't learn new tooling. Your agents don't need reconfiguration.

The speed gains are concrete. On real-world benchmarks published on Tenki's site: Citrea's builds run 67% faster, n8n runs 48% faster, Rust cargo builds run 40% faster. Across the board, Tenki reports 30% faster builds and 50% lower cost than GitHub's hosted runners.

At $0.015/min/core with 500 free minutes, you can test this on your own pipelines before committing. No CLI install. No new directory structure. No parallel CI systems.

Where Depot genuinely wins

I don't want to dismiss what Depot built. There are capabilities in Depot CI that Tenki's approach doesn't try to replicate, and for some teams they matter a lot.

Local patch execution is genuinely novel. Running CI against uncommitted changes before pushing eliminates a real source of friction. GitHub Actions has no equivalent. If your agents frequently push broken commits just to get CI feedback, this solves that loop directly.

Targeted job reruns save time and money. Rerunning just the failing job in a multi-step pipeline instead of the whole thing is something teams have wanted from GitHub Actions for years. Depot delivers it natively.

SSH debugging mid-job is useful. Dropping into a running CI job to inspect state interactively is a debugging superpower. It's especially valuable for complex integration tests that fail in CI but pass locally.

If you have the engineering bandwidth to evaluate and migrate to a new CI system, and these capabilities map to pain you're feeling today, Depot CI is worth a serious look.

Where Tenki is the lower-risk path

For most teams, the primary pain point in agentic CI isn't the absence of local patch execution or SSH debugging. It's that builds are slow and expensive. The agent pushes code, waits five minutes for CI, fixes the issue, waits another five minutes. The feedback loop is the bottleneck, and the feedback loop is slow because the runners are slow.

Tenki attacks that directly. Faster bare-metal runners cut build times, which cuts the feedback loop, which lets agents iterate faster. A build that took 12 minutes on GitHub's runners takes 4 minutes on Tenki's. That's not a rearchitected CI system. It's the same system running on better hardware.

The risk profile is fundamentally different:

• Rollback is trivial. Change the label back to ubuntu-latest and you're back on GitHub's runners. No migration tool, no directory cleanup, no parallel systems to decommission.
• No new toolchain. Your team keeps using GitHub's UI for logs, status checks, and PR integrations. No CLI to install, no new dashboard to learn.
• Full Actions compatibility. Every action from the marketplace works. Every workflow feature works. Service containers, matrix strategies, reusable workflows. Tenki runs GitHub Actions. It doesn't re-implement them.
• Incremental adoption. Switch one workflow to Tenki runners, benchmark it, then decide. You can run some workflows on Tenki and some on GitHub's hosted runners simultaneously without any configuration conflict.

The missing piece: closing the inner loop

Depot's blog post describes the ideal agentic CI loop: agent pushes code, CI runs fast, agent reads the results, agent fixes issues, repeat. But Depot only accelerates the CI execution part. What happens between "CI finishes" and "agent understands what went wrong" is still on the agent (or the human).

Tenki's Code Reviewer fills that gap. It's an AI code review layer that runs on every PR, posting context-aware review comments directly in GitHub. It catches bugs, logic errors, and regressions before the human reviewer even opens the PR.

Paired with fast runners, you get the complete agentic feedback cycle Depot describes: fast CI execution (Tenki Runners) plus automated first-pass code review (Tenki Code Reviewer). The agent pushes code, builds finish in minutes instead of ten, and review comments land immediately. The human reviewer gets a pre-screened PR with the obvious issues already flagged.

At $0.50 per review with 10 free reviews to start, it's low-risk to test on your own repos.

Picking the right path

Depot CI and Tenki solve the same core problem from opposite directions. Depot says: the CI system itself is broken, so we rebuilt it. Tenki says: the CI system is fine, the runners are just slow.

If you need local patch execution, SSH debugging, and programmatic CI orchestration via API, and you're willing to adopt a new CI platform to get them, Depot is a serious option. They've built something technically impressive.

If your primary pain is slow builds and expensive CI minutes, and you'd rather get faster feedback without changing your workflow, Tenki is the shorter path. One label change, same YAML, and your agents start getting sub-60-second feedback on builds that used to take five minutes. Add the Code Reviewer and you've closed the full inner loop Depot describes, without leaving GitHub Actions.

Most teams I'd talk to should try the zero-migration path first. If faster runners and automated review don't solve your agentic CI bottleneck, you'll know quickly, and nothing stops you from evaluating Depot CI after.