Last week I reviewed a project proposal. A database modernization engagement, Sybase to Postgres. A fairly common ask these days. What caught my attention wasn’t the scope or the timeline. It was a staffing model.

The proposal said: two data engineers for the first two months to build migration scripts, then a QA engineer joins in month three to test them. Classic. Sequential. Clean.

Except, this was supposed to be an agentic workflow.

If these agents can interact with each other in a multi-agent workflow, why does the QA engineer start at month three? In a human-centric project, that makes perfect sense, developers write the code first; QA tests it later. That’s the rhythm we’ve all worked on for decades. But if a validation agent can run alongside the conversion agent from day one, testing as it generates, why are we staffing the project like it’s 2019?

I’ve been observing this for a few days now, and to be honest, I’m doubtful if I’m being entirely fair to my team. It is genuinely hard to build real multi-agent workflows that collaborate autonomously, handle failures gracefully, and know when to escalate to a human. Technology is maturing fast, but it isn’t any magic. There are real reasons to be cautious.

But I feel there is something more to think about. Something that isn’t just a technology gap.

Every developer, QA analyst, and business analyst on my team now has access to some variants of Claude Code, Copilot, or Cursor. These are genuinely powerful tools. But I observe that their ability to use these tools to their full potential is constrained, not by the tools themselves, but by how they think about the work. They reach for the agent to complete a subtask. They review the output. They decide the next step. The agent waits.

The human is still the orchestrator of every micro-decision, functioning less like a strategic lead and more like a traffic cop, present at every intersection, approving every turn.

I want to say something that might be uncomfortable, because I think it’s real.

If you’re a developer and an agent can write migration scripts faster than you can, and another agent can test them, and a third can validate the results, it is a completely rational question to ask: what is my role here? That fear isn’t irrational. It isn’t laziness. It’s a legitimate question about professional identity in a paradigm that is changing faster than most of us have experienced in our careers.

And I wonder if that fear, unspoken, maybe not even fully conscious, is quietly shaping how teams design their workflows.

This is not because the project requires it, but because it feels safer as it keeps the human essential.

I don’t think this is an isolated problem. I suspect it’s playing out in teams everywhere, in product companies and IT services firms, in startups and enterprises, where developers are being handed out agentic tools and asked to rethink how they work.

So, I’m genuinely asking: is this a challenge you’re seeing in your team? Are your tech leads and developers designing truly agentic workflows, or are they building human-shaped processes and placing agents inside them? And if the fear of relevance is a factor, how are you addressing it?

I don’t have a clean answer yet. But I think naming the problem is the first step. The shift from “agents as tools” to “agents as collaborators” isn’t a technical upgrade. It’s a mindset change. And mindset changes are harder, slower, and more personal than any technology deployment I’ve ever managed.