For a long time, the bottleneck in my blogging workflow wasn’t ideas — it was friction. I’d have a half-formed thought on a Tuesday afternoon, open my terminal, stare at a blank .md file, realize I needed to check the frontmatter schema, look up the right tag slugs, make the commit, push, watch the Vercel deploy, and by then I’d lost whatever momentum I had. The post would sit in a drafts/ folder until I quietly deleted it six months later.
I knew I needed to fix the process. What I didn’t expect was that the fix would end up being an AI agent with shell access.
What “Managed Agents” Actually Means Here
Claude has a feature called Managed Agents — essentially a way to configure Claude with a persistent system prompt, tool access, and a defined role. Instead of chatting with a general-purpose assistant, you’re talking to a collaborator that already knows your codebase layout, your writing style, and what it’s allowed to touch.
The key difference from just prompting Claude in a chat window is agency: the model can be given tools — bash, file read/write, git — and execute multi-step workflows autonomously. You describe what you want, and it figures out the steps. You’re supervising, not driving.
For my blog, that looked like this: I describe a post I want to write, Claude drafts it in the right format, writes it to the right directory, commits it with a sensible message, pushes to main, and Vercel handles the rest. One conversation, zero context switching.
Setting Up the Agent
My blog runs on Astro, hosted on Vercel, with content in src/content/blog/ and src/content/papers/. The repo is straightforward — no monorepo madness, no custom build scripts doing weird things. That made it a reasonable first target.
Here’s roughly how I wired it up:
Step 1: Define the system prompt. This is where most of the work lives. I wrote out my writing style (first-person, conversational, open with a story), the frontmatter schema for both content types, the directory layout, and what the agent should not do (no force pushes, no touching src/components/, no merging PRs without review). Think of it as an onboarding doc for a new contractor who happens to be extremely fast.
Step 2: Give it the right tools. The agent needs: file read, file write/edit, bash (for git operations and build checks), and optionally a web fetch tool for pulling paper abstracts or checking URLs. I scoped bash access tightly — it can run git, npm run build, and ls, but that’s about it.
Step 3: Test the handoff points. The hairiest part was making sure the agent understood when to stop and ask versus when to proceed. Publishing a post is low-stakes. Deleting a file is not. I added explicit instructions about confirmation thresholds and practiced a few dry runs before giving it real write access.
Step 4: Connect it to the repo. The agent runs in an environment with the repo cloned and git configured with credentials. In practice, I use a deploy key scoped to that single repo so a mistake can’t ripple out to anything else.
What the Workflow Looks Like Now
The actual experience is almost embarrassingly simple. I open a conversation with the agent and say something like:
“Write a post about my experience setting up Claude Managed Agents to automate blog publishing.”
The agent figures out this is a blog post (not a paper review), picks a title, writes the content in my voice, drops it in the right directory, does a quick sanity check on the frontmatter, commits with a message like feat(blog): add post on claude managed agents, and pushes. Vercel picks it up and deploys in about 90 seconds.
What I’m not doing: opening VS Code, remembering the tag format, running git add -A && git commit -m "...", watching the pipeline, realizing I misspelled something in the title after it’s live.
What I Learned (and What Still Trips Up)
The system prompt is everything. I rewrote mine three times. The first version was too vague and the agent made reasonable but wrong choices — like putting a paper review in src/content/blog/. The second version was too rigid and it kept asking for confirmation on things I didn’t care about. The third version found the right level of specificity: describe the intent behind each rule, not just the rule itself. “Put paper reviews in src/content/papers/ because they have a different schema and RSS feed” is more robust than just “put paper reviews in src/content/papers/.”
Idempotency matters. Early on I had a bug where running the same publishing command twice would create two files with slightly different slugs. Fixed it by having the agent check for existing files by title before writing. Simple, but easy to miss.
You still need to read what ships. The agent writes in my voice well enough that it’s tempting to just let it go. But I’ve caught a few instances where it confidently stated something slightly wrong about a paper, or used a metaphor that felt off. I review before I push, full stop. The agent handles the mechanical work; the editorial judgment stays with me.
Git history is actually nice. Every post has a clean, atomic commit with a descriptive message. My git log looks better now than it ever did when I was committing manually at 11pm.
Is This Worth It for You?
If you’re running a personal blog and already comfortable with AI tools, yes — the setup cost is maybe a few hours and the payoff is real. The friction reduction alone is worth it for me because I actually publish more.
If you’re running a team blog or something with editorial review cycles, this approach needs more guardrails — a PR-based workflow rather than pushing straight to main, some kind of review step baked in. The bones are the same, the permissions model just tightens up.
The bigger lesson isn’t really about blogging though. It’s about what becomes possible when you treat AI as a configured agent with a defined role rather than a generic chat interface. The system prompt is the product. Once I internalized that, a lot of other automation ideas started to look a lot more tractable.
Now if only it could handle the part where I second-guess every title for twenty minutes. That one’s still on me.