Architect Professional: systems at scale
Multi-agent orchestration, enterprise integration, security and audit, and the governance that keeps quality and cost predictable.
For architects who own delivery risk. The material is organised around the constraints enterprises actually impose — identity, residency, auditability, cost attribution — and the reference architectures that satisfy them.
Course outline
15 lessons · 6h 32m · v1
01Multi-agent architectureOrchestration patterns, and the determinism you give up for them.4 lessons
- When multi-agent actually helpsFree preview26 min
- Orchestrator, worker and critic patternsFree preview30 min
- Shared state and hand-off contracts26 min
- Debugging emergent behaviour28 min
02Enterprise integrationIdentity, data boundaries, and systems that are not allowed to fail.4 lessons
- Identity, permissions and delegation28 min
- Data residency and boundary design26 min
- Integrating with systems of record26 min
- Vendor and model diversification22 min
03Security, compliance and auditThe evidence trail an auditor or security reviewer will ask for.3 lessons
- Threat modelling an LLM application30 min
- Auditability and evidence26 min
- Incident response for AI systems24 min
04Scale, reliability and governanceKeeping quality and cost predictable as adoption grows.4 lessons
- Reliability engineering at scale28 min
- Evaluation as a platform capability26 min
- Cost governance across an organisation24 min
- Rollout, training and change management22 min
What this covers
You will be able to
- Choose between single-agent and multi-agent designs on evidence
- Meet identity, residency and audit requirements
- Threat model an LLM application
- Govern cost and quality across teams
Included
- 15 lessons across 4 modules
- Reference architecture diagrams
- Threat model and audit templates
- Lifetime access and updates
Preview: When multi-agent actually helps
The first two lessons of the course are free to read, so you can judge the material before buying.
Multi-agent designs are usually attempted for the wrong reason: the task feels big. The right reason is that two parts of the work need genuinely different context, tools or review.
Legitimate decomposition
- Different tool permissions: one agent reads, another writes.
- Different context: a codebase reader and a policy checker cannot share one window cheaply.
- Independent verification: a critic that did not produce the work.
- Parallel exploration where the answer space is wide.
What does not justify it
Splitting a single reasoning task across agents adds hand-off loss and coordination cost without adding capability. If one prompt with better structure solves it, multi-agent is complexity you will maintain forever.
The test: can you name the artefact passed between agents, and why a single context cannot hold it? If not, keep one agent and improve its tools.
Checkpoint
State the one constraint that would justify splitting a task across two agents.