If you're building anything with AI right now, you've felt the pull.
The demos are intoxicating. An agent that reads your codebase, understands the issue, writes the fix, opens the PR, and runs the tests. End-to-end. No human in the loop. Every conference talk, every product launch, every funding announcement pushes the same narrative: the future is fully autonomous AI agents across the entire SDLC. Planning agents. Coding agents. Testing agents. Deployment agents. Multi-agent orchestration. A fleet of autonomous workers, with engineers promoted to "managers of AI."
I'm not here to tell you that's wrong. Agentic AI works. I use it every day. But the more I build, the more I find myself asking one question: Does this workflow actually earn that level of autonomy?
I started noticing this while working on a research project — a codebase intelligence tool I've been building during weekends.
I was building the whole thing with Claude Code, and I got deep into making my own development process fully agentic. Spec-driven development with multiple agent personas, each one handling a different stage of the pipeline. One agent for planning, another for implementation, another for testing, another for review. I was designing agent handoffs, defining persona boundaries, and orchestrating the whole flow. Full agentic SDLC for a solo builder. It felt like the future.
But as I iterated, I kept finding that the steps that gave me the most value weren't the autonomous ones. They were the moments where I paused, looked at what the agents had produced, and made a judgment call — this coupling doesn't look right, this test is verifying the wrong thing, this approach misses a constraint I haven't written down anywhere. The insights that mattered most were the ones that needed a human to see them, not an agent to act on them.
I started pulling back. Instead of orchestrating a pipeline of agent personas, I moved toward semi-autonomous flows — where I choose what runs, when, and on which parts of the codebase. Defining the workflow boundary is itself an engineering decision.
That was the first hint. But I didn't fully trust it yet. So I tested the same idea in a completely different domain.
I built a Family OS and named it Jeeno! The idea was to turn our family Slack workspace into an intelligent home operating system using OpenClaw's multi-agent platform.
I built specialized sub-agents for cooking, kids' academic coaching, and family coordination. Set up cron jobs for daily activity suggestions, cross-channel memory so the system could connect a dinner discussion in one channel to a grocery run in another, and privacy boundaries so parent conversations never leaked into the kids' channels. I ran multiple models — Sonnet and Opus from Anthropic, Gemini 2.5 Pro, with fallbacks — and built background agents for summarization and context compaction.
It worked. That felt like magic. And then I looked at the economics. 😢
The workflows that worked well — recurring meal plans, weekly reminders, routine scheduling — were simple enough that a basic automation could have handled them. I didn't need a dispatch agent routing to a specialized sub-agent for a grocery list. I didn't need multi-model orchestration for a reminder.
The workflows that were complex enough to justify the architecture — coordinating a messy family week, handling exceptions, connecting context across channels in real-time — those worked sometimes, but the cost of running multiple models, maintaining the agent infrastructure, and tuning the system week after week added up. The orchestration overhead was real. The API costs across multiple model providers were real. And the return on investment, honestly, was negative.
I didn't kill Jeeno because it failed. I killed it because nothing in my household sat in the zone where multi-agent orchestration was the right tool. The simple stuff didn't need it. The complex stuff didn't earn it.
And here's the thing — my family still uses AI constantly. They just don't need my over-engineered system for it. Everyone has their own Claude account now, and they default to that instead of Jeeno. And I'd rather have my kids use NotebookLM over anything else at this point!
The only use cases I still haven't found a simpler replacement for are the emergent behaviors — Jeeno sitting inside our group chats, eavesdropping on family conversations, and connecting dots across channels that no single-user tool can see. That ambient awareness, plus the dream of a shared family knowledge base where everyone's learning compounds. I'm waiting for Claude's Cowork channels to roll out to Slack — that might close the gap entirely. But until then, those are the only pieces I genuinely miss. But the rest? Replaced by tools that already exist, without a single line of orchestration code.
That was the moment I started thinking about this as a tax.
The autonomy tax: the gap between what a workflow can be automated with and what it should be automated with.
Once I had that frame, I started applying it everywhere.
Before making anything agentic, I now sit with a set of questions:
- Is this a repeated workflow? If it runs once, automation is overhead. If it runs fifty times a day, the math changes. Frequency is the first filter.
- What's the blast radius of getting it wrong? Generating a test stub autonomously — low risk, easy to verify, and critically, cheap to discard. If I can throw away the output and nothing downstream breaks, the agent can run freely. But modifying a payment path, a compliance check, a service with undocumented SLA dependencies — where discarding isn't cheap, and downstream systems have already consumed the change — I'd rather have a human deciding that upfront, not just reviewing it after the fact.
- Is the context already machine-readable? If the agent needs tribal knowledge, undocumented constraints, or cross-system understanding that lives in a senior engineer's head, I'm not automating the task. I'm hiding the complexity behind a confident-sounding output.
- Does the human-in-the-loop version already work well enough? This one stings. Sometimes the manual version takes thirty seconds, and the automated version takes an hour to maintain. That was the Jeeno lesson in a sentence.
- What's the cost of the agent being confidently wrong? Not just compute cost. The time spent debugging autonomous output that looks right but isn't. Trust erosion occurs when a team stops believing the agent's suggestions because it got burned twice.
I've started running every potential workflow through these questions. Most don't survive. That's been humbling. I thought this was just my experience — a builder's intuition from two projects that pushed me toward the same conclusion. Then I found the research.
Anthropic published "Measuring AI Agent Autonomy in Practice" in early 2026, studying how developers actually use coding agents over time. Even after 750 sessions — power users who've built deep trust with the tool — more than half still keep humans in the loop. Auto-approve rates climb from about 20% for new users to around 40% for veterans. The people who know agents best still choose supervised autonomy. That's not a training wheels pattern. That's a revealed preference.
SWE-Bench Pro tells you why. When researchers tested coding agents on realistic, long-horizon tasks across diverse codebases, the best models stayed below 45% success. But when they removed human-provided requirements and interface specifications — when the agent had to figure out what to build, not just how to build it — success rates collapsed from 25.9% to 8.4%—a 70% drop. The compound math makes it worse. If each autonomous step has 85% accuracy — which sounds great — a 10-step workflow succeeds about 20% of the time. Every step you add multiplies the failure probability. This isn't a model capability problem. It's an architectural property of chained autonomous decisions.
I felt this with my spec-driven dev process before I had the numbers. The more agents I chained, the more I spent debugging the coordination rather than benefiting from the automation.
So, where have I landed?
I've stopped thinking in terms of "autonomous or manual" and started thinking in terms of a spectrum — where the right position is a per-workflow decision. Not per-company. Not per-team. Per-workflow.
- A greenfield prototype with no users? Let the agent run.
- A high-frequency migration task with sandboxed execution and automated verification? That's where autonomous agents genuinely shine — companies like Stripe and Ramp have proven this at scale.
- A payment processing service with regulatory constraints buried in its runtime behavior? I want a human at every decision point.
- A test suite for a stable utility library? Semi-autonomous, run it on a schedule, and review the output.
- A deployment pipeline for a service that handles PII? Human-gated, every time.
The skill I find myself developing isn't prompt engineering. It isn't agent framework selection. It's something I've started calling autonomy design — the habit of honestly evaluating each workflow against the questions that tell me whether it's earned the level of autonomy I'm tempted to give it.
Sometimes the autonomy tax — the overhead, the cost, the compound error risk, the negative ROI on automating things that weren't bottlenecks — exceeds the value of what you're automating.
The question I keep asking myself isn't "how do I make my agents more autonomous?"
It's "how do I get better at deciding what level of autonomy each workflow has actually earned?"
I'm still figuring it out. But I think the question itself is worth more than most of the answers I've seen so far.
Research cited: Anthropic, "Measuring AI Agent Autonomy in Practice" (2026). Deng et al., "SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks?" arXiv:2509.16941 (2025). Wang et al., "Position: Humans are Missing from AI Coding Agent Research." Mitchell et al., "Fully Autonomous AI Agents Should Not be Developed," arXiv:2502.02649.
Originally published on LinkedIn.