{"slug": "the-unsexy-way-to-deploy-an-ai-agent", "title": "The Unsexy Way to Deploy an AI Agent", "summary": "A developer deployed an internal investigation agent that periodically picks up newly triaged engineering issues, investigates the relevant codebase and Git history, and produces an investigation report by running the existing workflow behind a scheduled CI pipeline rather than adopting a dedicated agent runtime. The account argues that for bounded, repo-based workflows needing Git access, secrets and scheduling, CI/CD is often sufficient, while complex multi-agent systems with state and orchestration requirements warrant frameworks like ADK or LangGraph.", "body_md": "I've been building AI workflows that run locally.\n\nInitially, I manually triggered them when something happened. Then I added cron jobs to run them at intervals.\n\nThat works, but eventually you want the workflow to run without you.\n\nYou 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.\n\nSo I started looking at how to move these workflows to the cloud.\n\n| Hosting approach | How it works | Pros | Cons | \n|---|---|---|---|\n| **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 | \n| **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 | \n| **Rewrite in custom orchestrator** | Rewrite the workflow natively in ADK/LangGraph | Full control; proper orchestration | Complete rewrite | \n| **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 | \n\nMy initial instinct was to use an agent framework.\n\nBut for repo-based workflows, **CI/CD turned out to be a surprisingly good fit.**\n\nConsider an investigation agent.\n\nIt needs to:\n\nLocally, this is easy. The agent has the repository and can just run:\n\n```\ngit log\ngit diff\ngrep\nfind\ncat\n```\n\nMove the workflow to a generic cloud runtime and suddenly you need to solve how the agent gets that context.\n\nYou can clone the repository, use Git APIs, download archives, build repository tools, etc.\n\nBut if the workflow is already in GitLab, **the CI runner already has most of this.**\n\nIt can:\n\nAnd it already has a scheduler.\n\nI 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.\n\nMy first instinct was to move the workflow into a dedicated agent runtime.\n\nInstead, I put the existing workflow behind a scheduled CI pipeline.\n\nThe repository was already there. Git history was already there. The secrets and execution environment were already there.\n\n**Zero rewrite.**\n\nThat experience changed how I think about deploying agentic workflows to the cloud.\n\nI'm not saying CI/CD is an agent runtime.\n\nIt's a good fit when the workflow is:\n\n```\nstart → investigate → finish\n```\n\nIt's a different story when you need:\n\nAt that point, I'd consider something like ADK or LangGraph and rewrite the workflow around proper orchestration.\n\nThe 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.\n\nI'm now thinking about this less as:\n\n\"Which agent framework should I use?\"\n\nand more as:\n\n**\"What does this workflow actually need from its runtime?\"**\n\nFor a scheduled workflow that needs repository access, Git history, secrets and bounded execution, **CI/CD may be enough.**\n\nFor a complex multi-agent system with state and orchestration requirements, use an orchestration framework.\n\nDon't introduce an agent platform just because the thing you're running happens to be an agent.\n\nSometimes the simplest cloud runtime is the infrastructure you already have.", "url": "https://wpnews.pro/news/the-unsexy-way-to-deploy-an-ai-agent", "canonical_source": "https://dev.to/yeeehzus/the-unsexy-way-to-deploy-an-ai-agent-31al", "published_at": "2026-10-03 08:53:59+00:00", "updated_at": "2026-10-03 09:07:29.915636+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "mlops", "ai-tools"], "entities": ["GitLab", "Claude Code", "ADK", "LangGraph"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/the-unsexy-way-to-deploy-an-ai-agent", "markdown": "https://wpnews.pro/news/the-unsexy-way-to-deploy-an-ai-agent.md", "text": "https://wpnews.pro/news/the-unsexy-way-to-deploy-an-ai-agent.txt", "jsonld": "https://wpnews.pro/news/the-unsexy-way-to-deploy-an-ai-agent.jsonld"}}