Chapter 13 — Teams and Operating Models for Agentic AI

TL;DR

Agentic AI fails without the right people, roles, and operating rhythms; models and scaffolds are necessary but not sufficient, because ownership, evaluation discipline, and governance make the difference between a demo and a durable capability.
Every agent needs a cross-functional pod (product owner, agent architect, evaluation engineer, UX designer, governance partner, ops/SRE) working alongside a central platform team that provides shared model access, scaffolds, guardrails, and evaluation infrastructure.
Expect a productivity J-curve: early investment in workflow redesign, upskilling, and change management pays off later, and the jagged frontier of model capabilities means teams must treat delivery as frontier-mapping through deliberate experimentation.
Org patterns (hub-and-spoke, federated CoE, embedded teams) should evolve with maturity from ad hoc pilots through repeatable, integrated, and optimised stages, while avoiding anti-patterns like AI lab theatre, shadow AI, and single-hero engineer teams.
Sustainable capability comes from embedding evaluation and governance into the daily delivery cadence, upskilling existing staff (domain SMEs into product owners, SDETs into evaluation engineers, SREs into AI-aware ops), and treating each agent as a long-lived product with a backlog, lifecycle gates, and a living AI dossier.

13.0 From Projects to Capabilities

13.0.1 Why teams and operating models matter now

By the time you reach this chapter, you have seen agentic AI from almost every technical angle. Chapter 4 covered scaffolds and inner loops for structuring behaviour. Chapter 5 introduced harnesses and observability for repeatable tests, replays, and traces. Chapters 6 and 7 dealt with evaluation—metrics, judges, datasets, CI gates, canaries, and playbooks. Chapter 8 covered optimization. Chapter 9 provided best practices for prompts, tools, context, memory, and orchestration. Chapter 10 focused on UX for agentic applications. Chapter 11 walked through the journey from prototype to production. Chapter 12 established governance, policy, and lifecycle frameworks.

The missing piece is people. Who does all this? How do they work together? How does the organisation evolve from a string of pilots to a repeatable capability?

Most organisations start with isolated wins. They build a one-off HR Leave agent that partially automates leave policy questions. They deploy an Invoice triage agent as a pilot. They run a Contact Centre summarisation agent in one business unit.

Without the right teams and operating model, these stay as "cool demos." There is no owner when policies change. No one maintains harnesses and evaluation datasets. Ops teams lack visibility or on-call processes. Governance is a PowerPoint, not a working system.

Agentic AI demands ongoing stewardship. Models drift and tools change. New regulations appear. Attack surfaces evolve through prompt injection and data exfiltration. UX expectations rise as users get used to the agents.

This chapter is about baking in the roles, skills, rituals, and structures that make agentic AI a durable capability across HR, IT, Finance, Legal, Contact Centre, and beyond.

Callout 12.1 — Expect the J-curve (plan for the dip)

In many organisations, the first wave of AI adoption produces a paradox. Spend and effort rise, while measured productivity looks flat or even worse. Economists describe this as a productivity J-curve for general purpose technologies. Early investment goes into intangibles like redesigned workflows, new skills, and new ways of organising work. Those benefits do not show up immediately in standard output metrics. Later, when the complements are in place, gains compound and the curve turns upward. [R12.1] [R12.4]

What this means for agent programmes:

Treat "low utilisation after initial excitement" as a signal to improve complements, not just as a model problem. Focus on workflow integration, trust, and incentives. Budget explicitly for non-model work such as change management, enablement, evaluation engineering, tool hardening, and governance operations. Measure the right thing—track end-to-end cycle time, rework, escalation rates, and oversight burden, not just "tokens used" or "prompts shipped." Avoid pure cost-cutting strategies in the early phase. Evidence suggests market expansion and new services can attenuate the initial dip compared to narrow cost leadership strategies. [R12.4]

Callout 12.2 — The jagged frontier (there is no instruction manual)

Teams often assume AI capability is smooth and predictable. Hard tasks fail. Easy tasks pass. In practice it is jagged. Models can be excellent at one form of reasoning and surprisingly bad at a nearby variant. The boundary is not visible until you try. Mollick describes this as the jagged frontier and argues that there is effectively no instruction manual. You only learn what is inside or outside the frontier through repeated use and deliberate experimentation. [R12.5] [R12.13]

Operating model implications:

Treat early delivery as frontier mapping, not just feature building. Make experimentation safe by using sandbox environments, synthetic data, and shadow modes before broad rollout. Convert discoveries into assets such as golden cases, red-team suites, tool contracts, and runbooks. Institutionalise learning. "What we learned about the frontier this month" should be a standing agenda item in portfolio reviews.

13.0.2 Anchor: agents as long-lived products, not one-off PoCs

The key mental shift:

Treat each agent (HR Leave, IT Service Desk, Invoice Approval, Contact Centre Triage, CRM Co-pilot, Contract Review, Scheduling) as a product, not a project.

This implies four things. First, each agent needs owners—someone ultimately accountable for the behaviour and outcomes of the agent. Second, each agent needs backlogs that include not just feature stories, but evaluation stories, harness improvements, safety tasks, and UX refinements. Third, each agent follows a lifecycle: idea → pilot → production → continuous improvement → retirement (Ch12.1). Fourth, each agent maintains an AI dossier with tests, metrics, risks, and governance artefacts (Ch12.2–11.4).

No single team can do all of this. The pattern that consistently works combines two elements. Stable, cross-functional domain pods (such as an HR Leave squad or Contact Centre squad) own specific agents end-to-end. A central platform team builds and runs shared capabilities including model access, scaffolds library, harness infrastructure, logging, guardrails, policy-as-code, and evaluation tooling.

The rest of this chapter unpacks the roles in those pods and platforms, their collaboration modes, and the org patterns that sustain them.

13.0.3 Learning objectives

By the end of this chapter, you should be able to:

Design a minimum viable team for an agent product, including ownership for evaluation, UX, ops, and risk.
Translate the Chapter 2 and Chapter 4 layer split (scaffold, runtime, orchestrator, harness) into clear responsibilities and handoffs.
Embed evaluation and governance into day-to-day delivery so they stay current as policies, tools, and models change.
Choose an org pattern (hub-and-spoke, federated, embedded) that fits your maturity, regulation profile, and portfolio size.
Spot the common org anti-patterns that cause agent pilots to decay.

13.0.4 Ownership map: who owns which layer and artefacts

Chapter 2 and Chapter 4 decomposed an agent into distinct engineering layers. In practice, that decomposition becomes a team interface.

Layer or artefact	Primary owner	Supporting roles	What "good" looks like
Scaffold (inner loop)	Agent architect / lead engineer	Product owner, conversation designer	Bounded behaviour, explicit checkpoints, predictable tool use, traceable reasoning
Runtime (auth, retries, sandboxing, tool safety)	Platform engineer, SRE	Security, governance partner	Safe execution defaults, policy enforcement at boundaries, reliable fallbacks
Workflow orchestrator (durable long-running cases, SLAs)	Backend engineer / platform	Product owner, ops	Clear state model, timeouts, escalation paths, audit trails
Harness + evaluation assets (golden sets, red-team suites, scorecards)	Evaluation engineer	SMEs, platform, safety engineer	Repeatable suites, meaningful thresholds, drift detection, regression on incidents
AI dossier + evidence pack	Product owner, governance partner	Evaluation, security, ops	Always up to date, maps tests to risks and gates, supports audits and sign-offs

13.1 Roles and Skills for Agentic AI

13.1.1 Core product and technical roles

These are the people closest to the agents as products and systems.

Agent / product owner (per domain)

For each domain (HR, IT, Finance, Legal, Contact Centre) you want a dedicated agent product owner. This person defines and prioritises outcomes such as reduced handle time, fewer escalations, and faster approvals. They curate and refine the scope of the agent, deciding which sub-tasks it should and should not attempt (see Chapter 3's "select right problems"). They translate domain policies and workflows into user stories, test cases, and evaluation rubrics (connected to Ch6–7). They own the agent's AI dossier and lifecycle gates (Ch12). They decide when to expand capabilities, when to tighten guardrails, and when to roll back.

Think of this as a hybrid of product manager and domain SME. You do not need them to tune models. You need them to design useful, safe behaviour and make trade-offs.

Agent architect / lead engineer

This role sits at the intersection of product, architecture, and implementation. The agent architect chooses and designs the scaffolds for each agent (ReAct, Plan–Execute, Manager–Worker, etc.). They decide on tooling boundaries—what should be done via tools, what via retrieval, what by the LLM directly (Ch4 and Ch9). They design multi-agent orchestration where needed, for example when an HR Leave agent calls a Scheduling agent. They align with central platform patterns for logging, configuration, and guardrails. They perform senior code and design reviews focusing on safety and observability as much as correctness.

They need deep familiarity with the inner loop (runtime behaviour) and how the outer loop (evaluation, improvement) feeds back into the design.

LLM / tool engineers

These are the hands-on builders. They implement RAG pipelines, including retrieval patterns and evaluation (Ch4, Ch6–7, and Ch9). They integrate tools (APIs, databases, workflow engines) into agent scaffolds. They optimise latency, throughput, and cost (Ch11.4). They implement guardrails such as schema validation, output constraints, and policy checks. They work with evaluation engineers to instrument spans and traces (Ch5, Ch11).

Depending on team size, this might be one role or split into an LLM engineer (prompts, scaffolds, evaluation integration) and a tool integration engineer (APIs, back-ends, security boundaries).

13.1.2 Data, evaluation, and safety roles

Agentic AI lives and dies on data quality, evaluation discipline, and safety practices.

Data engineer / data product owner

The data engineer curates policy corpora such as HR manuals, IT procedures, legal templates, and contact centre knowledge bases. They design and maintain vector stores and indexing strategies for agent retrieval. They govern data access patterns—who can see what, what goes into embeddings, and redaction rules (link to Ch12 risk and privacy). They publish data products (e.g., "HR Policy Knowledge Base") with SLAs and quality metrics.

In many organisations this is a step toward data mesh thinking. Each domain pod owns data products their agents rely on.

Evaluation engineer

This role connects directly to Ch5–7. The evaluation engineer builds and maintains harnesses for each agent (offline and online). They design and implement metrics covering task success, safety scores, latency, cost, and UX proxies. They orchestrate LLM-as-judge flows, rule-based checks, and where needed, human review. They curate golden sets, red-team suites, and simulation scenarios. They work with platform to ensure evaluation is integrated into CI/CD (§13.3.4).

Think of them as the test engineer or SDET of the agentic world, but with a focus on behavioural and safety evaluation, not just code coverage.

Safety / red-team / security engineer

Their job is to break your agents safely before the world does. They conduct regular red-team exercises covering prompt injection, data exfiltration, and jailbreaks. They align attacks and mitigations with OWASP LLM Top 10 and other threat catalogues. They collaborate with evaluation engineers to turn discovered exploits into regression tests. They work with security architecture teams on network boundaries, secrets management, and data exfiltration controls.

In smaller orgs this may be a part-time role inside the platform or security team. In regulated environments, it becomes a dedicated function.

Governance / AI risk partner

This is the bridge to the frameworks and checkpoints in Ch12. The governance partner interprets Singapore and sectoral frameworks (AI Verify, Model AI Governance, MAS FEAT, PDPA, sector guidelines) and translates them into concrete requirements for agents. They define and maintain lifecycle checkpoints and artefacts (AI dossiers, risk registers, model cards). They participate in design and release reviews as an independent voice. They help teams design oversight UX (e.g., approval flows, escalation paths) that satisfy governance needs without killing usability.

In practice, this person often sits in Risk, Compliance, or a central AI governance office but must work very closely with domain pods.

13.1.3 UX, service, and change roles

Agents are experienced as services, not as technical components. These roles make that experience coherent.

UX / service designer

The UX designer applies agent UX patterns from Ch10, including conversational vs workflow-driven, human-initiated vs event-triggered, and handoff patterns. They design oversight experiences—how users supervise and correct the agent, how exceptions are handled, how to show uncertainty. They work with the agent product owner to align the UX with service blueprints that clarify where humans stay in the loop and where agents automate.

Conversation designer

For conversational agents, the conversation designer defines tone, style, and persona constraints consistent with organisational brand and compliance. They design interaction flows including clarifying questions, escalation triggers, and fallback behaviours. They contribute prompt templates and dialogue rubrics that can be embedded into scaffolds. They review real transcripts to refine intent handling, explanation patterns, and apology/repair flows.

They are to conversational agents what UI designers are to visual interfaces.

Change and comms lead

Without change management, even the best agents get quietly bypassed. The change lead plans rollout communications—who needs to know what, when. They create training materials, quick-start guides, FAQs, and short videos. They coordinate feedback loops from frontline staff back to the agent product team. They work with HR, unions, or staff reps where appropriate to address job impact concerns.

Canaries: redesign entry-level work, not just tools. Early labour market evidence suggests the first visible impacts of generative AI show up in early-career roles in AI-exposed occupations, while employment for more experienced workers in the same occupations is more stable, at least initially. [R12.3] [R12.4] For builders, the practical takeaway is to treat onboarding and apprenticeship as part of the operating model. Create "junior-friendly" workflows where agents draft, summarise, and retrieve, while juniors learn verification, policy interpretation, and exception handling under supervision. This protects quality and preserves the talent pipeline.

In smaller setups this might be part of the agent product owner's job. In large organisations, it is a dedicated change role.

13.1.4 Operations and platform roles

These roles keep agents reliable, observable, and maintainable.

MLOps / AIOps / SRE

The SRE designs and maintains deployment pipelines for agents (Ch11). They implement observability—metrics, logs, traces, and alerts across agents and their scaffolds (Ch5, Ch11). They run on-call rotations for incidents that might involve both infra and model/agent behaviour. They coordinate rollbacks, traffic shaping, canary releases, and feature flags. They track SLOs that blend infrastructure and agent performance, such as "95% of HR Leave queries answered within 5 seconds with CSAT ≥ 4".

Agent platform team

This is the central team that builds shared tools and standards. They provide common model access (LLMs, embeddings, speech, vision) with policy guardrails. They operate shared harness infrastructure, evaluation tooling, and dashboards. They maintain reusable scaffold libraries, guardrail components, and config registries (policies, allowed tools, thresholds). They maintain the tool catalog and tool contracts, ideally via MCP-style standardisation, including schema versioning and access controls. They provide reusable components for multi-agent orchestration (A2A patterns), routing, and safe delegation. They own policy-as-code engines and integrate them into pipelines (Ch12.2.4, §13.3.4). They support domain pods with guidance, templates, and reviews.

Support / on-call rotation models for agents

As agents move into production, teams must define first-line support and decide where users log issues. They must decide how incidents are triaged—does it go to SRE, the agent squad, or governance? They implement runbooks for common issues such as degraded model performance, flaky tools, and policy changes. They ensure post-incident reviews always produce updates to harnesses, evaluation datasets, or UX—not just infra patches.

13.1.5 Skill matrix and learning paths

With so many roles, it helps to think in skill clusters:

Scaffolds and orchestration: prompt design, inner loop patterns, tool calling, state management
Retrieval and data: RAG, indexing schemes, data cleaning, governance
Evaluation and safety: harness design, LLM-as-judge, metrics, red-teaming, incident analysis
UX and service design: conversational patterns, oversight UX, service blueprints
Security and governance: threat modelling, OWASP LLM, regulatory mapping
Domain knowledge: HR policies, finance controls, legal procedures, contact centre operations

You do not need each person to have everything. Instead, define learning paths.

Full-stack agent engineer

Target audience: existing software or MLOps engineers.

Start with foundations—LLM APIs, prompt patterns, basic RAG. Move to scaffolds and tools—Plan–Execute, error handling, tool contracts. Then cover evaluation—writing harnesses, integrating metrics into CI/CD. Finally, learn security and governance basics—OWASP LLM Top 10, red-team fundamentals, policy-as-code.

Evaluation and safety specialist

Target audience: SDETs, security engineers, data scientists.

Start with evaluation basics—golden sets, metrics, label quality. Move to LLM-as-judge patterns, comparative evaluation, rubric design with SMEs. Then cover adversarial testing and red-teaming—attack patterns, mitigations, regression tests. Finally, learn governance integration—mapping tests to framework requirements, AI dossier contributions.

Domain SME → agent product owner

Target audience: HR, finance, legal, contact centre leaders.

Start with "Agentic AI 101" targeted to their domain. Move to user story writing for agent behaviour, including success and safety rubrics. Then cover basics of harnesses and evaluation—what golden cases look like, reading dashboards. Finally, learn governance responsibilities—lifecycle gates, sign-off criteria, handling escalations.

📚 Related sections: - RACI in governance → Chapter 12, §12.2.3 - SME involvement in evaluation → Chapter 6, §6.3 - Learning path patterns → Appendix A (Checklists)

13.2 Collaboration Modes (SMEs, Engineers, Risk, Ops)

Technology alone does not deliver impact. Collaboration patterns do. Agentic AI amplifies this because success depends on SME knowledge, evaluation discipline, and operational maturity.

Centaur vs cyborg workflows

Two collaboration modes serve as useful design defaults. In a centaur workflow, there is a clear handoff line between human and AI. Work is partitioned. This works best for regulated tasks, high-impact writes, and decisions needing auditability. The team must provide review checkpoints, approval UX, traceability, and harness cases for the handoff boundary.

In a cyborg workflow, human and AI interleave rapidly, iterating together across micro-steps. This works best for creative synthesis, drafting, exploration, design work, and rapid iteration. The team must provide fast feedback loops, good tooling ergonomics, versioning, "diff then commit," and lightweight provenance.

Teams can choose a centaur structure where governance and auditability are dominant, or a cyborg structure where rapid iteration and co-creation matter most. [R12.5] [R12.6]

13.2.1 Co-design with SMEs

The best agents start with co-design sessions between domain SMEs and engineering teams. Map real workflows by asking questions like "What steps does an HR officer follow when evaluating a leave request?" Identify high-value tasks and non-negotiable rules such as regulatory constraints and union agreements. Turn these into tasks, rubrics, and scenarios that feed directly into scaffold design (which tools and steps are needed) and evaluation datasets (golden cases, edge cases, red-team scenarios).

For example, consider the Invoice Approval Agent. Finance SMEs define what "acceptable" looks like for invoice coding, approval thresholds, and exceptions. These definitions become LLM judge rubrics, checklists, and policy enforcement rules embedded in the scaffold and harness.

13.2.2 Engineers + risk and security

Risk and security teams must be embedded, not consulted only at the end. Run regular threat modelling workshops for each agent, covering inputs, tools, data stores, and outputs. Review agents against OWASP LLM Top 10 and local regulatory requirements. Turn any discovered vulnerabilities into permanent test cases in the harness. Agree on risk tiers for agents (e.g., contact centre summarisation vs contract drafting vs credit decisions) and align testing depth and governance gates accordingly.

This creates a feedback loop:

Threat model → red-team tests → harness additions → improved safeguards → updated AI dossier.

13.2.3 Engineers + ops

Agents blur the line between application code and models/services. Collaboration with ops involves shared SLOs (Ch11) covering response time, error rates, fallback rates, safety violations (e.g., policy breach flags per 1,000 calls), and cost per transaction or session. It also involves joint incident reviews that ask: Was it infra, model behaviour, tool failure, or UX confusion? Did the harness catch it earlier? What eval metrics should be added to avoid recurrence?

Over time, this should feel similar to DevOps, but with metrics and incidents that are behavioural as much as technical.

13.2.4 Governance forums and rituals

Chapter 12 introduced lifecycle gates. Here we make them social.

Portfolio reviews (monthly or quarterly) look across all agents (HR, IT, Finance, Legal, Contact Centre). They discuss lifecycle stage, key metrics, incidents, and upcoming changes.

Release review ceremonies have each agent present an evidence package with test results, new harness cases, and updated risk assessment. The governance or AI risk partner confirms that framework requirements remain satisfied.

Incident postmortems follow a standard, blameless format. They always result in updates to dossiers, harnesses, and runbooks—not just hot fixes.

13.2.5 Collaboration patterns for distributed teams

In larger organisations and multi-region setups, you will not get everyone in the same room. You need async documentation with AI dossiers, design docs, runbooks, and decisions recorded in a shared repo with clear ownership per agent. You need shared dashboards showing evaluation metrics, safety flags, cost, and latency in one place—per agent, per domain—with views tailored for different audiences (exec, product owner, ops, risk). You need lightweight rituals such as weekly async updates from each squad and monthly cross-squad learning sessions to share patterns and failures.

📚 Related sections: - Layer separation (scaffold vs runtime vs orchestrator) → Chapter 4, §4.1 - Production responsibilities and handoffs → Chapter 11 - Governance rituals and checkpoints → Chapter 12, §12.2

13.3 Embedding Evaluation and Governance into Day-to-Day Work

The central principle from Ch3 was "Evaluation is a Feature." Here we make it operational.

13.3.1 "Evaluation is a Feature" in the delivery cadence

In a mature team, the backlog includes not just "add feature X" but also "Add golden cases for scenario Y," "Improve judge rubric for safety rule Z," and "Add red-team scenario for prompt injection pattern W." Every new feature comes with tests and metrics. When you expand the HR Leave agent to handle maternity leave, you also add harness cases, updated rules, and relevant safety checks. Regression testing includes behavioural suites, not just unit tests.

In other words, evaluation tasks are first-class citizens, not afterthoughts.

Centaur metrics: measure the human plus agent system

Metric lens	What it measures	Examples you can operationalise
Model-only	The model's outputs in isolation	Faithfulness, policy compliance score, harmful-content rate, tool-call validity
Centaur (human + agent)	The combined system: a person using the agent to complete real work	Cases resolved per hour, time-to-decision, rework rate, escalation rate, approval turnaround, minutes of human oversight per case, incident rate per 1,000 sessions

Centaur evaluations shift development toward augmentation. They capture human-centered desiderata that disappear when you benchmark the model alone. [R12.2] [R12.4]

13.3.2 Dossiers and lifecycle gates as everyday tools

The AI dossier (Ch12) should not be a once-a-year compliance artefact. Embed it into normal work. Update the dossier whenever you add a new capability, change a scaffold or model, or discover a new risk or mitigation.

Make lifecycle gates checklist-driven:

Idea: define use case, domain owner, initial risk tier
Design: early threat model, initial test plan, SME sign-off
Pre-Pilot: harness v1, golden set baseline, oversight plan
Pre-Prod: red-team results, rollback plan, SLOs defined
Change: impact analysis, tests, sign-off, rollback readied

13.3.3 Telemetry, on-call, and continuous improvement

Chapter 5 and Chapter 11 covered observability. Here is how to use it day-to-day.

Establish daily or weekly rituals around dashboards. Are we seeing more tool errors? Has the distribution of user queries shifted? Are safety flags or user complaints rising?

Link signals to actions. Drift in user queries leads to collecting examples, then expanding the dataset and harness. Frequent safety flags lead to tightening guardrails, updating rubrics, and revisiting UX. High fallback rates lead to re-examining scaffold design or tool reliability.

The goal is a continuous feedback loop: telemetry → investigation → harness/test changes → design changes → updated dossier.

13.3.4 Integrating governance and security into CI/CD

CI/CD must become CI/CE/G: continuous integration, evaluation, and governance.

Pipelines should run evaluation suites on every significant change, covering task success metrics, non-regression on safety rubrics, and OWASP LLM Top 10 scenario checks where applicable. Policy-as-code and config registries (Ch12.2.4) act as gates. They disallow deployment to production if safety metrics degrade beyond thresholds. They enforce that high-risk agents always have up-to-date red-team results. Security tests (static, dynamic, adversarial) sit alongside traditional tests.

This does not need to be complex initially. Start with a small set of must-pass checks for your most critical agents, then expand.

13.3.5 Working with Singapore frameworks and sector rules in practice

For many readers, frameworks like AI Verify, the Model AI Governance Framework, MAS FEAT, and sectoral guidelines are not optional. They are table stakes.

The practical pattern works as follows. For each agent (e.g., Invoice Agent, HR Leave Agent, Contact Centre Agent), the governance partner works with the team to map framework principles to concrete practices—documentation, tests, oversight processes. They tag evaluation artefacts (datasets, metrics, red-team logs) with the framework items they support.

During internal reviews or external audits, the team can then show how their harnesses demonstrate fairness, robustness, and explainability. They can show how their AI dossier links incidents and mitigations to specific guidelines.

The key shift is to treat frameworks as design inputs, not after-the-fact audits.

📚 Related sections: - Production maturity and gates → Chapter 11, §11.0, §11.7 - Evaluation in CI/CD → Chapter 7, §7.4 - Governance checkpoints → Chapter 12, §12.2

13.4 Org Patterns for "Agentic AI as a Product Capability"

There is no single correct org structure, but a few patterns show up repeatedly.

13.4.1 Central platform + domain pods (hub-and-spoke)

When it works best: medium to large organisations with multiple domains and shared constraints.

The central platform team (hub) owns model gateways, shared scaffolds, evaluation infrastructure, logging, guardrails, and policy-as-code. They own common standards, libraries, and secure integration patterns. Domain pods (spokes) include HR, IT, Finance, Legal, and Contact Centre squads. Each pod owns its agents, backlogs, harnesses, and AI dossiers.

This pattern avoids each pod reinventing infra and governance. It keeps agents close to domain SMEs and business outcomes. It allows consistent evaluation and risk practices across the portfolio.

13.4.2 Federated centres of excellence

When it works best: large, multi-region or multi-business-unit organisations.

Multiple mini-hubs (e.g., per region or BU) have their own platform capabilities. A federated CoE defines global standards including common scaffold patterns, evaluation frameworks, governance templates, and approved tools and libraries. Local teams tailor implementations to local regulations, languages, and workflows.

This is more complex, but often necessary when legal, cultural, or operational contexts vary significantly.

13.4.3 Embedded agent teams inside existing product squads

When it works best: organisations with mature product engineering and platform teams.

Agents become features inside existing products. Contact centre software gains triage and summarisation agents. CRM gains a sales co-pilot agent. HRIS gains a leave guidance and policy agent. Instead of separate agent squads, you embed LLM/scaffold specialists, evaluation engineers, and governance liaisons into product squads.

The challenge is to maintain consistency in evaluation and governance. The central CoE or platform defines common patterns and gates. Embedded teams follow those patterns while tailoring to their product.

13.4.4 Choosing patterns by maturity and sector

You are unlikely to get it perfectly right on day one. A pragmatic roadmap follows.

Early-stage (ad hoc pilots): Form a small "Agent Tiger Team" with 1–2 engineers, 1 data/eval person, 1–2 domain SMEs, and 1 governance partner. Focus on 1–2 flagship agents (e.g., HR Leave, Contact Centre triage).

Mid-stage (repeatable): Evolve into central platform + 2–3 domain pods. Start defining shared patterns and governance artefacts.

Advanced (integrated): Build out full hub-and-spoke or federated CoE. Embed agent roles into major product squads.

Highly regulated: Establish stronger central governance with mandated roles (data protection officer, AI risk committee). Create clear demarcation of what can be decentralised vs what must stay central (e.g., risk policies).

13.4.5 Organisational anti-patterns

A few recurring failure modes deserve attention.

"AI lab theatre": A central lab builds flashy demos without domain ownership, evaluation discipline, or production integration.

Shadow AI: Business teams spin up their own agents, bypassing platform, security, and governance. This leads to duplicated work and unmanaged risk.

Single "hero" engineer teams: One highly skilled engineer builds the agent. There is no SME, no UX, no risk partner. When they leave, the capability collapses.

Evaluation and governance as one-off project work: A big push before launch, then nothing. Harnesses and dossiers rot. Policies drift. Trust erodes.

Spotting and addressing these anti-patterns early is part of building a sustainable capability.

13.4.6 Leadership, lab, and crowd (a practical overlay)

Mollick frames successful AI transformation as an interaction between leadership, the crowd, and the lab. The key claim is that individual productivity gains do not automatically become organisational gains. Capturing them requires clear incentives, safe boundaries, and rapid experimentation that is owned inside the organisation. [R12.10]

Leadership sets the "why," but also the safety boundaries and incentives. They determine where experimentation is allowed, what data is off-limits, what success looks like, and whether productivity gains translate into layoffs or growth. If this is ambiguous, people hide their AI use. [R12.8]

The crowd discovers what actually works in context. Frontline employees experiment on real tasks and share repeatable workflows and prompts. [R12.9] [R12.10]

The lab turns the best discoveries into products and standards. It ships internal tools, publishes prompt and workflow libraries, and builds benchmarks for the tasks your organisation actually does—not generic public leaderboards. [R12.10]

Mapping this to the patterns in this chapter: Leadership includes exec sponsor, governance partner, risk committee, and platform leadership. Lab includes agent platform team, evaluation engineers, safety engineers, and enablement. Crowd includes domain pods, power users, and frontline practitioners in HR, Finance, IT, Legal, and Contact Centre.

Anti-pattern warning: Three common defaults are to ignore AI, ban it, or over-centralise it. These approaches often produce "secret cyborgs"—people use AI anyway, but off-policy and without sharing learnings. (See also §13.4.5.) [R12.8] [R12.9]

13.5 Capability Building, Hiring, and Upskilling

You can design all the structures you like. Without people development, they will not sustain.

13.5.1 Hiring strategies

You probably do not need a flood of brand-new job titles. Instead, augment existing roles. Up-skill SDETs into evaluation engineers. Grow a few agent architects from senior engineers who enjoy design and systems thinking.

When hiring externally, look for evaluation engineers with a background in testing, data science, or applied ML, plus hands-on LLM eval experience. Look for safety specialists with security or adversarial ML experience and a pragmatic view of enterprise risks. Look for agent architects with broad platform experience, not just prompt hacking.

Mix internal domain SMEs (who know HR/Finance/Legal/Contact Centre deeply) with external AI expertise. Neither group can succeed alone.

13.5.2 Upskilling existing teams

Create targeted learning plans.

For domain SMEs: Cover foundations of LLMs and agentic patterns, writing rubrics and examples for evaluation, and understanding metrics and dashboards.

For developers: Cover scaffolds and harnesses (Ch4–5), evaluation integration (Ch6–7), cost and performance optimisation (Ch11), and security basics for LLMs.

For ops and SRE: Cover observability for agents (new metrics, traces, and alerts), incident playbooks that include model and behaviour issues, and governance-aligned change management.

These do not need to be 6-month programs. Start with short, hands-on sessions around your actual agents.

13.5.3 Partner and ecosystem models

Few organisations can or should build everything in-house. Consider vendors and cloud providers for foundational models, evaluation tooling, and observability platforms. Consider system integrators and consultancies to jump-start pilots and help set up platform patterns. Consider academia and assurance partners for specialised evaluation, safety, or regulatory topics.

The key is to maintain internal ownership of agent product decisions, risk appetite and governance, and the core platform that ties agents together.

13.5.4 Maturity roadmap

Your agentic AI capability evolves through four stages: Ad hoc → Repeatable → Integrated → Optimised. See Table 12.5 in §13.A below for detailed characteristics, evidence, gaps, and triggers at each stage.

Signals you are ready to move up: you can onboard a new agent using existing patterns without reinvention; you can answer "how do we know this agent is working safely?" with dashboards, not anecdotes; and incidents drive systematic improvements to harnesses, scaffolds, and governance.

13.6 Summary and bridge to Chapter 14

At scale, the limiting factor for agentic AI is rarely a missing model capability. It is missing ownership and missing operating rhythm. The teams and org patterns in this chapter aim to make three things true across your portfolio.

Every agent has a clear owner, a maintained backlog, and a practical definition of "done" that includes evaluation and safety.

Evaluation and governance run as part of delivery, not as an end-of-project event. Tests, dossiers, and evidence packs stay current.

Ops, UX, risk, and engineering share the same reality through telemetry, runbooks, and rituals that turn incidents into regressions.

In Chapter 14, the case studies show what this looks like end-to-end, using the same reusable template: principles in action, scaffolds and patterns used, harness and evaluation setup, and governance and lifecycle aspects.

12.A Tables and Visuals

Table 12.1 — Role–Skill Matrix for Agentic AI Teams

This matrix shows at a glance which roles need which capabilities. Use it for hiring, upskilling, and pod design.

Role	Domain Knowledge	Scaffolds & Orchestration	RAG & Data Products	Evaluation & Metrics	Safety & Security	UX / Conversation Design	Governance & Frameworks	Production Ops & SRE
Agent / Product Owner	H	M	M	M	L	M	H	L
Agent Architect / Lead Engineer	M	H	H	H	M	M	M	M
LLM / Tool Engineer	L	H	H	M	M	L	L	M
Data Engineer / Data Product Owner	M	L	H	M	L	L	M	L
Evaluation Engineer	M	M	M	H	H	L	M	M
Safety / Red-Team / Security Engineer	L	M	M	H	H	L	M	L
Governance / AI Risk Partner	M	L	L	M	M	L	H	L
UX / Service Designer	M	L	L	M	L	H	M	L
Conversation Designer	M	M	L	M	L	H	L	L
MLOps / AIOps / SRE	L	M	M	M	M	L	L	H
Agent Platform Engineer	L	H	M	M	M	L	M	H

Legend: H = High proficiency expected | M = Medium | L = Low (awareness level)

Table 12.2 — Learning Paths for Different Personas

Target Persona	Path Name	Starting Skills	Key Learning Modules	Hands-on Milestones	End-State Responsibilities
Domain SME (HR, Finance, Legal)	Agent Product Owner	Deep domain expertise, stakeholder management	Agentic AI 101, User story writing for agents, Rubric design, Reading dashboards, Governance responsibilities	Write 10 golden cases, Review one evaluation dashboard, Participate in one release review	Own agent backlog, Define rubrics with engineers, Sign off on lifecycle gates
Backend Engineer	Full-Stack Agent Engineer	Software engineering, APIs, databases	LLM APIs and prompt patterns, Scaffolds (ReAct, Plan–Execute), Tool integration, Evaluation harnesses, Security basics	Build one working scaffold, Integrate 3 tools, Pass OWASP LLM scenarios	Design and implement agent scaffolds, Own tool integrations, Support evaluation engineering
SDET / QA Engineer	Evaluation & Safety Specialist	Test design, automation, data analysis	Evaluation foundations, LLM-as-judge patterns, Red-team and adversarial testing, Governance integration	Build one harness suite, Curate one golden set, Run one red-team exercise	Own agent evaluation infrastructure, Design safety suites, Contribute to AI dossiers
SRE / Platform Engineer	AI-Aware SRE / AIOps	Infrastructure, monitoring, incident response	Agent observability, Behavioural metrics, Incident playbooks for AI, Governance-aligned change management	Add agent metrics to dashboards, Write one agent runbook, Conduct one AI incident review	On-call for agent incidents, Own deployment pipelines, Track agent SLOs

Table 12.3 — Collaboration Rituals and Forums

Ritual / Forum	Frequency	Participants	Main Inputs	Outputs / Artefacts	Related Chapter Links
Co-design Workshop	Per agent kickoff, then quarterly	Domain SMEs, Agent Architect, Evaluation Engineer	Workflow maps, Policy documents, Pain points	Task definitions, Rubrics, Initial golden cases	Ch6 (Evaluation), Ch4 (Scaffolds)
Threat Modelling Session	Per agent design, then on major changes	Engineers, Security, Risk, Governance	Agent architecture, Data flows, Tool inventory	Threat register, Red-team scenarios, Harness additions	Ch9 (Security patterns), Ch12 (Governance)
Release Review Ceremony	Before each production release	Domain Pod, Platform, Governance Partner	Test results, Evidence pack, Risk assessment	Go/no-go decision, Dossier updates, Rollback plan	Ch11 (Production gates), Ch12 (Checkpoints)
Incident Postmortem	After each incident	Ops, Agent Squad, Risk, affected SMEs	Incident timeline, Traces, User reports	Root cause, Harness additions, Runbook updates	Ch11 (Observability), Ch5 (Harnesses)
Portfolio Review	Monthly or quarterly	Cross-domain leads, Governance, Exec Sponsor	Dashboards, Lifecycle status, Incident summaries	Priority decisions, Resource allocation, Risk escalations	Ch12 (Lifecycle), Ch13 (Org patterns)

Table 12.4 — Org Patterns for Agentic AI: Comparison

Pattern	Description	When to Use	Strengths	Challenges / Risks	Typical Sectors / Org Types
Central Platform + Domain Pods (Hub-and-Spoke)	Central team owns infra, scaffolds, eval tooling; domain pods own specific agents	Medium–large orgs with multiple domains and shared constraints	Consistent standards, avoids reinvention, clear ownership per domain	Platform team can become bottleneck, domain pods may feel constrained	Financial services, healthcare, large enterprises
Federated Centres of Excellence	Multiple regional/BU hubs with local platforms; federated CoE sets global standards	Large, multi-region or multi-BU organisations	Local autonomy, adapts to local regulations/languages, scales across geographies	Coordination overhead, risk of fragmentation, harder to share learnings	Global enterprises, conglomerates, multinational banks
Embedded Agent Teams in Product Squads	Agent specialists embedded in existing product teams; slim central CoE for standards	Mature product engineering orgs	Fast iteration, deep product integration, minimal org change	Risk of inconsistent evaluation/governance, harder to share patterns	Tech companies, SaaS providers, digital-native firms
"Agent Tiger Team" (early-stage)	Small cross-functional team focused on 1–2 flagship agents	Organisations just starting with agents	Fast learning, low overhead, concentrated expertise	Does not scale, bus factor risk, governance may be ad hoc	Any org in early pilot phase

Anti-Patterns to Avoid

Anti-pattern	Symptom	Consequence	What to Do Instead
AI Lab Theatre	Central lab produces demos, no domain integration	Pilots never reach production, business value unclear	Pair lab with domain pods, require production path
Shadow AI	Business teams build agents without platform/governance	Security risks, duplicated effort, compliance gaps	Provide easy onramps, make platform compelling, governance support
Single Hero Engineer	One person builds and maintains the agent	Bus factor = 1, no eval/UX/risk coverage	Require minimum team (SME + engineer + eval)
One-off Governance	Big audit push before launch, then neglect	Dossiers rot, trust erodes, incidents escalate	Embed governance into delivery cadence

Table 12.5 — Agentic AI Capability Maturity Stages

Stage	Typical Characteristics	Evidence of This Stage	Key Gaps	Triggers to Move Up	Recommended Next Moves
1. Ad hoc	Isolated pilots, no shared standards, evaluation mostly manual, single-hero teams	Agents built case-by-case, no central tooling, governance by PowerPoint	No platform, no repeatable eval, no clear ownership	First pilot reaches production, second agent request arrives	Form small platform team, define minimal eval pattern, document first agent
2. Repeatable	Shared scaffold patterns, central platform emerging, eval harnesses for key agents, some governance templates	2–3 agents using common tools, golden sets exist, AI dossiers started	Inconsistent practices across domains, governance still project-based	Third domain wants an agent, first major incident, regulatory inquiry	Expand platform team, define governance rituals, hire eval engineer
3. Integrated	Agents in core products/workflows, CI/CD includes eval & governance gates, clear SLOs, multi-domain portfolio	Agents are "business as usual", incidents go through standard process, dossiers current	Optimisation opportunities unexplored, ecosystem immature	Portfolio exceeds 5 agents, cross-domain patterns emerge, exec sponsorship strengthens	Formalise CoE, build ecosystem partnerships, invest in advanced eval
4. Optimised	Continuous improvement loops, proactive risk management, strong ecosystem partnerships, frontier experiments inform strategy	Agents self-improve via feedback, governance is proactive not reactive, new agents onboard in days	Maintaining edge requires ongoing investment	Market leadership, regulatory thought leadership, talent magnet	Lead industry working groups, publish patterns, invest in research partnerships

Figure 12.1 — "From Projects to Capability" Overview

flowchart LR
    subgraph Pilots["Ad hoc Pilots"]
        P1[HR Leave PoC]
        P2[Invoice PoC]
        P3[Contact Centre PoC]
    end

    subgraph Pods["Cross-Functional Domain Pods"]
        HR[HR Leave Squad]
        INV[Invoice Squad]
        CC[Contact Centre Squad]
    end

    subgraph Capability["Agentic AI Capability"]
        Platform["Central Platform Team<br/>(Models, Scaffolds, Eval Infra,<br/>Guardrails, Logging)"]
        Gov["Governance & Standards"]
    end

    P1 --> HR
    P2 --> INV
    P3 --> CC

    HR --> Platform
    INV --> Platform
    CC --> Platform

    Platform --> Gov

Moving from isolated pilots to a reusable agentic AI capability built on stable domain pods and a central platform.

Figure 12.2 — Role Involvement Across the Agent Lifecycle

gantt
    title Role Involvement Across Agent Lifecycle
    dateFormat X
    axisFormat %s

    section Agent Product Owner
    Idea           :active, po1, 0, 1
    Design         :active, po2, 1, 2
    Pre-Pilot      :active, po3, 2, 3
    Pilot          :active, po4, 3, 4
    Pre-Production :active, po5, 4, 5
    Production     :active, po6, 5, 6
    Retirement     :active, po7, 6, 7

    section Agent Architect / Engineers
    Idea           :done, eng1, 0, 1
    Design         :active, eng2, 1, 2
    Pre-Pilot      :active, eng3, 2, 3
    Pilot          :active, eng4, 3, 4
    Pre-Production :active, eng5, 4, 5
    Production     :crit, eng6, 5, 6
    Retirement     :done, eng7, 6, 7

    section Evaluation & Safety
    Idea           :done, eval1, 0, 1
    Design         :crit, eval2, 1, 2
    Pre-Pilot      :active, eval3, 2, 3
    Pilot          :active, eval4, 3, 4
    Pre-Production :active, eval5, 4, 5
    Production     :active, eval6, 5, 6
    Retirement     :done, eval7, 6, 7

    section Governance / Risk
    Idea           :crit, gov1, 0, 1
    Design         :active, gov2, 1, 2
    Pre-Pilot      :crit, gov3, 2, 3
    Pilot          :done, gov4, 3, 4
    Pre-Production :crit, gov5, 4, 5
    Production     :active, gov6, 5, 6
    Retirement     :crit, gov7, 6, 7

    section Ops / SRE
    Idea           :done, ops1, 0, 1
    Design         :done, ops2, 1, 2
    Pre-Pilot      :done, ops3, 2, 3
    Pilot          :crit, ops4, 3, 4
    Pre-Production :active, ops5, 4, 5
    Production     :active, ops6, 5, 6
    Retirement     :active, ops7, 6, 7

Legend: Active = Primary involvement | Crit = Gate/decision point | Done = Supporting/informed

Key roles across the agent lifecycle, showing primary involvement, gate points, and supporting roles from idea to retirement.

Figure 12.3 — Feedback Loops Around a Deployed Agent

flowchart TB
    Agent["HR Leave Agent<br/>(Production)"]

    subgraph Loop["Continuous Outer Loop"]
        Telemetry["1. User Interactions<br/>& Production Telemetry"]
        Eval["2. Evaluation Harness<br/>& Dashboards"]
        Review["3. Incident Reviews<br/>& SME Feedback"]
        Updates["4. Scaffold / Data<br/>/ UX Updates"]
        Governance["5. Governance<br/>& Dossier Updates"]
    end

    Agent --> Telemetry
    Telemetry --> Eval
    Eval --> Review
    Review --> Updates
    Updates --> Governance
    Governance --> Agent

Continuous feedback loops connecting telemetry, evaluation, design updates, and governance for each agent.

Figure 12.4 — Org Pattern Variants

flowchart TB
    subgraph HubSpoke["A: Hub-and-Spoke"]
        Platform1["Agent Platform Team<br/>(Models, Scaffolds, Eval,<br/>Guardrails)"]
        HR1[HR Pod]
        IT1[IT Pod]
        FIN1[Finance Pod]
        LEG1[Legal Pod]
        CC1[Contact Centre Pod]

        Platform1 --- HR1
        Platform1 --- IT1
        Platform1 --- FIN1
        Platform1 --- LEG1
        Platform1 --- CC1
    end

    subgraph Federated["B: Federated CoEs"]
        Global["Global Agentic CoE<br/>(Standards & Patterns)"]
        APAC["APAC Hub"]
        EMEA["EMEA Hub"]
        AMER["Americas Hub"]

        Global --- APAC
        Global --- EMEA
        Global --- AMER
    end

    subgraph Embedded["C: Embedded Teams"]
        CoE["Slim CoE<br/>(Governance & Patterns)"]
        Prod1["Contact Centre Product<br/>+ Agent Layer"]
        Prod2["CRM Product<br/>+ Agent Layer"]
        Prod3["HRIS Product<br/>+ Agent Layer"]

        CoE --- Prod1
        CoE --- Prod2
        CoE --- Prod3
    end

Common organisational patterns for scaling agentic AI: (A) hub-and-spoke with central platform, (B) federated centres of excellence, and (C) embedded teams with slim CoE.

Figure 12.5 — CI/CE/G Pipeline for Agentic AI

flowchart LR
    subgraph Changes["Code & Config Changes"]
        Code["Scaffolds<br/>Tools<br/>Prompts<br/>Policies"]
    end

    subgraph Build["Build & Unit Tests"]
        Unit["Standard Tests<br/>Lint<br/>Type Check"]
    end

    subgraph Eval["Evaluation Harness"]
        Tasks["Task Metrics"]
        Safety["Safety Metrics"]
        OWASP["OWASP Scenarios"]
    end

    subgraph Gov["Governance Checks"]
        Policy["Policy-as-Code"]
        Thresholds["Risk Thresholds"]
        Dossier["Dossier Update?"]
    end

    subgraph Deploy["Deployment"]
        Canary["Canary / Shadow"]
        Full["Full Rollout"]
    end

    subgraph Monitor["Monitoring"]
        Telemetry["Telemetry<br/>& Feedback"]
    end

    Code --> Unit --> Tasks
    Tasks --> Safety --> OWASP
    OWASP --> Policy --> Thresholds --> Dossier
    Dossier --> Canary --> Full --> Telemetry
    Telemetry -.->|Feedback| Code

Integrating evaluation (CE) and governance (G) into the continuous integration and deployment pipeline for agents.

Figure 12.6 — Agentic AI Capability Maturity Staircase

flowchart TB
    subgraph Maturity["Capability Maturity Stages"]
        direction TB
        L4["4. OPTIMISED<br/>- Continuous improvement loops<br/>- Proactive risk management<br/>- Ecosystem partnerships<br/>- New agents in days"]
        L3["3. INTEGRATED<br/>- Agents in core workflows<br/>- CI/CD with eval gates<br/>- Clear SLOs<br/>- Governance routine"]
        L2["2. REPEATABLE<br/>- Shared patterns<br/>- Platform emerging<br/>- Eval harnesses exist<br/>- Some governance templates"]
        L1["1. AD HOC<br/>- Isolated pilots<br/>- No shared standards<br/>- Manual evaluation<br/>- Hero engineers"]

        L1 --> L2 --> L3 --> L4
    end

Agentic AI capability maturity stages, from ad hoc pilots to optimised, integrated operations.

Key Takeaways

Agents are products, not projects — Treat each agent as a long-lived product with a dedicated owner, a backlog that includes evaluation and safety stories, lifecycle gates, and a living AI dossier that stays current through continuous delivery.
Cross-functional pods plus a central platform — The pattern that consistently works pairs stable domain pods (product owner, architect, engineers, evaluation engineer, UX designer, governance partner) with a shared platform team providing model access, scaffold libraries, guardrails, evaluation infrastructure, and policy-as-code.
Evaluation and governance are everyday work, not launch events — Embed harness updates, red-team scenarios, dossier maintenance, and governance checks into the normal delivery cadence and CI/CD pipeline so they stay current as models, tools, and policies change.
Plan for the J-curve and the jagged frontier — Early adoption will show rising costs before visible productivity gains; budget for non-model complements like change management, enablement, and workflow redesign, and treat delivery as frontier-mapping through deliberate experimentation rather than predictable feature shipping.
Upskill existing staff rather than hiring from scratch — Grow evaluation engineers from SDETs, agent architects from senior engineers, AI-aware SREs from existing ops teams, and agent product owners from domain SMEs, using targeted hands-on learning paths tied to your actual agents.
Choose and evolve your org pattern deliberately — Start with a small tiger team for early pilots, grow into hub-and-spoke or federated models as the portfolio expands, and watch for anti-patterns (AI lab theatre, shadow AI, single-hero engineers, one-off governance) that cause agent capabilities to decay.
Measure the human-plus-agent system, not just the model — Centaur metrics like end-to-end cycle time, rework rate, escalation rate, and oversight burden per case capture real-world value that model-only benchmarks miss, and they keep teams focused on augmentation rather than raw automation.

Next -> Chapter 14 brings everything together with end-to-end case studies that show how principles, scaffolds, evaluation, UX, production, and governance work in practice.

12.R References

[R12.1] Erik Brynjolfsson, Daniel Rock, Chad Syverson. "The Productivity J-Curve: How Intangibles Complement General Purpose Technologies." NBER Working Paper No. 25148 (2018). https://www.nber.org/system/files/working_papers/w25148/w25148.pdf

[R12.2] Andreas Haupt, Erik Brynjolfsson. "AI Should Not Be an Imitation Game: Centaur Evaluations." Stanford Digital Economy Lab (June 2025). https://digitaleconomy.stanford.edu/wp-content/uploads/2025/06/CentaurEvaluations.pdf

[R12.3] Erik Brynjolfsson, Bharat Chandar, Ruyu Chen. "Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence." Stanford Digital Economy Lab (Nov 13, 2025). https://digitaleconomy.stanford.edu/wp-content/uploads/2025/08/Canaries_BrynjolfssonChandarChen.pdf

[R12.4] Marcus Weldon. "Centaurs, Canaries and J-Curves: Pitfalls and Productivity Potential of AI." Newsweek.AI (published Dec 18, 2025; updated Dec 20, 2025). https://www.newsweek.com/nw-ai/centaurs-canaries-and-j-curves-pitfalls-and-productivity-potential-of-ai-11214666

[R12.5] Ethan Mollick. "Centaurs and Cyborgs on the Jagged Frontier." One Useful Thing (Sep 16, 2023). https://www.oneusefulthing.org/p/centaurs-and-cyborgs-on-the-jagged

[R12.6] Ethan Mollick. "I, Cyborg: Using Co-Intelligence." One Useful Thing (Mar 14, 2024). https://www.oneusefulthing.org/p/i-cyborg-using-co-intelligence

[R12.7] Ethan Mollick. "On-boarding your AI Intern." One Useful Thing (May 20, 2023). https://www.oneusefulthing.org/p/on-boarding-your-ai-intern

[R12.8] Ethan Mollick. "Detecting the Secret Cyborgs." One Useful Thing (Jun 18, 2023). https://www.oneusefulthing.org/p/detecting-the-secret-cyborgs

[R12.9] Ethan Mollick. "On holding back the strange AI tide." One Useful Thing (Jul 23, 2023). https://www.oneusefulthing.org/p/on-holding-back-the-strange-ai-tide

[R12.10] Ethan Mollick. "Making AI Work: Leadership, Lab, and Crowd." One Useful Thing (May 22, 2025). https://www.oneusefulthing.org/p/making-ai-work-leadership-lab-and

[R12.11] Ethan Mollick. "Freeing the chatbot." One Useful Thing (May 2, 2024). https://www.oneusefulthing.org/p/freeing-the-chatbot

[R12.12] Ethan Mollick. "Getting started with AI: Good enough prompting." One Useful Thing (Nov 24, 2024). https://www.oneusefulthing.org/p/getting-started-with-ai-good-enough

[R12.13] Ethan Mollick. "The Shape of AI: Jaggedness, Bottlenecks and Salients." One Useful Thing (Dec 20, 2025). https://www.oneusefulthing.org/p/the-shape-of-ai-jaggedness-bottlenecks