Everyone has an opinion about AI agents. Almost nobody publishes their actual production setup — the gateways, the MCP servers, the credential handling, the monthly bill. This is mine, as of August 2026, with real numbers and the failures included.
I run coding and automation agents daily for real work: this site, open-source tooling, and the automation that runs my infrastructure. Here's the stack, layer by layer.
#
The agents (division of labor) I don't use one agent for everything. Using the right tool per task is the cheapest optimization available:
opencode — my open-source coding agent for repository-scale work. Runs with a local provider config, executes code, verifies results. It's the workhorse for feature work where I want full control of the loop. #
Claude Code / Codex — used for sessions where their specific strengths apply (long-context refactors, or tasks tuned to their model families). I treat them as specialists, not a default. #
Hermes (Nous Research) — the automation layer.Cron jobs , scheduled pipelines, monitoring: things that run while I sleep and message me when they break. This is the agent that writes the drafts for this site, runs my infrastructure checks, and handles repetitive ops.
The rule I've landed on: a coding agent that runs unattended is an ops problem, not a coding problem. Which is why the layers below matter more than which agent you pick.
#
The gateway layer
Routing through gateways instead of calling providers directly is the single biggest sanity improvement. I use three:
OpenRouter — the default router for experimentation. The free tier covers low-stakes calls, and the model catalog means I can A/B test providers without touching config.OpenRouter -Merge — my main paid gateway. One API for the models I use daily, withcost tracking across agents. At $10/mo it pays for itself in what it stops me from overspending on direct API calls.Merge -Vercel AI Gateway — for the projects already on Vercel's stack. Its free tier ($5 of credits per 30 days) handles the low-volume path fine; I only reach for it when the project is already there.Vercel Why gateways and not direct API keys? Becauseevery agent that holds a direct provider key is a credential you're one prompt injection away from leaking. Gateways centralize the key, give you a kill switch, and make the bill auditable. This matters more than any model choice.
#
Credential handling (the part nobody writes about)
This is where most agent setups are a disaster waiting to happen. My rules:
Secrets live in pass / Bitwarden, never in agent context. Agents get credentials via an injection layer at runtime, not by reading a.env that sits in the repo.
2.
I maintain trustless — an open-source credential broker that serves secrets to agents through a local proxy, with DLP scrubbing and per-call authorization. It exists because I watched agents echo API keys into logs, chat history, and debug output. Once per week was too often.
3.
Long-lived keys are the enemy. Refresh tokens that rotate, short-lived sessions, and per-service keys scoped to exactly one tool. When a key leaks (it will), the blast radius is one service, one function.
#
MCP servers and tooling
The MCP layer is where the real leverage is. Currently running:
Filesystem + git servers — for agent access to repos without shelling out into the filesystem blindly #
Web search / fetch servers — the ones that make agents useful for research without hallucinating URLs #
Home-grown servers for my own infra — including a server that wraps my credential broker so agents can request secrets through a structured interface instead of me pasting them
The lesson: a well-scoped MCP server beats a prompt telling the agent to "be careful" every time. If the agent can't reach it, it can't break it.
#
Networking and self-hosted pieces
Tailscale — all agent access to my infra goes over the tailnet; SSH is not exposed publicly. Agents reach services by tailnet name, which also means thepublic attack surface is ~zero.Tailscale -Cloudflare — DNS, Pages (this site), Workers, and the edge layer. The free tier covers everything this site needs.Cloudflare -Qdrant + Mem0 — self-hosted memory/vector layer for the automation agent. Running my own instance means the agent's memory never leaves my server.Qdrant -vLLM — for the local models I run (a small Japanese-optimized model does embedding and light extraction work). Keeping boring inference local cuts gateway spend measurably.
#
The bill (real numbers) Monthly, as of this writing:
| Layer | Cost | | Gateways (Merge Pro + Vercel free tier + OpenRouter free) | ~$10 | | Cloudflare (DNS + Pages + Workers) | $0 | | Self-hosted infra (cloud free tiers, one cheap VPS) | ~$5 | | Total | ~$15/mo |
The trick is boring: route the expensive calls through the free tiers, self-host the repetitive work, and let the gateways absorb the variance. I've seen the same setup run $200+/mo when the routing is lazy.
#
What I'd change / what's broken
Context management is still the bottleneck. Long-running agents degrade; I still restart sessions more than I'd like. #
The agents occasionally fight each other — two automation runs touching the same state. File locking and job ownership markers helped, but it's not solved. #
Model quality is uneven across providers. The gateway makes switching cheap, but "cheap to switch" means I spend more time evaluating than I'd like.
The agent you pick matters less than the plumbing around it: gateway routing, credential hygiene, scoped MCP access, and a tailnet. Get those right and you can swap models and agents freely — which is exactly what you'll want to do, because this space moves monthly.
This is the first post in what will be a series on the details: MCP server design, gateway cost engineering, and credential handling for agents. If you're running agents in production too, I'd like to hear what your stack looks like.
*Disclosure: some links in this post are affiliate links — see [disclosure](https://agentjournal.dev/disclosure/).*
*Originally published at [agentjournal.dev](https://agentjournal.dev/blog/running-ai-coding-agents-in-production/).*