I've been building AI workflows that run locally.
Initially, I manually triggered them when something happened. Then I added cron jobs to run them at intervals.
That works, but eventually you want the workflow to run without you.
You don't want your laptop open. You don't want it consuming your personal AI API quota. And you don't want to be there to trigger it.
So I started looking at how to move these workflows to the cloud.
| Hosting approach | How it works | Pros | Cons |
|---|---|---|---|
| Managed agent platform | The AI provider runs the agent and execution loop | Built-in; little infrastructure | Vendor lock-in; requires giving the provider access to your code/systems |
| Headless agent + custom orchestrator | Run something like Claude Code headlessly and use ADK/LangGraph to orchestrate it | Minimal changes to an existing workflow | Not really using the orchestrator to its full potential |
| Rewrite in custom orchestrator | Rewrite the workflow natively in ADK/LangGraph | Full control; proper orchestration | Complete rewrite |
| CI/CD + scheduler | Run the existing workflow as a scheduled CI job | Almost no changes; existing repo, secrets and Git access | Not designed for long-running workflows |
My initial instinct was to use an agent framework.
But for repo-based workflows, CI/CD turned out to be a surprisingly good fit.
Consider an investigation agent.
It needs to:
Locally, this is easy. The agent has the repository and can just run:
git log
git diff
grep
find
cat
Move the workflow to a generic cloud runtime and suddenly you need to solve how the agent gets that context.
You can clone the repository, use Git APIs, download archives, build repository tools, etc.
But if the workflow is already in GitLab, the CI runner already has most of this.
It can:
And it already has a scheduler.
I built an internal investigation agent that periodically picks up newly triaged engineering issues, investigates the relevant codebase and Git history, and produces an investigation report.
My first instinct was to move the workflow into a dedicated agent runtime.
Instead, I put the existing workflow behind a scheduled CI pipeline.
The repository was already there. Git history was already there. The secrets and execution environment were already there.
Zero rewrite.
That experience changed how I think about deploying agentic workflows to the cloud.
I'm not saying CI/CD is an agent runtime.
It's a good fit when the workflow is:
start → investigate → finish
It's a different story when you need:
At that point, I'd consider something like ADK or LangGraph and rewrite the workflow around proper orchestration.
The CI/CD implementation can also be a transient solution. Get the workflow running first, then rewrite the internals later without necessarily changing the system that calls it.
I'm now thinking about this less as:
"Which agent framework should I use?"
and more as:
"What does this workflow actually need from its runtime?"
For a scheduled workflow that needs repository access, Git history, secrets and bounded execution, CI/CD may be enough.
For a complex multi-agent system with state and orchestration requirements, use an orchestration framework.
Don't introduce an agent platform just because the thing you're running happens to be an agent.
Sometimes the simplest cloud runtime is the infrastructure you already have.