Skip to content

The Talent Stack

Canon Beast edited this page Aug 24, 2026 · 2 revisions

The talent stack

Three roles. None of them is "prompt engineer", and the one everybody hires last is the one that decides whether any of it gets used.




The hiring mistake this page exists to prevent

A programme gets funded, and the first requisition says prompt engineer.


Six months later there are agents nobody trusts, no one who can say what should have been tested, and a business team that was never asked what "correct" means.


None of those are prompting problems, and the role that was hired cannot fix any of them.



Role 1 · The Agent Architect

Not a prompt engineer.


The Architect designs the state management, the tool integrations, and the failure paths. Those three, in that order, are what separates a demo from a system.


The discipline underneath the role is context engineering: what the agent knows, when it knows it, and how it forgets safely. The third one is the part that has no equivalent in ordinary software and no obvious owner if this role does not exist.


In a regulated environment the Architect also understands the data architecture well enough to route regulated data safely, which is a design responsibility rather than a compliance sign-off.


The test for this role: ask what happens when the third tool call in a chain fails. An Architect answers with a state diagram. A prompt engineer answers with a retry.



Role 2 · The AI Product Owner, the Translator

The domain expert who speaks both the operation and AI product management.


Usually a senior operations analyst in the domain who has learned enough about how these systems behave to write a meaningful golden dataset. Not a data scientist who has learned the domain. The direction matters, and it is the harder direction to fake.


They own the business outcome, not the code. They sign the risk charter.


Two things this role does that nobody else in the org can:


They write the golden dataset, which means they decide what "correct" means before the system is built. A golden set written by the team that built the agent tests whether it does what it does.

They are the reskilling path made concrete. This is the role the person whose work the agent absorbed can actually move into, which is why the Dignity Clause and the talent stack are the same conversation and not two.



Role 3 · The Guardian, the Red Teamer

The person whose job is to break the agent before production does.


They run the adversarial suite, read transcripts looking for confident wrong answers, and have the authority to block a deployment. The authority is the role. Without it this is a reviewer, and reviewers get overruled by dates.


The Guardian has to hold two heads at once:


The bad actor. Someone deliberately trying to make the system do something it should not.

The confused first-time user, under time pressure, at midnight. Who is far more common, produces stranger inputs, and is the one the demo never included.


Most red-teaming covers the first head and skips the second, which is why systems pass a security review and then fail in week one on somebody typing their question in the wrong box.



Where the three come from at the start

Before there is a CoE there is a small group, and the source material is unusually consistent about its shape: three people, cross-functional, deliberately outside the normal process.


Owns
The Architect The patterns
The Governor Security and the risk posture
The Builder Shipping the first agent

That is the same three roles above, compressed. The Guardian and the Governor are the same instinct at different scales; the Builder becomes the Architect once there is more than one agent to be consistent about.


Their job is to survive the pilot stage and prove value quickly, which means they are explicitly allowed to move faster than the eventual process will. That is a deliberate, temporary exemption, and the failure mode is forgetting it was temporary.



How the team scales, as ratios

The source gives a headcount table by maturity level. Headcounts do not transfer between organisations and ratios mostly do, so this is the shape rather than the numbers.


Role How it scales from first pilots to an optimised programme
Platform architect Grows steadily. Roughly one at the point of a real second agent, and a small team by the time the platform is shared
Agent engineers The bulk of the growth, and roughly four engineers per architect at every level. That ratio holds better than any absolute number in the table
Security and compliance Starts as a consultant, not a hire, and becomes a permanent role at around the point the first externally-facing agent ships
Enablement and training Starts at zero

That last row is the finding, and the source states it without comment.


Enablement is the last role funded and the first thing a programme needs, because adoption is what kills these programmes and adoption is the thing enablement owns. A team that hires four engineers before it hires anyone to help people use what those engineers built has decided, without deciding, that the hard part is the building.


Reading this table honestly: the ratios are worth carrying, the absolute numbers are not, and the row that reads zero is a recommendation nobody made on purpose.



The role everybody else's job turns into

The three roles above staff the function. The larger change is what happens to everyone the function touches.


The shift is from doing the work to supervising work that gets done. It is not a promotion and it is not a demotion. It is a different job with a different skill, and it arrives whether or not anyone plans for it.


Four responses, and only one of them is the one people fear:


What it means What it looks like
Redesign Change the workflow, not the headcount The agent resolves asynchronously; humans own the escalation path
Reskill New capability in the same person Operators become supervisors of the thing that replaced the task
Redeploy Move to higher-value work Out of retrieval and data-gathering, into investigation and judgement
Rebalance Adjust hiring, not staffing Attrition and a changed hiring forecast, rather than layoffs

Rebalance is the honest one and it is usually the real answer. It is also the one that requires deciding a year earlier than anyone wants to, because a hiring forecast is changed in advance or not at all.


Training someone to use AI takes half an hour. Training someone to supervise it is a practice, and it is the thing the enablement row funds.



From the practice canon. Developed through client delivery and refined in collaboration; the frameworks stated here are the author's own.

Clone this wiki locally