The Unsexy Way to Deploy an AI Agent

Samridhi Vig — Sat, 03 Oct 2026 08:53:59 +0000

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.

The options

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.

The Git problem

Consider an investigation agent.

It needs to:

read a ticket
inspect the codebase
search Git history
read markdown files
inspect recent commits
diagnose the issue
produce a report

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:

check out the repository
access Git history
run scripts
access CI secrets
install dependencies
run containers
call external APIs

And it already has a scheduler.

A real example

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.

When CI/CD isn't enough

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:

persistent state
specialised agents
parallel execution
complex retries
human approval
event-driven workflows
long-running execution

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.

My current approach

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.