Curriculum for Certified Professional for Software Architecture (CPSA)^® Advanced Level
AGENTA – Architecture for Agentic Software Engineering Contexts

AI-assisted, augmented, agentic coding

AI orchestration

Agentic workflow design

Agentic engineering vs vibe coding

Harness, context, prompt, and human-in-the-loop engineering

Participants can explain the terms AI, ML, GenAI, and LLMs and classify how they relate to each other.

Participants know the terms data, model, training, and inference.

Participants know that data is the central foundation of AI (garbage in, garbage out).

Participants understand LLMs as probabilistic tools whose outputs are samples from a distribution and can explain the implications for architecture work.

Participants know basic concepts of LLMs such as tokens, prompts, context, and reasoning.

Participants know the most important characteristics of LLMs and can make well-founded decisions about using specific providers and models.

Participants know the capabilities (e.g., language, knowledge, structured output) and limitations of LLMs (e.g., hallucinations, bias, knowledge cutoff, context window).

Participants can weigh whether tasks should be done by humans, classic software tools, or LLM agents.

Participants understand the concept of “context engineering” and know why it matters.

Participants know a selection of prompt-engineering techniques to optimize the quality of outputs, e.g., role playing, consistency, or repeating.

Participants know the difference between assistants and agents.

Participants have a basic understanding of the agentic loop (ReAct pattern): prompting, reasoning, tool usage, state management (memory).

Participants are familiar with advanced techniques such as planning, sub-agents, hand-offs, and human-in-the-loop.

Participants have a basic understanding of the structure and functioning of modern coding agents.

Participants know the strengths and broad applicability of the agent-based approach in software development and architecture work.

Participants understand autonomy as a spectrum with multiple levels and can place tools/workflows appropriately. They understand how the levels differ across typical activities (from idea to feedback).

Participants can name concrete current practices in agentic engineering, such as Spec-Driven Development, Agent Swarms, Conversational Programming, and related workflows, and classify them within the autonomy spectrum.

Participants know which activities are typically referred to as "architecture work" and understand that AI can affect these activities.

Participants can explain how AI assistants and agents can support core architecture activities, such as quality goal definition, decision documentation, and architecture reviews. They can identify which activities can be supported, accelerated, or partially automated by AI, and where human architectural judgment remains necessary.

Participants can map architecture work to agentic engineering. Instead of merely augmenting traditional activities, they can anchor architecture work in agentic processes and tools — for example, by embedding architecture principles through context engineering, supporting architecture decisions with guardrails, evaluating alternatives by implementing them in agentic loops, and continuously validating architectural assumptions through automated feedback.

understand the phases of the decision lifecycle: problem identification, option exploration, (in)validation of alternatives, decision making, decision establishment, deprecation, and iteration

understand the effect of agentic engineering: It can accelerate exploration and (prototype) development, and - paired with continuous validation - can increase decision cycle frequency

understand that it is important to establish feedback loops from development, testing, and operations into ongoing architectural reasoning

can explain how these effects make it possible to establish a continuous, evidence based architecture process, and why this is a good thing.

can decompose quality goals into concrete, assessable criteria, like quality scenarios

can identify conflicts or contradictions between quality goals, constraints, and architectural intentions

know how to use these drivers to support goal-oriented design and development of software solutions (see chapter 3)

understand why it is important to have different concepts in the agentic workflow to handle architectural drivers & goals on one side and architectural decisions & concepts on the other side.

can explain bottom-up needs for architectural work, especially in agentic engineering contexts: structural weaknesses, unintended drift, or emerging complexity in evolving systems

know established tools to identify architectural drivers: technical debt assessment, static structural analysis, monitoring-based feedback and dynamic analysis, metrics and test coverage analysis, architecture reviews

can use AI-assisted techniques to support bottom-up driver identification: AI-driven architecture reviews and structural assessments, consistency checks and quality assessments

Generating and refining architectural options for a given problem situation

Evaluating candidate options against drivers, existing decisions, constraints, and architectural principles

Understanding the limits of AI-generated suggestions and the omnipresent nature of trade-offs in architectural decisions

Framing architectural decisions as hypotheses with assumptions, expected outcomes, and measurable criteria for validation or invalidation.

Replacing potentially existing meeting-based approaches for architectural design with experimental loops

Designing lightweight experiments such as spikes, simulations, prototypes, and side-by-side variant comparisons

Identifying architectural risks and using targeted experiments to address them

Using experimental outcomes to support, weaken, revise, or revisit architectural decisions and understand that these agentic experiments can be cheaper than highly developed "specs"

Known risks include model-inherent aspects that need attention: hallucinations, bias, sensitivity to prompt structure and instruction ordering, differences in context effectiveness, potentially sponsored technologies, …​

Participants know the value and risks of switching models during a decision process

Participants are able to define review checkpoints and know how to maintain human responsibility over consequential architectural decisions by enforcing these checkpoints and using additional methods (e.g., setting boundaries for agentic decisions, enforcing guardrails)

The course participants can distinguish whether they are directing agents through a fixed plan or composing the agent workflow itself, and can select the appropriate style for a given context.

The course participants can reason about the effects of orchestration on throughput (especially regarding fewer hand-offs causing less friction), traceability, and the development process as a whole.

The course participants know about orchestration variants and can identify meaningful checkpoints at which human judgment is required.

The course participants can identify failure modes specific to orchestration (e.g. runaway agents, infinite loops, lost human override points, cascading errors across orchestrated steps) and can design containment mechanisms that limit their impact.

The course participants can specify targets, constraints, and acceptance criteria rather than prescribing the exact path, and can explain why this style of guidance is more effective when working with AI agents.

The course participants understand that orchestration design has direct cost and sustainability implications (token consumption, agentic loop length, tool-call frequency) and can take these into account when shaping orchestration patterns. See also LG 7-4.

Participants can explain the relationship between the information an agent receives and the quality and architectural consistency of its output.

Participants understand why providing architectural knowledge to agents is a design problem that requires engineering discipline, not just writing instructions.

Participants can explain the inherent limitation: providing knowledge increases the probability of good results but cannot guarantee them.

Participants can identify which architectural decisions, constraints, quality goals, principles, domain concepts, integration rules, and system boundaries are relevant for AI agents working in a given codebase, and can assess which are missing.

Participants can evaluate different forms of representing architectural knowledge for agent consumption and assess their trade-offs in terms of precision, maintainability, and effectiveness.

Participants can select suitable representation forms, such as ADRs, architecture rules, context files, knowledge bases, retrieval indexes, diagrams-as-code, or structured constraints.

Participants can assess different strategies for delivering architectural knowledge to agents (e.g. Retrieval Augmented Generation, Skills) and can select appropriate strategies for different situations.

Participants can reason about who or what should decide when specific knowledge is loaded, and can explain the trade-offs involved.

Participants understand the architectural implications of standardized integration protocols (e.g. Model Context Protocol) for agent-tool communication and can identify where such mechanisms add value in an organization.

Participants can evaluate whether the architectural knowledge currently available to agents in a project is sufficient, well-structured, and effectively delivered.

Participants understand that more knowledge is not always better. Irrelevant or contradictory information degrades agent performance. They can design strategies that balance comprehensiveness with signal quality.

Participants can design an iterative process for improving architectural knowledge delivery based on observed agent behavior.

Participants are aware that shared documents are not shared understanding and that establishing such involves other disciplines and methodologies (e.g. Domain-driven Design, Collaborative Modeling)

Participants can explain why AI agents, without explicit constraints, tend to produce work that violates architectural decisions, accumulates technical debt, and introduces inconsistencies.

Participants can describe the factors that determine an AI agent’s behavior (e.g. context and tools) and identify where architects can intervene most effectively.

Participants understand the relationship between providing architectural knowledge to agents and constraining agent behavior, and can explain why knowledge alone (e.g. in agent’s context) is insufficient.

Participants understand that explicit architectural controls can hinder evolvability and are therefore a temporary, "sinking" investment — maintained only until models and agents can reliably enforce the controls themselves, and reduced as their capabilities grow.

Participants can design preventive and detective controls that work together to keep AI agents within architectural boundaries and aligned with architectural decisions, quality goals, and system constraints.

Participants can assess the trade-offs between different types of enforcement mechanisms, in particular the trade-off between precision and coverage, and between speed and depth of analysis.

Participants can select appropriate enforcement mechanisms for different architectural concerns (e.g., structural rules, quality attributes) and can explain why some are harder to enforce than others — atomic structural rules allow fast, deterministic checks, whereas holistic quality attributes like maintainability or usability yield only holistic feedback that is hard to obtain automatically (cf. atomic vs. holistic fitness functions).

Participants know about examples for enforcement mechanisms, such as architecture tests, static analysis, linters, dependency rules, policy checks, review gates, sandboxing, and manual approval workflows.

Participants can design architectural controls at appropriate points in the development and delivery process, and can justify why different controls belong at different points.

Participants understand that AI-assisted development can cause architectural drift at a pace that exceeds traditional review cycles, and can design mechanisms for continuous verification.

Participants can assess how amenable an existing codebase and technology stack are to architectural control of AI agents, and can identify the properties that make control easier or harder.

Participants can design a strategy for incrementally introducing architectural controls to systems that were not built with AI-assisted development in mind, and can prioritize which controls to establish first.

Participants can reason about the trade-off between the effort of establishing controls and the risk of operating AI agents without them.

Participants can design feedback processes where failures in AI-generated work inform improvements to the control system itself.

Participants can reason about the extent to which the improvement of controls can itself be automated, and where human architectural judgment remains essential.

Distinguish as-is documentation (current system state — benefits most from AI-tool support) from to-be documentation (vision, target architecture - AI plays a fundamentally different and smaller role)

Understand that vision documents require active human processes: talking, discussing, evaluating, deciding. The quality of the resulting document depends on the quality of those human interactions — AI can support but not replace them

Know that for human-facing documentation, audience-oriented format (who reads it, for what purpose, in what context) is at least as important as quantity

Know that agent-facing documentation (e.g. as context for coding agents or AI-assisted workflows) has more options than traditional formats or templates, and that concise, machine-readable representations often outperform traditional documents

Understand that long agentic iteration loops can drift the architecture away from original decisions, and know why this must be deliberately tracked and surfaced

Know how AI can help detect when existing decisions are being implicitly changed during agentic development, and flag these for human review

Use ADRs as a core tool for capturing decisions arising from agentic development loops: context, alternatives, rationale, and consequences — including decisions that emerge incrementally rather than in a single moment

Know how AI can support ADR drafting by collecting and synthesizing information from diverse agentic context sources: context logs, guardrail outputs, chat histories, emails, and meeting minutes. Understand that the resulting draft must go through a human-in-the-loop review — for validation, correction, and completion

Understand the limitations of AI-generated ADR content: organizational commitment, stakeholder buy-in, implicit knowledge, and the social contract that makes a decision binding cannot be generated or substituted by AI — these require human processes

Understand how to maintain traceability between implementation artifacts and the decisions that shaped them, even when those decisions were made across many short agentic iterations

Know where to place human review checkpoints in agentic loops to ensure accountability for consequential architectural decisions is never fully delegated to the agent

Summarize and analyze available system artifacts: source code, deployment descriptors, configuration, tests, and interfaces

Interpret structural information from code, repositories, interfaces, and dependency graphs; combine findings into usable representations such as knowledge graphs or structure models, and keep them continuously up-to-date

Combine AI-generated insights with traditional static and dynamic analysis to improve accuracy and coverage

Detect technologies and frameworks using code property graphs (e.g. Joern, see [Joern]) or AI coding agents; recognize recurring architectural and design patterns in a domain-informed way; relate findings to architectural structures and modernization concerns

Extract candidate business rules from code, tests, and configuration; relate them to documented domain concepts and business processes; prepare them for validation with domain experts and stakeholders

Identify gaps, inconsistencies, and uncertainties in recovered information, and validate findings using static/dynamic analysis tools, code inspection, and stakeholder communication

Generate architecture-related documentation and views from code, repositories, interfaces, and other development artifacts, including knowledge representations of these artifacts

Reconstruct and maintain relevant system views in alignment with system evolution; understand the value of text-based diagram formats (e.g. Mermaid, Structurizr) for version-controllable, living documentation

Validate generated views and documentation against developer knowledge and actual system behavior

Understand the value of current system views for analysis, communication, and modernization planning

Participants can explain copyright issues such as copyleft licenses and assess which obligations may arise when using, adapting, and especially distributing software/artifacts in an AI context.

Participants are aware of the resulting legal risks and understand that an AI-augmented architectural process needs to establish controls and processes that shield the generated code and artifacts from copyright-related liabilities.

Participants can, when using AI tools, check from a data protection perspective whether and which personal data are processed, classify roles and responsibilities (controller/processor), and derive when contractual requirements must be clarified.

Participants can apply the EU AI Act in its basic features (roles, risk logic, phased applicability) to typical AI tool scenarios and explain the timeline for application with key dates.

Participants can decide for concrete initiatives when they must involve which internal and external stakeholders (e.g., data protection officer, information security) and can document the results in a way that is audit-ready and decision-ready.

Participants can explain what is meant by traceability of AI outputs and justify why this is important for quality assurance, incident analysis, governance, and auditability.

Participants can evaluate and weigh concrete measures to ensure traceability in a system context, in particular structured logging, consistent referencing of context artifacts, and quoting & citation as a mechanism for verifiable provenance of statements.

Participants can explain why versioning and observability are necessary for AI applications, and can name key components such as prompt/template versioning, model/configuration states, traceable changes, as well as logging, tracing, or monitoring.

Participants can classify and compare token-based billing models versus subscription/seat-based models and select a suitable governance and budgeting model for different team and use-case contexts.

Participants can consider dependency risks (vendor lock-in) and data sovereignty when selecting LLM providers and understand the importance of flexible options to switch providers.

Participants can explain why guardrails are important for agent and tool usage, and can describe how they can help reduce risks such as compliance violations, data leakage, or misuse.

Participants can implement an allowlist/whitelist strategy for tool integrations, describe appropriate authorization and approval processes, and justify the trade-offs between flexibility and control for different organizational areas.

Participants can explain and distinguish the key environmental impacts of AI-supported development across the lifecycle and classify typical misconceptions about them.

Participants can identify and assess the most important drivers of energy and emissions impact in AI-assisted development (e.g., model size, multi-stage/agentic workflows) and create awareness of them within the organization.

Participants can identify and classify sensitive information and decide what must not be shared with AI tools.

Participants can assess data flows and data retention of AI tool usage and identify key risks.

Participants can define team-appropriate rules for selecting and using AI tools in a secure and data-protection-compliant way.

Participants are familiar with the OWASP LLM Top 10 and know which risks are relevant to agentic engineering (among others, prompt injection and tool misuse). They have also heard of the MITRE ATLAS knowledge base.

Participants can recognize prompt-injection attacks (direct and indirect) in agentic systems, explain the associated "confused deputy" risk, and derive requirements for robust prompt/context boundaries (e.g. clear separation of data and instructions, no trust in externally sourced content).

Participants are familiar with suitable measures to reduce these risks (e.g. least privilege, scoped credentials, explicit approvals / human-in-the-loop, monitoring).

Participants can select suitable sandboxing strategies for tool execution and know the advantages and disadvantages of container-based versus VM-based solutions.

Participants understand that the developer stays responsible for the result: "you push it, you own it".

Participants understand the risk of skill atrophy through overreliance on AI and can design personal and team practices (e.g. deliberate AI-free practice, human-first / AI-second reasoning practices, traditional and AI-supported katas, using AI as a learning instrument for explanation, summarization, and questioning) to preserve core engineering skills.

Participants understand the remaining importance of critical thinking (keep asking questions and researching until an understanding of a problem is gained as well as scrutinizing and cross-checking ‘AI-generated results’ against their own knowledge and observations)

Participants understand that agent decisions are shaped by available context and by both biases in training data (e.g. weighting toward particular vendors, frameworks, or stacks) and biases in existing artifacts of the own organization, and can identify situations in which such biases distort architectural choices.

Participants can distinguish AI-supported reasoning from delegated decision-making.

Participants can identify which architecture activities must remain human-owned and know that this might change in the future.

Participants know that shared terminology and a consistent domain vocabulary (e.g. a domain glossary, ubiquitous language) act as anchors that make agent decisions more predictable and aligned with the system’s design (see [Gu et al. 2025]).

Participants know about indicators for whether teams are improving architectural capability, not only producing faster outputs, and that the goal is to maximize outcome and impact for the user rather than output (avoiding what’s increasingly called 'AI slop')

Participants can apply a hypothesis-driven approach to AI adoption (identifying a problem, formulating hypotheses, running experiments, measuring outcomes) and explain why this is preferable to broad, untargeted rollouts.

Participants understand AI adoption as a continuous, multi-stage process (e.g. access, adoption, proficiency, ways of working, organizational change) rather than a one-time initiative, and can position an organization within such a model.

Participants know about enabling measures such as trainings, hackathons, and dedicated time for experimentation, and can argue why protected time for learning is a precondition for sustainable adoption.

Participants know that explicit ownership of AI adoption within a team or organization is crucial for its success.

Participants understand the importance of a learning culture that tolerates mistakes and creates psychological safety for asking questions, and can identify cultural anti-patterns that block adoption.

Participants can balance ease of access (recommending sensible default tooling) with openness to alternatives, and can justify this trade-off.

Participants can support the shift in engineering identity from writing code toward shipping outcomes, and can explain its implications for individuals and teams.

Participants know meaningful indicators for the success of AI adoption (e.g. DORA metrics, lead time, change failure rate, developer experience signals) and can use them to validate the hypotheses driving adoption.

Participants know new collaboration patterns that combine humans and AI (e.g. Human + Human + AI pairing) and can identify safeguards that ensure people continue to talk to each other rather than only to the agent and that insights encountered within an AI session might be shared with the human developer team. Correspondingly the participants know about agent topologies (e.g. Solo, Sub-Agent, Agent Teams)

Participants know that collaboration patterns must match team context and that different team roles can perform different AI-supported activities (e.g. that product roles might trigger agent workflows, that developers might draft features).

Participants can shift their own focus from line-level coding toward a broader architectural, generalist and product-centric thinking and they can anticipate the implications of this shift for hiring, skill development, and team size and composition.

Participants understand that established agile practices will evolve under AI-supported development (e.g. pull request size, faster feedback loops, changed cadence).

Participants can reason about the evolving role of the architect across architecture levels (software, solution, enterprise) and can identify where AI support has the greatest leverage at each level.