Lab 01 — Enterprise Agentic Platform, End to End

Phase 17 · Lab 01 · Phase README · Warmup

The problem

Every earlier phase built one mechanism in isolation. This capstone wires them together into one runnable, tested mini-platform and makes you implement the request lifecycle — the order of the layers, the trust boundaries between them, and how each layer's guarantee composes. This is exactly the whiteboard a Staff/Principal candidate draws in the system-design round.

request + token
   │
   ▼  [P13] authenticate + resolve tenant  (never trust tenant_id from the body)
   ▼  [P13] authorize (RBAC, default-deny) + quota (token bucket)
   ▼  [P10] INPUT guardrail: injection check on untrusted content
   ▼  [P04] assemble context within a token budget
   ▼  [P05] retrieve grounding (tenant-scoped)
   ▼  [P01/P02] agent loop with validated tool calls, step budget  ── [P14] meter cost + trace
   ▼  [P10] OUTPUT guardrail: exfiltration / secret scan
   ▼  [P11] eval gate: grounded + safe?  (sampled)
   ▼  [P13] audit (metadata, secrets redacted)
   ▼
response

What you build

You implement the load-bearing pieces (the dataclasses and trivial helpers are given): token verify, RBAC, the token-bucket quota, tenant-scoped retrieval, budgeted context assembly, the in/out guardrails, the groundedness eval — and above all AgentPlatform.handle, the ordered lifecycle that composes them.

File map

FileRole
lab.pyyour implementation (fill the # TODOs; the lifecycle is the main one)
solution.pyreference + a main() running 5 scenarios (benign, injection, cross-tenant, forged token, quota)
test_lab.py19 tests: each primitive + each terminal path of the lifecycle
requirements.txtpytest only

Run it

pytest test_lab.py -v
LAB_MODULE=solution pytest test_lab.py -v
python solution.py

Success criteria

  • You can draw the request lifecycle from memory and name which phase each layer comes from.
  • Your handle blocks at the right layer for each attack (auth, authz, quota, input guardrail, output guardrail, eval gate) and audits every terminal path.
  • You can explain why the order matters (authenticate before authorize; input guard before the agent; output guard + eval before returning).
  • You can point at where each cross-cutting concern lives: reliability, security, cost, eval, tenancy, observability.
  • All 19 tests pass under both lab and solution.

How this maps to the real stack

This is the shape of a real enterprise agent platform (the Citi / Docker / Cohere archetype): an API gateway does authn/authz/quota, a guardrail service wraps the model, an MCP tool layer (Phase 03) and a durable orchestrator (Phase 08) run the agent, a vector store (Phase 05/06) provides tenant-scoped grounding, an eval service (Phase 11) gates quality, and OpenTelemetry traces + a cost meter (Phase 14) watch it all. Your inline versions are minimal, but the composition — the lifecycle and its boundaries — is exactly what production looks like. See system-design/01-enterprise-agent-platform.md for the full-scale design.

Limits. Each layer here is a teaching miniature (the "agent" is a scripted function, retrieval is lexical, durability isn't wired in). The point is the integration; swap in the real components from each phase and you have a production platform.

Extensions (your own machine)

  • Wire in the durable engine (Phase 08) so a crashed request resumes; add a human-approval signal for high-impact actions.
  • Replace the scripted agent with the ReAct runtime (Phase 01) + MCP tools (Phase 03).
  • Add model routing + a semantic cache + real OTel spans (Phase 14) and report $/resolved-task.
  • Turn the eval gate into a behavioral regression suite (Phase 11) run in CI.

Interview / resume signal

"Built an end-to-end enterprise agent platform composing authentication and RBAC, tenant isolation and quotas, layered injection/exfiltration guardrails, tenant-scoped retrieval, a metered and traced agent runtime, and an eval gate — as one ordered request lifecycle with explicit trust boundaries — and can defend every layer and its placement."