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
| File | Role |
|---|---|
lab.py | your implementation (fill the # TODOs; the lifecycle is the main one) |
solution.py | reference + a main() running 5 scenarios (benign, injection, cross-tenant, forged token, quota) |
test_lab.py | 19 tests: each primitive + each terminal path of the lifecycle |
requirements.txt | pytest 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
handleblocks 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
labandsolution.
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."