Advanced mastery · Module 2

Enterprise architectures

Enterprise architecture is where good agent ideas get messy.

1h 3 outcomes Advanced mastery

Previously

Fine-tuning open source models

My opinion is that fine tuning is only worth it when you can name the win you want, the risk you accept, and the test you will run before anyone depends on it.

This module

Enterprise architectures

Enterprise architecture is where good agent ideas get messy.

Next

Production deployment

Production is not just running code.

Progress

Mark this module complete when you can explain it without rereading every paragraph.

Why this matters

When building agents for multiple customers, data isolation is critical.

What you will be able to do

  • 1 Explain what changes when your agent has many organisations and many users.
  • 2 Design isolation for data, prompts, and tool permissions.
  • 3 Plan for availability and safe degradation under load.

Before you begin

  • Comfort with earlier modules in this track
  • Ability to explain trade-offs and risks without jargon

Common ways people get this wrong

  • Cross tenant leakage. One leaked prompt or log line is enough to break trust and create legal risk.
  • Cost spikes. If routing always chooses the biggest model, your bill becomes a surprise.

Main idea at a glance

Multi-Tenant Agent Architecture

Stage 1

Customer Requests

Customers A, B, and C all making requests simultaneously

I think the hardest part of multi-tenant systems is making sure one customer's data never leaks to another

Enterprise architecture is where good agent ideas get messy. The same system must handle different organisations, different rules, and different risk appetites without leaking data or becoming too complex to run.

5.2.1 Multi-Tenant Architecture

When building agents for multiple customers, data isolation is critical.

Key principles

  1. Data Isolation: Each tenant's data must be completely separate

  2. Resource Limits: Prevent one tenant from consuming all resources

  3. Audit Trails: Track all actions by tenant for compliance

  4. Customisation: Allow per-tenant configuration without code changes

Common mistake

Quoting headline AI statistics without context

Reality: Most AI adoption statistics measure intent or experimentation, not production impact. When someone tells you "88% of companies use AI", the follow-up question is "for what, and with what measurable outcome?" The 6% high performer figure is far more informative than the 88% adoption figure.

Mental model

Isolation and routing

Enterprise agents succeed when tenants are isolated and requests are routed by risk and cost.

  1. 1

    Tenant

  2. 2

    API boundary

  3. 3

    Router

  4. 4

    Models

  5. 5

    Tools

Assumptions to keep in mind

  • Tenant data is isolated. Isolation must cover storage, prompts, logs, and memory. Not just a database table.
  • Routing rules are explicit. Routing should be a decision you can explain, not a mystery.

Failure modes to notice

  • Cross tenant leakage. One leaked prompt or log line is enough to break trust and create legal risk.
  • Cost spikes. If routing always chooses the biggest model, your bill becomes a surprise.

Check yourself

Quick check. Enterprise architecture and orchestration

0 of 3 opened

What is the non negotiable requirement in a multi tenant agent system
  1. A single shared database for simplicity
  2. Complete isolation of tenant data and prompt context
  3. One model for every customer
  4. A dashboard for every metric

Correct answer: Complete isolation of tenant data and prompt context

If one tenant can access another tenant's data or conversation context, the system is not safe to run.

What is smart routing in an agent platform
  1. Using faster network links
  2. Sending requests to an appropriate model based on complexity and risk
  3. Caching every response
  4. Running all requests through the largest model

Correct answer: Sending requests to an appropriate model based on complexity and risk

Smart routing keeps cost and latency under control while still sending high risk or complex requests to stronger models.

In a supervisor orchestration pattern, what is a common trade off
  1. It removes the need for logging
  2. The supervisor can become a bottleneck and a single point of failure
  3. It guarantees correctness
  4. It prevents prompt injection

Correct answer: The supervisor can become a bottleneck and a single point of failure

Central coordination is easier to reason about, but you must design for supervisor failure and for saturation under load.

Artefact and reflection

Artefact

A short architecture note with one diagram and a clear boundary statement.

Reflection

Where in your work would explain what changes when your agent has many organisations and many users. change a decision, and what evidence would make you trust that change?

Optional practice

Build a small team and compare supervisor, peer, hierarchical, and round robin coordination.

Back to AI Agents