KUBERNETES DELIVERY / JAVA 25 / AGENTIC SYSTEMS
Give every release
an evidence-backed decision.¶
Build a reasoning layer for canary delivery. Four Java agents investigate the same deployment window, explain what changed, and submit a recommendation to a governed rollout gate.
The question: should this release receive more traffic?
A brief dependency slowdown can block a healthy candidate. A retry regression can pass HTTP checks while increasing downstream work. This tutorial makes both cases observable, repeatable, and explainable.
Follow the investigation¶
01 / SHARED SLOWDOWN
A red signal needs context.¶
Stable and canary both slow down. Compare the revisions, identify the shared dependency, and hold until recovery.
HOLD, then GO after recovery
02 / HIDDEN RETRIES
A green signal needs scrutiny.¶
Checkout succeeds, but the canary makes repeated inventory calls. Correlate request observations, retry logs, and release guidance.
NO-GO for the regression
03 / GOVERNED AUTONOMY
A recommendation needs authority.¶
Apply production approval requirements. Withhold promotion when evidence is missing, stale, or belongs to another rollout stage.
HOLD until policy is satisfied
Build the demo, then plan production¶
01Run the decision roomStart locally, choose live AI or explicit fixtures, and explore the presenter UI. 02Connect delivery to KubernetesInstall GitOps, Argo Rollouts, workloads, and observability on OpenShift. 03Investigate the candidateRun both failure scenarios and follow the four-agent workflow. 04Govern the outcomeRequire fresh evidence, enforce safety limits, and approve eligible production releases. 05Plan production automationCompare manual and automatic investigation, human review, implementation patterns, and operational tradeoffs.
Three engineering perspectives¶
Platform engineers¶
Provide a shared analysis service, scoped identities, a reusable rollout template, and centrally enforced decision policy.
AI engineers¶
Compose @Agent specialists with a sequential and parallel workflow. Validate tool use, evidence references, memory isolation, and deadlines.
Application developers¶
Change a release in Git. Read a concise decision, follow its evidence, and understand what needs to improve before promotion.
A reproducible engineering demonstration. Faults and traffic are synthetic. Cluster-mode requests and telemetry are real. Local fixtures are explicitly labeled and cannot authorize a live rollout. The cluster installer targets OpenShift 4.22 and requires a real-cluster rehearsal.