Two engineering leadership roles landed in my inbox last month. On paper they had almost nothing in common.
One was at a company building an agentic workflow platform. They wanted someone who could redesign how engineering work gets done. Spec, plan, execute, verify. Agents as the default workers. The leader's job was to turn engineering into a set of autonomous loops that produce outcomes without a human in the middle of every step.
The other was at a company building context infrastructure for AI systems. Memory, retrieval, real-time state, the substrate agents use to think. They wanted someone who could make sure agents always had the right information at the right time. Low-level, high-performance, production-grade.
Different companies. Different stacks. Different pitches. I read both, filed them, and moved on.
A week later I opened them again and realized they were hiring the same person.
The stack they're both building toward
Once I saw it I couldn't unsee it. Both companies are building different layers of one system.
Context layer
↓
Agent reasoning and planning
↓
Execution layer
↓
Verification and feedback
↓
back to context
One company owns the top half. The other owns the bottom half. But the thing they're both really building is the loop. Context feeds reasoning, reasoning drives execution, execution produces results, results get verified, verification updates context, loop closes, loop runs again.
Neither job description says any of this out loud. They both describe their own layer and stop there. But the leader they want is someone who can see the whole loop and design into it, regardless of which half they're nominally responsible for.
What they're actually asking for
Both roles, underneath the different vocabulary, want the same six things.
Think in systems, not features. Not "build a feature." Design an autonomous system that produces outcomes reliably. The unit of work is no longer a ticket. It's a closed loop.
Own the full lifecycle end to end. Product, infra, architecture, code. Zero hand-holding. Strong opinions that turn into shipped systems, not strong opinions that turn into slide decks.
Treat AI as infrastructure, not tooling. The wrong framing is "use AI to help engineers move faster." The right framing is that AI is the substrate the work runs on. That changes every decision downstream.
Hold speed and correctness at the same time. One company is optimizing for speed of execution. The other is optimizing for speed of information. Both require verification layers that catch what the speed hides.
Have opinions about where agents are going. Not takes. Not theory. Opinions backed by systems you've actually shipped.
Be closer to a founder than a manager. Product ownership, technical ownership, commercial judgment, team leadership, all in one seat. Both roles describe this without using the word.
I've been that person before. It's what running Elements Software actually was. It's what building Fast Protocol has been. The only thing that's new is that the market has started hiring for it explicitly instead of pretending it's a normal engineering management role.
Why this is happening now
Agents flattened the middle layer of engineering orgs. You don't need three tiers of managers coordinating twenty engineers when five engineers running agents can ship the same work. The org chart compresses. The remaining seats get broader and deeper at the same time.
The people who used to split this work across a VP, a staff engineer, and a product lead now need to find one person who can hold all three. That person is rare. That's why the comp is climbing and the job specs are getting honest about what they actually want.
The second reason is harder to say out loud. Most companies don't yet know what an agent-native system looks like in their domain. They're hiring someone to figure it out, ship it, and be accountable for whether it works. That's not a management hire. That's a founding-engineer hire with a salary instead of equity.
What to do with this if you're reading job specs right now
Read past the surface. The title and the stack will mislead you. Look for the six things above. If you find four or more, the company is hiring for the new role whether they've named it or not.
Ask about decision authority before you ask about the tech stack. The roles that want founder-mode execution but don't give founder-mode authority are the ones that break people. I wrote about that dynamic a few days ago and I'll keep writing about it, because it's the thing most engineers don't ask about until they're already inside it.
And if you're the one hiring, say it out loud. Stop writing job descriptions that describe a layer when what you actually want is someone who can design across layers. You're not going to get the person you need by describing the person you used to hire.
The role changed. Most job descriptions haven't caught up. That's the opportunity, if you can see it early.