Practical Service Design for Agentic Workflows
In a course module, I wrote:
“Most abandoned tools fail because they’re added on top of existing habits instead of reshaping them. Without a shift in workflow and mindset, the tool is just another inbox to check, another distraction to maintain.”
Here’s what that means in my day-to-day practice—and how I’m designing agentic workflows that feel less like “new tools” and more like extensions of what I already do.
Where Tools Break for Me
- Voice unloads that go nowhere. If transcripts just sit in a folder, I don’t act on them.
- Extra dashboards. If I have to log in somewhere new to see tasks, I stop using it.
- Too much granularity. Tools that ask me to tag every little thing slow me down instead of helping.
- Context drift. When outputs live far away from where I’m actually working (GitHub, Obsidian, client docs), they get forgotten.
The friction isn’t technical—it’s workflow fit.
Service Design Applied to My Workflows
Instead of bolting tools on, I start with the rhythms I already rely on and shape agents around them. A few examples:
Daily voice unloads
- Current state: I talk for 10–15 minutes, GPT-5 structures the transcript.
- Design principle: Outputs land in Obsidian automatically, already tagged by theme.
- Why it works: I open Obsidian daily anyway, so the results live where I naturally review.
GitHub-driven builds
- Current state: Code and tasks live in repos.
- Design principle: Agents generate commit messages and draft issues right in GitHub Desktop or Issues—not a separate app.
- Why it works: I don’t leave my flow; the AI augments what I was already doing.
Client reporting
- Current state: I piece together updates from transcripts, task boards, and analytics.
- Design principle: Agents compile weekly summaries and surface them into the draft doc I’d send anyway.
- Why it works: The update feels like it came from my own process, not a foreign tool I have to remember to check.
Patterns I’m Leaning On
From these cases, a few practical service design patterns emerge:
- Anchor in existing rituals. If I already do it daily (voice unload, commits, weekly reports), agents attach there.
- Deliver into the tools I touch anyway. Obsidian, GitHub, shared docs—not new dashboards.
- Keep the plumbing invisible until it matters. I don’t need to see the orchestration, only the output. If something fails, then I want a clear log.
- Balance auto vs. review. For transcripts → Obsidian, full auto is fine. For client-facing text, I want a draft waiting for my approval.
Why This Matters for Me
I’ve abandoned plenty of tools because they sat next to my workflow instead of inside it. By reshaping the workflow with service design principles:
- My voice unloads become a daily archive I can trust.
- My code commits carry a clear history without extra effort.
- My client updates arrive with less friction and more clarity.
The agents don’t live off to the side—they live inside the rhythm of my work.
Closing Thought
Agentic workflows aren’t about adding tools on top—they’re about reshaping what I already do so the agents carry the load. If I have to “remember to use” a tool, it will fail. If it meets me in my rituals, it becomes part of the operating system. That’s the difference between another inbox and an actual workflow upgrade.