Level 2: Purpose and Scope of the Programme

In Level 1 you learned what an agent solution is: a model, instructions and context, tools, state or memory, control logic, and an execution environment, assembled to deliver a business capability. This level steps back one pace and asks a different question: what is this programme actually trying to make you capable of, and why is it deliberately vendor-neutral?

This is not filler. Almost every expensive mistake in agent delivery comes from skipping the framing: teams learn one product's buttons, then discover they cannot reason about the capability the product was providing. Getting the scope clear now makes the following forty levels far cheaper to absorb.

Why the material is taught without organisation-specific products or terminology

The programme states its own purpose plainly: it teaches the architecture, engineering and operational practices needed to build production-ready AI-agent solutions without depending on any organisation-specific product, policy, process or terminology.

There are four reasons this matters, and you should be able to state them.

1. Capabilities outlive products. "We need governed model access" is a durable requirement. "We use vendor X's gateway" is this quarter's implementation. If you learn the requirement, you can re-implement it anywhere.
2. Selection must be driven by context, not habit. The material's technology note is explicit: product names are representative examples, not mandatory recommendations, and capabilities should be selected according to workload, risk, team skills, deployment environment and operational requirements. Those five selection inputs are worth memorising — they reappear whenever you justify a choice.
3. Transferability. Learners here include software engineers, platform engineers, solution architects, data and AI engineers, product owners working with agentic solutions, and security, risk and operational colleagues supporting AI delivery. A shared vendor-neutral vocabulary lets those roles argue productively with each other.
4. No single assembled platform is offered as the answer. The programme instead breaks an agent platform into constituent architectural capabilities and shows how representative open-source, cloud-native and commercial technologies can be combined.

Do this now: write, in one sentence and with no product names in it, the capability your current or imagined project most needs. If you cannot phrase it without a product name, you have found a gap in your own model.

Analogy: the kitchen, not the appliance

Think of a commercial kitchen. A vendor-neutral training programme teaches stations: cold preparation, hot line, plating, dishwashing, food-safety records. Any kitchen you walk into has those stations, though the oven brands differ wildly. Product training teaches you one oven. Capability training teaches you what the oven is for, so that when the oven changes — and it will — the meal still goes out. In agent work, the "stations" are things like model access, tool access, runtime, evaluation and observability.

The path from idea to production

The programme preserves the essential goals of a mature enterprise agent platform, and the first of those goals is a consistent path from idea to production. "Consistent" is the load-bearing word: not fast, not clever — repeatable, so that the tenth solution is safer than the first.

The material's recommended learning sequence describes that path. Follow it in this order:

1. Learn the essential mental model.
2. Study patterns before products.
3. Compare frameworks by workload shape.
4. Learn tools, MCP and A2A.
5. Design context, state and memory.
6. Understand gateways and guardrails as separate capabilities.
7. Walk the generic architecture end to end.
8. Add evaluation, security and delivery.
9. Add observability and operational controls.
10. Complete the capstone and final assessment.

Notice the shape of it. Concepts first, implementations second — that is the stated delivery style: framework-neutral concepts first, representative implementations second. Patterns come before products (step 2 before step 3). Evaluation appears before observability (step 8 before step 9), because the programme's goals include evaluation before release and observability after release. Those are two different activities at two different times, and conflating them is a classic error.

The runtime request path, for contrast

Do not confuse the delivery path above with the request path a live solution follows. Later levels walk the request flow in full, but hold this contrast now: the delivery path is how a solution gets built and released; the request flow is what happens each time a user asks for something. Both are sequences; only one of them is your learning route.

Do this now: map your own current position onto the ten steps. If you are shopping for a framework before you can articulate a pattern, you are attempting step 3 without step 2.

The capability areas in scope

The programme preserves eleven essential goals of a mature agent platform. Read them as a scope statement — anything on this list, you are expected to be able to design; anything not on it is out of scope.

• A consistent path from idea to production
• Safe and governed model access
• Reusable agent and tool patterns
• Framework choice based on workload shape
• Repeatable deployment
• Evaluation before release
• Observability after release
• Identity, security and auditability
• Human control over consequential actions
• Interoperability between agents, tools and enterprise systems
• Clear ownership throughout the lifecycle

Four of these deserve a sentence of clarification, because learners routinely misread them.

• "Framework choice based on workload shape" — not based on popularity, not based on the language you like. Shape means things like how long the task runs, how many steps it has, whether it needs durability, whether multiple agents co-operate.
• "Human control over consequential actions" — the control is targeted at consequential actions. Requiring a human to approve every trivial retrieval is not governance; it is a queue.
• "Interoperability between agents, tools and enterprise systems" — three distinct directions of integration, not one.
• "Clear ownership throughout the lifecycle" — the programme is blunt that a shared platform does not remove solution-team accountability.

Solution versus platform

The scope covers both, and they are different things. An agent solution implements a business capability. An agent platform provides reusable capabilities needed by many agent solutions: framework templates, model access, tool connectivity, runtime hosting, identity, guardrails, evaluation, observability, deployment automation, audit, cost management, and discovery and reuse. The stated design rule: the platform should reduce duplicated engineering without removing ownership from the solution team.

Worked example: two teams, same idea

A logistics business wants an assistant that answers "where is my shipment?" and, when a delivery has failed, re-books it.

Team A starts product-first. They pick a framework because a colleague used it, build a working demo in three days, and demo it to executives. Six weeks later, three problems surface at once:

• Model calls go directly from application code to a provider with a shared key. There is no record of who asked what, and no way to cap spend. They have no governed model access.
• The re-booking tool executes immediately on the model's decision. One customer got three vans. They have no human control over consequential actions.
• Asked "has quality improved since last week?", they can only say the demo "feels better". They have no evaluation before release.

Each fix now requires re-architecting code that already carries production traffic.

Team B starts capability-first, using the scope list as a checklist:

1. They classify the two jobs by shape: shipment lookup is read-only retrieval; re-booking is a consequential, side-effecting action. Different risk, therefore different controls.
2. They route all model traffic through a model-access capability so every call is attributable and capped — before choosing which framework calls it.
3. They gate re-booking behind human approval, and leave lookups ungated. Targeted control, not blanket control.
4. They build a small set of representative cases with expected outcomes, and treat passing them as a release gate.
5. Only then do they compare frameworks — and their comparison criterion is workload shape: does this workload need multi-step durability and checkpointing, or will a lightweight single-agent loop do?
6. They name an owner for the solution, even though the platform team supplies model access and observability.

Team B is slower to demo and dramatically faster to production — because their design already answers the questions the release process will ask. That gap is exactly what "a consistent path from idea to production" buys.

Misconceptions an expert would flag

• "Vendor-neutral means anti-vendor." No. Representative options are named throughout — Google ADK, LangGraph, Microsoft Agent Framework, OpenAI Agents SDK, CrewAI, LlamaIndex, Pydantic AI, MCP, OpenTelemetry and so on. They are examples of how to satisfy a capability, not a shopping list.
• "Learning the concepts means never touching a product." The method is deliberately hands-on: learn, compare, design, build, evaluate, operate and explain. "Build" and "operate" are in there.
• "A working prototype is a production service." The material explicitly denies this. It is one of its critical distinctions.
• "Evaluation is just scoring the final answer." Also explicitly denied. Evaluation covers far more, including tool selection and execution trajectory — later levels go deep on this.
• "The platform team is accountable once we adopt the platform." Ownership stays with the solution team, throughout the lifecycle.
• "More autonomy is better." From Level 1: autonomy is a design choice, not a requirement to maximise.

How you will be judged ready

The programme is honest about its bar. The readiness threshold is at least 85% on the final assessment plus successful completion of the capstone design. The format is ten modules, practical architecture exercises and a final assessment.

Completion evidence — the behaviours that show you are ready — includes being able to:

• Explain the eleven-layer architecture without notes
• Distinguish framework, runtime, gateway, tool plane and operations
• Select the least complex adequate agent pattern
• Compare at least two frameworks fairly
• Produce an evaluation and security design
• Trace a request end to end
• Explain platform value without relying on a single vendor product

Read that list as your syllabus in disguise. "Select the least complex adequate pattern" is a value judgement the whole programme is built to install: complexity is a cost you must justify, not a badge.

Do this now: pick the two items on the completion-evidence list you could not do today. Those are the levels to read twice.

Key takeaways

• The programme teaches practices without organisation-specific product, policy, process or terminology, so that capabilities — which endure — are learned rather than product interfaces, which change.
• Technology should be selected by workload, risk, team skills, deployment environment and operational requirements; named products are representative examples only.
• No single assembled platform is offered as the answer; an agent platform is broken into constituent architectural capabilities.
• The learning path runs: mental model → patterns before products → framework comparison by workload shape → tools, MCP and A2A → context, state and memory → gateways and guardrails as separate capabilities → end-to-end architecture → evaluation, security and delivery → observability and operational controls → capstone and assessment.
• Scope covers eleven platform goals, including governed model access, reusable agent and tool patterns, framework choice by workload shape, repeatable deployment, evaluation before release, observability after release, identity/security/auditability, human control over consequential actions, interoperability, and clear ownership.
• An agent solution implements a business capability; an agent platform supplies reusable capabilities and must not remove solution-team ownership.
• Readiness is at least 85% on the final assessment plus a completed capstone design.