4.8. Developer Handoff
In one glance
- You will: Package developer evidence and choose whether to continue to Kubernetes platform engineering.
- You need: Workshop checks completed and familiarity with the reference tools, policy, tests, and A2A boundary.
- Time: about 20 minutes, hands-on.
What proves the developer part is complete?
Finish with an agent you can explain, test, and measure.
mise run lab -- status
mise run lab -- check 8
Your developer portfolio contains the Python source, read-tool and approval checks, a bounded workflow, labeled evaluation cases, an injection guardrail with its known misses, a read-only MCP server, and a short explanation of limitations. Add the live model run configuration and results when provider access permits. Mark that evidence pending if you worked entirely offline.
How do you join the platform part from the reference?
Platform learners can start from the completed application after verifying its deterministic contracts.
mise run install
mise run check:core
mise run test
The reference in agents/python/src/agent includes persistent A2A sessions, transactional action audit, privacy policy, MCP boundaries, health probes, and crash-recoverable state. Compare these with the smaller workshop implementation before using the platform manifests.
A2A is the inter-agent interface; it does not require Kubernetes. 3.6. A2A exposes and exercises it on the laptop first. Stop temporary servers when finished.
What is the handoff contract?
The platform operates the application without rewriting its domain logic.
| Developer provides | Platform engineer adds |
|---|---|
| Python application and dependency lock | Non-root container and image provenance |
| Model configuration and evaluation cases | Gateway endpoint, provider credential custody, transport requalification |
| Read/write authority boundaries | Network policy and caller access controls |
| A2A interface and health contract | kagent resource, probes, limits, and rollout |
| State and audit semantics | Persistent volumes, backup, restore, and recovery drills |
| Trace and error metadata | Collection, dashboards, alerts, and operational feedback |
Keep the same evaluation dataset across the direct Gemini and gateway paths. A compatible API shape does not prove identical tool-call or approval behavior.
Are you ready for the more demanding platform part?
Part II assumes containers and Kubernetes; it does not teach those foundations from scratch.
Before continuing, you should explain a Deployment, Service, Secret, PVC, namespace, readiness probe, and NetworkPolicy, and use kubectl to inspect a failed pod. Prepare with Kubernetes Basics if those operations are unfamiliar.
Local Kubernetes is the main platform path. GKE is an optional extension. Check the separate hardware and platform contract in SUPPORT.md before installing the platform tools.
What proves this page worked?
Save a handoff note that someone else can use to reproduce your result.
Source: repository/revision and location of my learner code
Offline proof: command, date, and observed result
Evaluation: dataset and grader results; live model/configuration or pending
Limits: behavior and environments I have not verified
Next step: finish Part I, adapt my own domain, or enter Part II
Keep the note with a backup of learning/; that directory is ignored by the course repository. Finishing Part I is a valid stopping point on a machine that cannot run the platform.
You are done when:
- Your developer evidence is understandable without this course open beside it.
- You can explain the application/platform responsibility split.
- You chose a stopping point; if continuing to Part II, you satisfy its prerequisites or have chosen preparation material.
Continue to 5. Gateway when you are ready to operate the tested reference.