This morning a conversation with an employee clarified something I have been writing toward for years. As I explained where his role was headed inside an autonomous engine we are building at Prospus, two role names surfaced with unexpected precision: Evolution Architect and Autonomy Engineer. I have written about these roles in theory, but today they showed up in practice. This post defines both, explains what the Autonomy Engineer actually does inside a running system, and reflects on what the transitional phase looks like when the engine is live and humans and machines are working side by side.

---

This morning I was in a chat with my head of marketing. He had questions about some of our new developments on the Growth Engine, the technology we are preparing to offer as a service through Prospus as we reorient it away from generic digital services toward practical AI transformation. As I answered them, I found myself explaining not just what we were building but where his role was headed inside it. The goal, I told him, was for him to eventually operate this engine as the human inside it while I moved on to build the next one.

That was when the conversation took a turn I want to share. Explaining that goal out loud, in a real operational context, forced me to define both sides of the relationship in terms I had not used this directly before. So I wrote:

Me = Evolution Architect. You = Autonomy Engineer.

I have been writing about these roles for a while now. But this morning, they stopped being theoretical.

What I have been building toward

I introduced the Evolution Manager concept in a post called The rise of the evolution manager. The argument there was that as organizations commit to autonomization, a new class of leader would emerge, not a manager in the traditional sense but someone who consciously advances an enterprise through defined maturity stages.

Then I went deeper in Evolution architecture: the skill of structured domain mapping. The Evolution Architect is the higher-capability version of that role, someone who does not just manage within a system but designs the system itself. Their core skill is breaking broad objectives into artifacts, activities, and goals, then launching and orchestrating multiple initiatives in parallel.

That is what I do. I decide what gets automated, design the architecture, build the engines, and decide what stays human, and in what sequence. But I had not yet named the role on the other side of that relationship clearly enough.

What an Autonomy Engineer actually does

The traditional role is well understood. You receive requirements, ybuild to spec, and hand it back. The Autonomy Engineer is something different. The machine is no longer just a product being built. It is a running system producing output, and the Autonomy Engineer is the human inside that system whose job is not to build in the traditional sense but to operate in a new one.

In this morning’s conversation I outlined four responsibilities for this role.

1. Load your knowledge into the engine. The engine only knows what it has been given. A domain expert sitting beside a growth system who never transfers their knowledge into it is wasted leverage. The Autonomy Engineer finds every place where their expertise should be encoded and puts it there.
2. Influence the engine. An engine is not static. It has levers: keywords, targeting parameters, content frameworks, distribution logic. The Autonomy Engineer learns where those levers are and moves them based on analysis, not instinct alone.
3. Find where it is lagging. The Autonomy Engineer does not wait for a report to tell them something is off. They are close enough to the engine to feel it, to notice what the engine cannot see about itself and surface it before it becomes a problem.
4. Be the human in the loop. The engine runs, the human watches, corrects, and reports back to the architect. This includes surfacing gaps the engine cannot close on its own and requesting new features or additions when the system needs to evolve. This is not passive oversight but active participation in keeping a live system calibrated and pushing the architect to improve it.

None of this requires waiting to be told what to do. It requires understanding the engine well enough to know where it needs you.

This is what the transitional phase actually looks like

In May 2025 I wrote in Building the workforce of 2026: the agent protege program that the transition was coming, that every worker would need to adopt AI tools, document how they use them, capture what works, and build up a practice over time.

That was early. The transitional phase I described then was about adoption. What I am living now is the phase after adoption. The engine is built and running, and the question is no longer whether to use AI but how humans and engines work side by side when the engine is actually responsible for producing results.

I am the architect. My head of marketing is the engineer inside our Growth Engine he stewards on behalf of our clients. We are all operating inside the same system at different levels of abstraction. I will be building engines for every division, and as I do, this becomes my live case study for what it actually takes to develop an Autonomy Engineer. This is not a role that exists yet in any job description or HR system. It is emerging as the machines go live, and the only way to define it properly is to watch it develop in a real operation and document what it requires.

Two roles, one transition

The Evolution Architect designs the system, determines the phases, the sequencing, the engine architecture, and the correction logic, and operates at the level of the whole. The Autonomy Engineer operates inside the system, loading knowledge into it, finding its gaps, moving the levers that influence it, and keeping the human judgment layer functioning while the automated layer scales.

Both roles are new and neither maps cleanly onto anything that came before. The Evolution Architect is not a CTO or a strategy consultant. The Autonomy Engineer is not a traditional developer or a data analyst. They are what the transitional phase requires.

This will not be the last post I write about this. The process of developing this role in a live operation is going to teach me a great deal about what it actually demands, and I intend to document all of it. If you are watching your own team navigate this same transition, the question I would leave you with is this: who in your organization is learning to operate inside the machine, and who is still waiting to be told what to build?

---

Related reading: The rise of the evolution manager | Evolution architecture: the skill of structured domain mapping | The software company of the future is an Evolution Partner | The AI agent illusion: why alignment comes before acceleration and autonomy