The Organizational Axis: Teams by Quadrant
Prerequisite: the 2x2 quadrant model from earlier in this course — this lesson assumes you can already place a layer of a system into Headless/Conversational and Stochastic/Deterministic without re-deriving the axes. After this lesson, you can: explain why one quadrant of the 2x2 produces a role, "conversation designer," that the other three don't, and state the AI Product Engineer's actual job description as a weighted split rather than "engineer who uses an AI coding tool."
Try to hire a "conversation designer" for an overnight research agent, and the job posting makes no sense: there's no conversation to design, no flow to hand off, nothing to separate from the engineering work. Try to hire one for a CALM-style chat flow, and it's an obvious, normal role that already exists at scale. Same underlying skill, wildly different fit, and the reason isn't the person, it's which quadrant the system lands in.
Every lesson so far in this course has treated the 2x2 as a technical decision: where does this layer of the system live, and what does that placement cost in latency, risk, and eval effort. That's true as far as it goes, but it undersells the model. The quadrant a piece of your system lands in doesn't just shape the code, it shapes the org chart. Who you hire to build it, who you hire to maintain it, and whether those are even the same person, are downstream of the same axes you've already learned. This lesson is short because the point is narrow: the technical choice is also an organizational one, and one quadrant in particular breaks a pattern the other three share.
Four quadrants, four different teams
Look at who actually builds and maintains each quadrant, and a pattern falls out that the technical framing alone doesn't show you. The table below is this course's own team-shape framework, drawn from watching teams build in each quadrant rather than a formal hiring survey — read it as a useful lens for staffing a system, not a market study to cite on its own:
| Quadrant | Who builds it | Who maintains it |
|---|---|---|
| Headless + Stochastic | A senior engineer comfortable with non-determinism, with a cost-engineering reflex and a security-first instinct | The same person: this quadrant does not delegate well |
| Headless + Deterministic | A backend engineer plus a data engineer, occasionally an LLM-extraction specialist | A standard data-platform team, run like any ETL pipeline |
| Conversational + Stochastic | A product-minded full-stack engineer, comfortable shipping and iterating | The same person, until the system is big enough to need real flows |
| Conversational + Deterministic | A conversation designer and a backend engineer, as separate roles | Separate roles, with a clear handoff: the designer owns the flows, the engineer owns the custom actions |
Three of the four rows collapse builder and maintainer into the same person, or close to it. The fourth doesn't, and that's not an accident of headcount. It's a property of the architecture itself.
Conversational + Deterministic is the only quadrant where "conversation designer" is a real role that employs real people. In a Rasa CALM deployment, the flows (the structured conversation logic, the slots, the business rules about what the agent asks and when) are a distinct artifact from the custom actions that implement them in code. That separation is what makes the role possible: you can hand the flow design to someone who understands the conversation without asking them to also own the backend, and you can hand the custom-action code to an engineer without asking them to also design the dialogue. Try to draw the same clean split in the Headless + Stochastic quadrant and it collapses immediately: an agent's planning loop, its tool selection, and its failure modes are too entangled to hand to two people with a typed interface between them. One person has to hold the whole non-deterministic core in their head, which is exactly why that quadrant "does not delegate well."
What the AI Product Engineer actually does
The organizational axis also answers a question this course has been circling since lesson one: what does the person who does this work all day actually spend their time on? Not "a software engineer who uses Cursor": that's table stakes, not a job description. The AI Product Engineer is the person who does five things, in this rough proportion — this course's own working breakdown from observing the role in practice, not a measured time-and-motion study:
Takes a brief, decomposes it into pieces, and decides which quadrant each piece belongs in. This is the 2x2 applied, over and over, to real work.
Types the boundary between quadrants: what state crosses, what latency is visible to a human, who's in the loop when something fails.
Writes the tests that tell the team whether the non-deterministic core is actually behaving, not just running.
Treats tokens and milliseconds the way a database engineer treats rows and locks: a resource with a price, not an afterthought.
Implements the pieces, iterates the prompts, wires the flows. An AI coding tool writes most of the actual text.
Ninety percent of the role is judgment (placing layers, designing handoffs, building eval loops, owning cost/latency), not implementation. Writing code is the smallest slice, not the job description.
Notice what's missing from the 90% that isn't "write code": none of it is a skill an API call teaches you. Placing layers, typing handoffs, and building eval loops are judgment calls, not implementation details, and that's the argument underneath the whole split. Knowing how to call a model's API is not the same skill as being an AI Product Engineer. The API call is the easiest and last step in the sequence; the four steps before it are the actual craft, and they're exactly the skills the rest of this course has been teaching under different names.
Why the role is priced the way it is
That split also explains why the role is priced the way it is. In 2023 the binding constraint on software engineering value was throughput: how much code a person could produce. AI coding tools compressed that cost close to zero; nearly anyone can now generate far more code than they could two years earlier. When throughput stops being scarce, it stops being what companies pay a premium for. What's left scarce is judgment: what to build, how to evaluate it, which quadrant each layer belongs in, where the trust boundary sits. That's not a claim about the role being harder than regular engineering — in some ways it's easier. It's a claim about where the bottleneck moved.
The 2x2 you've been using all course is, among other things, a judgment framework, which is why an organizational lesson belongs in a course about technical architecture rather than being a footnote to it: the axis you place a layer on determines the team you need to build and run it, and that team is not optional context. It's the other half of the decision.
The course closes: five exercises to run against your own backlog, the questions this material gets most often, and a further-reading list credited by name.
Reply here and it goes straight to Rod. Same as replying to one of his emails.
