- 01. The three architectural archetypes most AI products collapse into — Augmentation, Copilot, Agent — and the structural property that distinguishes each.
- 02. The Intelligence vs Judgment framing that determines which archetype your workflow actually needs — and why most teams pick the wrong one because they confuse the two.
- 03. The Jagged Frontier finding — AI raises productivity inside its competence zone and drops it by 19 percentage points outside that zone — and why this single empirical fact changes every architecture decision.
- 04. The PM diagnostic that surfaces architectural misalignment in ten minutes — and the four traps that ship products with split personalities.
The product with the split personality
A vertical SaaS team spends Q3 2025 building what the PRD calls a “Copilot.” The model is good. The interface is clean. The eval suite is the right shape for a Copilot — suggestion quality, acceptance rate, edit distance.
By Q4 review, the product is sliding. Engineering has been quietly building agentic chains underneath the Copilot UI — multi-step reasoning, tool calls, autonomous data fetches — because the customer’s actual workflow demanded more than suggestions. Design has been pushing for visible agency: “the user wants the AI to do the thing, not propose the thing.” Sales is selling the product as an “intelligent assistant” because their buyer doesn’t have a budget line for “Copilot.”
By Q1 2026, the product has a split personality. The eval suite measures suggestion acceptance, but the actual usage is autonomous task completion. The pricing is per-seat, but the customer is consuming variable inference. The trust architecture was designed for visible suggestions, but the system is taking actions the user doesn’t see. Every metric is pointing in a slightly different direction. The team is debating whether the next version is a “Copilot+” or an “Agent” — without realising the question itself is the whole problem.
This is architectural ambiguity. It is the most common — and most expensive — strategic failure I see in 2026 AI product development. The team didn’t pick an architectural archetype. They drifted into one, and the drift accumulated drag across every other decision in the product.
The fix isn’t a redesign. The fix is upstream: making the architectural choice explicit, before the next sprint, with full awareness of what each archetype demands across pricing, evals, trust, latency, team structure, and moat.
The frame to carry into every product strategy meeting
Architecture, in AI product strategy, isn’t a technical concern. It is the upstream decision that determines almost every other decision downstream.
Pick the wrong archetype and your evals don’t match your product, your pricing doesn’t match your value capture, your trust architecture doesn’t match your user’s risk tolerance, your team structure doesn’t match the work the product actually does. None of these mismatches show up immediately. All of them show up by month six.
Architecture is upstream. Pricing, evals, trust, latency, team structure, moat archetype — all flow from the architectural choice.
The frame for every product strategy meetingMost teams make this choice implicitly through accumulated decisions. The teams that make it explicitly ship faster and waste less. The job of this post is to make the choice explicit and give you the diagnostic to run on your own product this week.
The Intelligence vs Judgment foundation
Before naming the three archetypes, the underlying distinction has to land — because architecture follows from this distinction, and most architectural mistakes trace back to a misread of where on the Intelligence/Judgment line the work actually sits.
Every workflow has two kinds of work happening inside it (Vlad Podoliako, Sell the Work, Not the Tool; echoed across 2026 AI strategy writing including the services-as-software wave analyses):
- Intelligence — rule-based, pattern-matchable, codifiable. The slice of the work where past examples reliably predict the right answer. Searching, summarising, transforming, routing, generating-from-template. Reading a contract for standard clauses. Categorising support tickets. Drafting a routine email.
- Judgment — contextual interpretation, ethical weighting, the instinct that builds across years of practice. The slice where past examples don’t reliably predict the right answer because the context is what matters. Whether to escalate a customer complaint that’s technically resolved but emotionally unresolved. Whether a contract clause is acceptable for this counterparty. Whether to ship the feature this week or hold for the eval.
AI in 2026 does Intelligence work very well. AI does Judgment work poorly — sometimes catastrophically poorly, in ways that are hard to predict from benchmark scores. The architectural question for any product is: where in the workflow does Judgment have to stay with the human, and what archetype enforces that?
This is also why “let the AI handle it” is the wrong answer to almost every PM question. The right answer is: which slice of this is Intelligence, which slice is Judgment, where does the boundary need to live, and what architecture enforces it?
Once the slice is named, the architecture follows from a single ratio. The three rules:
- High Intelligence · Low Judgment → Agent. Routine tier-1 support, lead enrichment, batch document classification. Humans don’t add much value to the routine call. The cost-structure win comes from taking them out of the loop.
- High Intelligence · High Judgment → Copilot. Sales, legal review, clinical decision support. AI surfaces; the human decides. Pair them; don’t replace the judgment.
- Low Intelligence · High Judgment → Augmentation. Creative writing, design, strategy. The human leads; AI amplifies a specific capability on demand.
The mismatch failures are predictable. Agent applied to a high-judgment workflow produces user revolt — the sales rep refuses to delegate which prospect to prioritise, which discount to escalate. Copilot applied to a low-judgment workflow produces a structural cost disadvantage — a competitor ships Agent on the same tier-1 cases and undercuts you because there’s no human in their loop. Augmentation applied to a high-Intelligence-low-Judgment workflow is just slow.
The Jagged Frontier — the empirical fact that changes everything
The single most important academic finding for AI PMs in 2026 came out of a Harvard / BCG field experiment by Dell’Acqua and colleagues. The study — published in 2023 and re-published in Organization Science in 2026 (HBS Working Knowledge; Organization Science) — measured what happens when knowledge workers use AI inside and outside the AI’s competence zone.
The result has come to be called the Jagged Frontier:
- Inside the AI’s competence zone: knowledge workers using AI were significantly more productive — faster and higher quality.
- Outside the competence zone: workers using AI were 19 percentage points less likely to produce correct solutions than workers without AI at all.
Read that twice. AI inside the frontier accelerates. AI outside the frontier makes humans worse than they would have been alone.
The mechanism: outside the frontier, the AI produces confident-sounding but wrong answers. Humans, lacking the expertise to spot the wrongness, anchor on the AI’s output. Their final answers are worse than if they’d worked from scratch.
AI inside the frontier accelerates. AI outside the frontier makes humans worse than they would have been alone.
Dell’Acqua et al., HBS / BCG (2023)This is the fact every architectural decision has to wrestle with. Augmentation, Copilot, and Agent each have a different relationship to the Jagged Frontier:
- Augmentation stays inside the frontier by design. The AI is doing one narrow slice that falls clearly within its competence zone. Spell-check doesn’t try to write your essay.
- Copilot assumes the human is doing the judgment work and can spot when the AI is outside its zone. The Jagged Frontier finding suggests this assumption is fragile — humans don’t always spot the wrongness, especially when they’re tired or rushed.
- Agent carries the most exposure to the Jagged Frontier, because the human is supervising selectively. When the agent crosses outside its frontier without being noticed, the cost compounds across multiple actions before the human catches it.
The architectural lesson: explicit awareness of where your AI’s frontier is, and explicit mechanisms to keep the user from being on the wrong side of it, are not optional. They are the architecture. A product that doesn’t have an answer to “what happens when the AI is asked to do something outside its competence zone?” has an architecture that fails the moment a real user tries something the team didn’t anticipate.
Three archetypes, three different products, one frontier
Figure 1 — The Autonomy Spectrum
Three archetypes sit on one continuous line of human autonomy. The Jagged Frontier disciplines all three — the architectural choice is, at its core, a bet on which side of the frontier your task sits.
Pick by Intelligence × Judgment ratio — not by what sounds most impressive
Figure 2 — The Intelligence × Judgment Diagnostic
Mismatches are predictable: Agent on high-judgment work produces user revolt; Copilot on low-judgment work concedes the cost-structure advantage to a leaner competitor.
How each architecture handles the same task — and what the PM owns at each one
Figure 3 — Three Workflows
Three legitimate ways to handle the same task. Unit economics, moat, pricing, and PM discipline are not optional — each follows from the architecture choice upstream.
Archetype 1 — Augmentation
The AI extends a human capability invisibly. The human is the actor. The AI is in the substrate.
What it is
Augmentation is the architectural archetype where the AI does its work underneath the user-facing surface. The user doesn’t think of themselves as using AI. They think of themselves as using a product that happens to be smart. Spell-check is augmentation. Smart compose is augmentation. Recommendation engines are augmentation. Auto-complete is augmentation.
The defining property: invisibility. Not literal invisibility — the user can sometimes see the AI’s outputs (a suggested word, a recommended product) — but cognitive invisibility. The user doesn’t have to interact with the AI as the AI. They interact with the product, and the product is smart.
What it demands
- Pricing: typically wrapped into the core product price. The AI is part of why the product is good; the user can’t easily isolate the AI value, so they don’t pay for it as a line item.
- Evals: narrow and capability-specific. Precision, recall, latency for the one slice the AI is doing. You don’t need a million-input eval suite for a spell-checker — you need a focused suite that catches the specific failure modes that matter.
- Trust: low-stakes by design. The user can ignore the AI’s output without losing anything important.
- Latency: demanding. The AI has to keep up with human typing speed, scrolling speed, clicking speed. Augmentation that lags becomes friction.
- Team structure: straightforward. ML team integrates with product team, normal collaboration cadence. No special governance.
- Moat archetype: tends toward Design (how the augmentation is integrated into the user’s flow) and Data (specific behavioural data on what the user accepted vs. ignored).
When it wins
When the slice of work the AI does is small, well-defined, high-frequency, and falls clearly inside the AI’s competence zone. The Jagged Frontier is barely a concern because the AI never approaches the frontier — it stays deep inside its competence.
When it fails
When the team tries to extend Augmentation to broader workflows where the user actually needs visible AI agency. Augmentation works because it’s narrow. Stretching it produces an awkward middle ground where the AI is too involved to be invisible but not involved enough to feel like a real assistant.
Archetype 2 — Copilot
The AI suggests. The human acts. Suggestions are the unit of value; the human’s judgment is the gate.
What it is
Copilot is the archetype where the AI is visible and the user explicitly interacts with it as an AI. The AI proposes, the user disposes. The product centres on a suggestion-and-action loop: the AI generates a suggestion, the user reviews, the user accepts or modifies, the user takes the action.
GitHub Copilot is the canonical naming source. ChatGPT in its conversational form is a Copilot — every response is a suggestion the user can accept, edit, or discard. Cursor in its earlier form was a Copilot. Most current chatbot deployments are Copilots, even when they’re branded as something else.
The defining property: human-in-the-loop on every action. The user is always the one who actually does the thing. The AI’s outputs are inputs to the human’s decision.
What it demands
- Pricing: per-seat, per-action, or hybrid. Suggestions are countable. Per-seat works because the user is the unit of value. Per-action works for higher-stakes Copilots where the suggestion has clear value.
- Evals: broader than Augmentation. Suggestion quality across diverse inputs. Acceptance rate by user. Edit distance between suggestion and final action. Time-to-action with suggestion vs. without.
- Trust: medium-stakes. The user is reviewing every suggestion before acting, so the cost of a bad suggestion is bounded by the user’s review time. But the Jagged Frontier is more salient here — bad suggestions outside the AI’s competence zone can mislead the user, especially under time pressure.
- Latency: still demanding, but less than Augmentation. Suggestions can take a beat. The user is in a deliberation pose, not a flow pose.
- Team structure: ML team + product team + a designer dedicated to the suggestion-and-action UX. The interaction surface where suggestions appear is high-leverage; it deserves a specialist.
- Moat archetype: tends toward Data — which suggestions get accepted vs. rejected by which users in which contexts is gold-standard behaviour-outcome data.
When it wins
When the user wants to remain in control. When the cost of an autonomous error is high. When the suggestions accelerate work that the user was going to do anyway. When the user’s expertise is what makes the suggestion useful.
When it fails
Three failure modes:
- Latency makes suggestions feel slow. If the user has finished typing the next word before the suggestion arrives, the suggestion is friction.
- Rejection rate is too high. When users feel they’re correcting the AI more than benefiting from it, the Copilot becomes a tax. The Agent Tax framing applies here directly.
- The user actually wants the AI to act. The Copilot architecture forces a review step on every action. For workflows where the user wants completed work, not reviewed suggestions, the Copilot adds friction the user resents.
The third failure mode is the one most teams hit on the way to Agent — the Copilot architecture becomes the constraint that’s holding the product back, and the team has to decide whether to reshape into an Agent or stay a Copilot with cleaner mechanics.
Archetype 3 — Agent
The AI acts. The human supervises selectively. Actions are the unit of value; human intervention is the exception.
What it is
Agent is the archetype where the AI takes actions in the world (or in the system) without per-step human approval. The user delegates a task. The AI plans, executes, and reports back. The human supervises selectively — checking on progress, intervening when something seems wrong, reviewing outcomes after the fact.
Customer-service agents that resolve full tickets without escalation are Agents. Research agents that go off and produce a report are Agents. Agentic coding tools that take a task and ship a PR are Agents. The newer modes of Cursor, Claude Code, and most “AI does the work” deployments are Agents.
The defining property: agency. The AI doesn’t ask permission for each step. It takes actions. The human’s role is to set the goal, set the boundaries, and intervene by exception.
What it demands
This is where the architectural complexity steps up materially. Agents are not Copilots with looser permissions — they’re a structurally different class of system, and they demand structurally different infrastructure.
Anthropic’s published guidance is the cleanest practitioner reference I’d point any AI PM at. In their Building Effective Agents essay, Anthropic identifies five architectural patterns for agentic systems:
- Prompt Chaining — break the task into a linear sequence of LLM calls, each consuming the previous output.
- Routing — classify the input, send to different specialised paths.
- Parallelization — run multiple LLM calls concurrently when subtasks are independent.
- Orchestrator-Workers — one LLM directs multiple worker LLMs on subtasks, then synthesises.
- Evaluator-Optimizer — one LLM produces output, another LLM evaluates and asks for revisions.
The patterns are listed in rough complexity hierarchy. Anthropic’s own guidance — and this is the guidance most teams ignore at their own cost — is to start with the simplest pattern that could plausibly work. Chaining and routing are easy to build, observe, and debug. Orchestrator-workers and evaluator-optimizer are powerful but expensive and operationally complex.
A team that reaches for orchestrator-workers when chaining works has multiplied their cost, multiplied their failure modes, and made debugging significantly harder — for no marginal value the user can perceive. Pattern over-architecture is one of the most expensive failure modes in agent development today.
- Pricing: per-outcome, hybrid, or outcome-based. The user is paying for completed work, not for suggestions or for capability access.
- Evals: complex. Multi-turn, multi-step, includes failure recovery, includes safety boundaries, includes the question “how often does the agent successfully complete an end-to-end task without human intervention?” — the AI Agent Autonomy Rate.
- Trust: high-stakes. The user is delegating action. The cost of an autonomous error compounds across multiple actions before the human catches it. The Jagged Frontier is most dangerous in Agent architectures.
- Latency: less demanding per-step than Copilot, more demanding end-to-end. The user has more patience for one step, less for total time-to-completion.
- Team structure: ML team + product team + a dedicated safety/eval function + an ops function that monitors agent behaviour in production. The ops function is the one most teams skip and most regret skipping.
- Moat archetype: tends toward Distribution (being the canonical agent for a workflow inside AI surfaces) and Dogfooding (the team running on the agent themselves, which is the only way to find the production failure modes fast enough).
When it wins
When the user genuinely doesn’t want to be in the loop for each step. When failure modes are bounded and recoverable. When the value of one completed task is high enough to justify the supervision overhead.
When it fails
The list is longer than for the other archetypes:
- Premature reach. Teams build Agents before they’ve mastered Copilots. Failure modes aren’t bounded. Supervision burden eats the value.
- Frontier blindness. Teams deploy outside the AI’s competence zone, hit the 19-pp accuracy drop, and reverse course at brand cost.
- Pattern over-architecture. Teams use orchestrator-workers when chaining works. Cost balloons. Observability collapses. Debugging becomes impossible.
- Missing ops layer. Teams ship the agent and don’t ship the monitoring. The first major failure happens in production, on a customer call, with no telemetry to diagnose it.
The first failure mode is the most common. Teams want to ship Agents because the demos are impressive and the strategic narrative is more interesting. The right move is almost always to ship a high-quality Copilot first and only graduate to Agent when the workflow genuinely demands it.
The SAE analogy — and where it usefully breaks
A useful cross-domain import: the SAE J3016 standard for autonomous driving, which defines six levels from Level 0 (No Automation) to Level 5 (Full Automation).
The autonomous-driving industry’s hardest problem turned out to be Level 3 — conditional automation, where the car drives itself most of the time but the human must take over when the car requests. Level 3 is empirically the most dangerous level, because the human has to maintain attention they’re cognitively unable to maintain.
The same dynamic plays out at the Copilot/Agent boundary in AI products. A product that’s trying to be both — sometimes Copilot, sometimes Agent, with the user expected to know which mode is active and intervene appropriately — is the AI-product equivalent of Level 3 autonomy. The user can’t reliably maintain the right mental model. Errors compound.
Where the analogy breaks is also informative: in driving, autonomy is a property of the vehicle. In AI products, autonomy is a property of the interaction — and it can change per task, per user, per session. The PM’s job is harder than the autonomous-driving engineer’s, because the autonomy level isn’t fixed. It has to be designed into the architecture in a way that makes the user’s mental model match the system’s actual behaviour at every moment.
Be explicit about which archetype you’re at, and don’t try to be all archetypes at once.
A product with a clear architectural identity is one the user can develop a stable mental model for. A product that drifts between archetypes is one the user can’t. The hardest level to operate in autonomous driving is Level 3 — for the same reason the hardest place to operate in an AI product is the Copilot/Agent boundary. Cognitive handoff between human and machine is where errors compound.
How architecture connects to the rest of the strategy
Architecture is the Design dimension of the 4D framework (L2-T01). It sits upstream of pricing (L2-T04), FinOps (L2-T05), evals (L2-T06), and the outcome-based pricing playbook (L2-T09). Each archetype also pulls a different set of compounding moats (L2-T02) — Copilot moats live in workflow integration; Agent moats live in harness mastery (L1-T01) and outcome economics; Augmentation moats live in brand and accumulated user style. The matrix below is the diagnostic I’d run on any AI product:
| Dimension | Augmentation | Copilot | Agent |
|---|---|---|---|
| Pricing | Bundled into core product | Per-seat / per-action / hybrid | Per-outcome / hybrid / outcome-based |
| Eval focus | Capability precision/recall/latency | Suggestion quality, acceptance rate, edit distance | Multi-turn task completion, failure recovery, Autonomy Rate |
| Trust mechanism | Low-stakes; user can ignore | Human review on every action | Boundary setting + selective supervision |
| Latency budget | Real-time (compete with typing speed) | Sub-second (compete with deliberation) | Per-step relaxed; end-to-end strict |
| Team structure | ML + product (normal collaboration) | ML + product + interaction designer | ML + product + safety/eval + ops |
| Moat archetype | Design + Data | Data | Distribution + Dogfooding |
| Jagged Frontier risk | Low (narrow zone) | Medium (user catches errors) | High (errors compound across actions) |
If your product’s actual choices don’t match the column for the archetype the team has named, you have architectural ambiguity. The fix is to either rename the archetype to match the choices, or to bring the choices back in line with the archetype.
Two production patterns to study. Cursor’s evolution is the public case study for the Copilot → Agent transition: it launched suggestion-driven, added Agent mode for autonomous multi-file edits, and re-engineered both the harness (the token tsunami response, L1-T07) and the pricing model (the per-seat-to-tiered-usage move, L1-T09) to make the transition pay. Both archetypes coexist in the same product. Apple Intelligence is the opposite case — Augmentation done well. The user never “uses the AI”; AI amplifies specific iOS tasks (writing tools, image edits, summarisation) without replacing user agency. The architecture matches a high-judgment consumer workflow.
The board narrative writes itself once the architectures are named: “Agent for routine support cases produces structurally lower cost per outcome because no human is in the loop. Copilot for high-stakes cases preserves the rep’s judgment and the customer relationship. Both architectures coexist; the routing logic between them is the strategic asset.”
The four traps in product architecture
Four failure modes show up over and over in AI product development. Each has a clean diagnostic and a clean fix. Each is cheaper to catch in a workshop today than in a redesign next quarter.
Trap 1 · Architectural ambiguity
The PM thinks the product is Copilot. The designer is building toward Agent. The engineer is shipping Augmentation under the hood.
The pricing is per-seat. The eval suite is for suggestions. The user experiences a confused product and the team can’t agree on what to fix.
Diagnosis: the team can’t articulate the archetype in one sentence, with agreement.
The fix: stop the next sprint. Hold a one-hour architectural-archetype workshop. Use the Intelligence vs Judgment lens to identify where Judgment has to stay. Pick one archetype. Realign every downstream decision to match.
Trap 2 · Premature Agent reach
The team wants to ship an Agent because Agents are strategically more interesting. The workflow doesn’t actually need full agency.
The Copilot version would deliver 80% of the value at 20% of the operational complexity. The team builds the Agent anyway. Failure modes aren’t bounded. Supervision burden eats the value.
Diagnosis: your team is reaching for Agent without first mastering Copilot in the same workflow.
The fix: ship the Copilot first. Run it for one quarter. Identify the specific friction that the Copilot can’t solve. That is the case for graduating to Agent — and the case will be much more defensible after you’ve earned the Copilot success.
Trap 3 · Frontier blindness
The team deploys the AI on workflows the team hasn’t tested it against. The 19-pp accuracy drop materialises when a real user asks a question outside the AI’s competence zone.
The error compounds. The brand takes the hit. The team only finds out about the frontier after they’ve crossed it in production.
Diagnosis: the team can’t articulate the boundaries of the AI’s competence zone for this specific deployment.
The fix: before launch, run a deliberate frontier audit. Test the AI on inputs at the edge of its expected use. Document where it fails. Add explicit graceful-degradation paths for those edge cases. The eval suite from Evals as the New PRD (L2-T06) is the structured form of this audit.
Trap 4 · Pattern over-architecture
The team uses orchestrator-workers when chaining works. The system has 5× the cost, 3× the latency, and observability that’s so split across LLM calls that nobody can debug a failure when it happens.
This is the trap that hurts most teams who pride themselves on engineering ambition. Sophistication for its own sake costs more than it earns.
Diagnosis: your agent uses Anthropic patterns 4 (orchestrator-workers) or 5 (evaluator-optimizer) without first proving that patterns 1–3 (chaining, routing, parallelization) couldn’t carry the workflow.
The fix: simplify until something breaks. Start from chaining. Add complexity only when chaining provably can’t handle a class of inputs. Anthropic’s own guidance is “start with the simplest architecture that could plausibly work” — there’s a reason that sentence is in their official agent essay.
Run the architectural alignment audit on your top AI feature.
For your top AI feature, answer these four questions. The audit is brutal precisely because it’s simple — the disagreement it surfaces is the work the team needs to do.
-
01
Archetype. Which of the three is it — Augmentation, Copilot, Agent? State it in one sentence.
-
02
Team agreement. Do engineering, design, product, and sales all give the same answer to question 1? Ask each lead separately, then compare.
-
03
Pricing alignment. Does your pricing model match the archetype? Bundled for Augmentation, per-seat or per-action for Copilot, per-outcome or hybrid for Agent.
-
04
Eval alignment. Does your eval suite match the archetype? Narrow capability for Augmentation, suggestion quality for Copilot, multi-turn task completion for Agent.
If question 2 surfaces disagreement, you have architectural ambiguity. That’s the first fix. If question 3 or 4 surfaces misalignment, you have an archetype/strategy mismatch. Either change the archetype to match the strategy, or change the strategy to match the archetype. Don’t ship the mismatch and hope it resolves itself.
You can do this in ten minutes. Most teams have never done it explicitly. The ones that do typically discover one of two things: the team disagrees on what archetype the product is, or the product is one archetype but the strategy was built for another. Both findings are good news. They’re cheaper to fix in a workshop today than in a redesign next quarter.
The sentence to carry
Architecture is upstream. The teams that make this choice explicitly ship faster and waste less than the teams that drift into one through accumulated decisions.
The frame for product architecture in 2026If you remember one frame from this post, make it that one. The three archetypes — Augmentation, Copilot, Agent — are the structural answers. The Intelligence vs Judgment lens is the diagnostic. The Jagged Frontier is the empirical fact that disciplines all three.
Sources
- Vlad Podoliako on Intelligence vs Judgment. “Sell the Work, Not the Tool” — primary framing reference.
- Services-as-software wave analysis. Tomasz Moser, “Services Are the New Software” — supporting reference on Intelligence/Judgment in service work.
- The Jagged Frontier — HBS Working Paper. Dell’Acqua et al., “Navigating the Jagged Technological Frontier” — HBS / BCG field experiment.
- The Jagged Frontier — Organization Science. 2026 publication of the same study.
- Building Effective Agents. Anthropic, “Building Effective Agents” — five agentic patterns and the “start with the simplest” guidance.
- SAE J3016 — Levels of Driving Automation. SAE International, J3016 — the autonomy-spectrum analogy.
- Apple — Private Cloud Compute. Apple Security Blog — the canonical Augmentation-done-well case for consumer AI.
- Cursor — Pricing & Architecture. Cursor blog — the public Copilot → Agent transition case study.
- GitHub Copilot — Architecture Overview. GitHub Docs — the canonical Copilot reference implementation.
- Andrej Karpathy — Software 3.0. karpathy.ai — the architectural reframe behind the three archetypes.