Building & orchestrating production-ready agentic AI systems.

Deep dive 10 opens the AI block of the series. Kevin Dubois and Daniel Oh (IBM / Red Hat, both Java Champions) gave the clearest map I've seen of how you get from "one LLM call" to a production agentic system — using LangChain4j-agentic on the JVM. The arc: an AI service is more than a model (it needs prompts, memory, tools, RAG, guardrails); agents are AI services that collaborate; you orchestrate them with four workflow patterns (sequence, loop, parallel, routing); shared state lives in an AgenticScope; and for real flexibility you graduate to the supervisor pattern where an LLM decides which agent to call next. And in production? Agentic apps are mostly just regular apps.

This is the conceptual backbone for the whole AI cluster. The next three deep dives — observing agents, GPU economics, and model serving — are all about running what this talk teaches you to build.

It all starts with a single AI service

An LLM is at the core of any AI-infused application — but, the speakers stressed, a model alone is not enough. A real AI service layers on:

Ingredient	Why you need it
Prompts	guide the LLM precisely and unambiguously.
Chat memory	remember previous turns — make it conversational.
Tools (function calling)	extend the LLM and own the deterministic tasks where generative AI falls short.
Data / knowledge (RAG)	provide contextual information and persist state.
Guardrails	block malicious input and unacceptable responses.
Production capabilities	observability, resilience, scaling — the boring-but-essential.

From a single service to agentic systems

What turns an AI service into an agent is the capability to collaborate with other agents to perform complex tasks toward a common goal. The talk laid out a four-rung ladder of increasing sophistication:

The demos used LangChain4j-agentic (with Quarkus), so the agent abstractions are plain Java interfaces — which makes the whole thing remarkably readable.

Defining an agent is annotating an interface

public interface StoryGenerator {
  @Agent("Generate a story based on the given topic, for a specific audience and style")
  String generateStory(String topic, String audience, String style);
}
// Use it like an ordinary API:
var story = storyGenerator.generateStory("dragons and wizards", "young adults", "fantasy");

Each agent carries its own system prompt via @UserMessage (e.g. a CreativeWriter, an AudienceEditor, a StyleEditor). The magic is in how you compose them.

Programmatic orchestration — four patterns

The simplest way to glue agents together is fixed, predetermined workflows. Four basic patterns are the building blocks of everything more complex:

Pattern	Shape	Example
Sequence / prompt chaining	A → B → C	writer → audience editor → style editor → novel
Loop / reflection	repeat until good enough	style scorer ⇄ style editor until score ≥ 0.8
Parallelization	fan out, aggregate	food agent ∥ movie agent → aggregator
Conditional / routing	pick a branch	router → legal / medical / technical expert

Sequence — declarative or programmatic

You can compose agents declaratively:

public interface StoryGenerator {
  @SequenceAgent(outputKey = "story",
    subAgents = { CreativeWriter.class, AudienceEditor.class, StyleEditor.class })
  String generateStory(String topic, String audience, String style);
}

…or programmatically with builders:

var creativeWriter = AgenticServices.agentBuilder(CreativeWriter.class)
    .chatModel(myModel).outputKey("story").build();
// … audienceEditor, styleEditor …
var storyGenerator = AgenticServices.sequenceBuilder(StoryGenerator.class)
    .subAgents(creativeWriter, audienceEditor, styleEditor)
    .outputKey("story").build();

The AgenticScope — shared state

How do agents pass results to each other? Through a shared AgenticScope — a collection of data shared among the agents in one agentic system. It:

• stores shared variables — written by one agent (its result) and read by another (its input). The topic, audience, style, and story all live here; each agent's outputKey names where it writes.
• records the sequence of invocations of all agents with their responses.
• provides system-wide context to an agent based on prior executions.
• is persistable via a pluggable SPI.

Loop / reflection

var styleScorer = agentBuilder(StyleScorer.class)
    .chatModel(myModel).outputKey("score").build();

UntypedAgent styleReviewLoop = loopBuilder()
    .subAgents(styleScorer, styleEditor)
    .maxIterations(5)
    .exitCondition(scope -> scope.readState("score", 0.0) >= 0.8)
    .build();

var storyGenerator = sequenceBuilder(StoryGenerator.class)
    .subAgents(creativeWriter, styleReviewLoop)   // workflows embed in workflows
    .outputKey("story").build();

A StyleScorer agent returns a 0–1 quality score; the loop keeps editing until the score clears 0.8 or it hits 5 iterations. Note that a whole loop is itself an agent you can drop into a sequence — workflows nest.

Parallel & routing

Parallel: a parallelBuilder runs a food agent and movie agent concurrently, then an aggregator reads both results from the scope (agenticScope.readState("movies"), readState("meals")) and combines them. Routing: a conditionalBuilder reads a category the router agent wrote and invokes only the matching expert:

UntypedAgent expertsAgent = AgenticServices.conditionalBuilder()
    .subAgents(scope -> scope.readState("category", UNKNOWN) == MEDICAL, medicalExpert)
    .subAgents(scope -> scope.readState("category", UNKNOWN) == LEGAL,   legalExpert)
    .subAgents(scope -> scope.readState("category", UNKNOWN) == TECHNICAL, techExpert)
    .build();

From orchestration to autonomous agents

Everything so far is fully deterministic — you, the developer, fixed the path. But many systems need to be flexible and adaptive. That's the line between a workflow and an autonomous agent:

Workflow	Autonomous agent
LLMs & tools orchestrated programmatically through predefined code paths	the LLM dynamically directs its own process and tool usage, keeping control over how it executes tasks

The supervisor pattern

The canonical autonomous design: a supervisor sits over a pool of agents and, each iteration, decides whether the goal is achieved (return the response) or which agent to invoke next — generating the arguments to pass it from the current context and state.

It tracks invocations with a simple record:

public record AgentInvocation(String agentName, Map<String, String> arguments) { }

The demo applied this to a vehicle-return workflow: a parallel feedback-analysis stage (cleaning, maintenance, disposition tasks) fed a FleetSupervisorAgent that autonomously orchestrated downstream agents — a pricing agent, a disposition-proposal agent, and a human-approval agent for high-value cases.

Production deployment — it's mostly just apps

Custom agentic patterns — a pluggable planner

The top rung of the ladder: separate the planner (decides the next action) from the execution layer (invokes agents). The planner is pluggable — workflow, supervisor, GOAP (goal-oriented action planning), peer-to-peer — and the execution layer is customizable by the framework (Quarkus). The planner reads/writes the AgenticScope, emits an action, the execution layer invokes the chosen agent, and the result flows back. This is how you build orchestration strategies the framework's built-ins don't cover.

The rest of the LangChain4j-agentic toolbox

The closing rapid-fire showed how much is already in the box — worth knowing exists so you don't reinvent it:

• Error handling & recovery — an errorHandler can inspect the failure and return ErrorRecoveryResult.retry() (e.g. inject a missing topic into the scope and retry) or rethrow.
• Programmatic non-AI agents — a plain Java class with @Agent (e.g. an ExchangeOperator calling a REST currency API). Deterministic work participates as a first-class agent.
• Human-in-the-loop — a humanInTheLoopBuilder prompts a person (read input, write to scope) mid-workflow.
• Asynchronous agents — .async(true) on the builder.
• A2A integration — a2aBuilder(A2A_SERVER_URL, …) consumes a remote agent over the Agent-to-Agent protocol.
• Comprehensive declarative API — @LoopAgent / @ExitCondition, @SequenceAgent, etc., as annotations.
• CDI support — @Inject your composed agents.
• Dynamic model selection — a DynamicModelSelector can route to a bigger model when a critique score is low (e.g. critique.score() > 7.8 ? enhancedModel : baseModel) — cost control by quality.

FAQ

When should I use a workflow vs an autonomous supervisor?

Default to a deterministic workflow (sequence/loop/parallel/routing) — it's cheaper, debuggable, and predictable. Reach for the supervisor pattern only when the path genuinely can't be fixed in advance and the system needs to decide iteratively which agent to call. Autonomy buys flexibility at the cost of predictability and token spend.

What's the AgenticScope actually for?

It's the shared blackboard: agents write results to named keys (outputKey) and read inputs from the same scope, instead of calling each other directly. That decoupling lets you rewire the topology freely, and it's where loop exit-conditions and parallel aggregators read state. It's persistable via an SPI.

Do I need Python for agents?

No — this whole talk is JVM-native via LangChain4j-agentic + Quarkus, with agents as annotated Java interfaces and CDI injection. If your stack is Java, you don't have to bolt on a separate Python service to do agents.

How is deploying an agentic app different from a normal service?

Barely. Same observability (plus token usage), AuthN/AuthZ (plus MCP/A2A), health checks, and scaling on Kubernetes. The new golden signals are token cost and agent-invocation traces — but the deployment model is the one you already run.

Takeaways

• An AI service is a model plus scaffolding — prompts, memory, tools, RAG, guardrails, ops. Most of the work is the scaffolding.
• Agents are services that collaborate. Compose them with four patterns: sequence, loop, parallel, routing.
• The AgenticScope is the shared blackboard — agents read/write named keys, so topology is rewireable.
• Workflows are deterministic; the supervisor pattern is autonomous. Use the former by default, the latter only where adaptivity is required.
• Production agentic apps are mostly regular apps — observability (incl. tokens), authz, health, scaling on Kubernetes.
• The JVM is a first-class agent platform via LangChain4j-agentic + Quarkus, with declarative and programmatic APIs, human-in-the-loop, A2A, and dynamic model selection built in.

Next in the series — Deep dive 11: What Did My Agent Do?, on observing and debugging the autonomous systems you just learned to build.

References

• KubeCon Mumbai 2026 — Day 1 index · the rest of the series
• LangChain4j — Agents · Quarkus LangChain4j · the frameworks used
• Quarkus + LangChain4j workshop · hands-on
• Building effective agents · the patterns vocabulary (chaining, routing, parallelization, orchestrator-worker)