The most useful question on an agentic engineering team is no longer “can you build this?” It is “which role are you in right now?” When the tasks are delegated, the value a human adds is not execution — it is the stance they take while orchestrating the work. The new core skill is moving cleanly between those stances, and knowing, at any given moment, which one you occupy. Call it role fluency.
It follows directly from the shift from tasks to roles: agents are sequential task-executors, but a person holds several roles at once and switches between them, often within a single hour. Fluency — not specialisation in one role — is what makes that switching reliable.
The roles, briefly
- Decomposer — turning an outcome into tasks an agent can actually execute (intent translation).
- Context designer — assembling the knowledge and constraints an agent needs to act well, not just plausibly.
- Evaluation designer — defining what “correct” means before the work runs.
- Reviewer and accountable owner — deciding what may enter the system, and owning that it did.
- Arbiter — making the trade-offs no specification can pre-resolve.
- Orchestrator — sequencing many streams of delegated work toward one outcome.
Most bad agentic work is a role error
Watch where agentic delivery actually goes wrong and you rarely find a model failure; you find a role confusion. Vibe coding is the canonical case: the agent writes the code, your role silently changes from author to accountable reviewer, and you keep acting like the author — skimming, trusting, shipping. The opposite error is just as common: reaching for the reviewer’s checklist on something you should have decomposed differently in the first place. The reviewer’s seat is also heavier than it was — DORA’s 2025 research shows time saved generating is reallocated to verifying, a verification tax that lands on whoever holds that role. Naming the role you are in is half the discipline.
Fluency, not specialisation
The instinct is to split the roles across people — a decomposer here, a reviewer there. It does not work, because the roles interleave per piece of work and per hour. The engineer who decomposes a problem is often best placed to design its evaluation and accept its result. What changes is the leverage: one person can hold the reviewer’s or orchestrator’s role across far more delegated work than they could ever have typed. Fewer task-hours, more role-hours, each carrying more weight.
The habit that separates the engineers who thrive with agents from those who drown is small and almost embarrassing to say out loud: they narrate the role they are in. “I’m decomposing now.” “I’m reviewing this, not writing it.” It sounds trivial. It is the single most reliable guard against shipping an unowned decision because you forgot which seat you were in.
Building it
For engineers: make the current role explicit, practise the switch, and learn to recognise the role error in yourself before it ships. For leaders: hire and grow for fluency, not raw output — and remember the apprenticeship that teaches these roles no longer happens by itself once the tasks are automated. Role fluency is learned the same way judgement always was: by doing the roles, under real stakes, with someone who already has it nearby.
The work that remains, once the typing is delegated, is a sequence of roles well played. Fluency between them — and the discipline of always knowing which one you are in — is the craft now.