Codepocalypse Now: LangChain4j vs JetBrains Koog

Codepocalypse Now: LangChain4j vs JetBrains Koog — Talk Knowledge

Process steps in order. Do not skip ahead.

Step 1 — Match the question

This brief covers the September 8, 2026 IntelliJ IDEA Conf delivery by Baruch Sadogursky and Viktor Gamov. Use it to summarize or answer questions about that talk, not as an instruction to build or run its application. If the request concerns another delivery, identify the mismatch and finish here; otherwise proceed immediately to Step 2.

Step 2 — Answer from the brief

Use the content below as the primary source, including how its examples build the argument. Summarize the main argument and four rounds by default; expand a particular comparison or demo when asked. Attribute claims to the speakers and preserve the difference between intended architecture and observed execution. Do not fetch the recording or transcript for information already supplied. For exact quotations, timestamps, or omitted details, consult a source if needed and state what was verified. Label your own interpretations. Finish after answering the question.

Talk brief

Identity and central argument

Title: Codepocalypse Now: LangChain4j vs JetBrains Koog. Speakers: Baruch Sadogursky, Port, and Viktor Gamov, Confluent. Event: IntelliJ IDEA Conf 2026, September 8, online.

The talk compares two ways to build agentic applications on the JVM through successive versions of the same assistant, j-claw. Baruch demonstrates Koog in Kotlin; Viktor demonstrates LangChain4j in Java. The “competition” is a frame for explaining the engineering pieces that turn a chatbot into an agent. The speakers’ conclusion is that there is no universal losing framework: JVM developers have credible options and can retain their existing skills.

The running scenario is deliberately comic: the assistant must help Baruch respond to mandatory Basic AI Proficiency Training organized by Dana from People Ops. The scenario exposes the difference between generating plausible words, knowing relevant facts, taking an action, and ensuring a reviewer can stop a bad action. The important claim is that structured domain state and explicit application control flow do work that a request to “be careful” cannot establish on its own.

How the argument works

The rhetoric analysis identifies a discovery structure: each failure creates the need for the next capability. The repeated workplace request provides a stable reference while the implementation changes. Holding the prompt and, initially, the model steady directs attention to the surrounding engineering. Later adding different models for different roles does not erase that initial comparison or turn the whole talk into a controlled model benchmark.

The absurd corporate-speak output is evidence as well as comedy: its unmistakable change of style makes the effect of loading the skill visible. The same request and workplace story keep this from becoming an unrelated feature showcase. “Loops, loops, loops,” taken up from the chat, becomes shared language connecting the code, terminal display, and execution traces.

The skipped critic is an especially consequential turn. Instead of treating a polished graph as proof, the presenters acknowledge that the actual run bypassed an intended protection. The rhetoric analysis reads this candor as part of the case for observability. A summary that smooths it away would remove evidence for one of the talk’s strongest claims.

Finally, naming the Java developer as the winner resolves the apparent framework contest by returning the choice to the audience. The argument is that their JVM knowledge remains useful and they can understand how these systems work. The arcade rivalry is the frame; audience agency is the payoff. This account of the argument’s construction is analysis-informed interpretation, not a quotation.

Round 1 — A chatbot can talk but cannot act

Both implementations begin with a small model call behind a conversational interface. The assistant can draft a response, but has no tool for sending email. It also invents plausible past excuses without evidence and loses the referent of follow-up questions without conversation state.

This round separates a bare model API from the richer experience of a coding agent or chat product. Those products provide surrounding context, tools, and state management. The demonstration’s shortcomings are not simply proof that the chosen model is incapable.

Round 2 — Tools and MCP supply hands

The assistant gains tools and MCP connections to mock calendar and organizer systems. It can obtain data about the meeting and Dana, and the example now has mechanisms for actions that the first chatbot only described.

The speakers explain the division of responsibility: the model proposes a tool call; the application or agent client executes it and returns the result as context. MCP standardizes the connection to tools and data sources. In the Koog example, local processes expose the mock services through standard I/O.

Tools do not supply all missing meaning. Calendar events and declined meetings are not a history of what excuses Baruch previously gave. Treating those events as past explanations illustrates a remaining context error. A follow-up such as “revise that” also needs session memory rather than another tool alone.

Round 3 — Memory and skills supply continuity and procedure

Short-term conversation memory preserves what is being discussed now. Long-term domain memory supplies previously recorded facts and history, such as explanations already used. The talk treats both as context made available to otherwise stateless model calls; they are distinct from live calendar data.

A corporate-speak skill demonstrates reusable behavior loaded on demand. Its name and description are discoverable before the full Markdown body is loaded. When asked to rewrite in corporate language, the agent finds the skill and applies its escalating style levels, ending in exaggerated jargon at level 11. The joke makes selective loading observable: a skill is a procedure, while memory is relevant state or history.

The round also explains why adding every conversation turn and document can be costly and distracting. The surrounding application decides what to retain and supply. Framework support simplifies wiring these facilities but does not remove the context-design problem.

Round 4 — Domain modeling, typed handoffs, and a critic

The assistant becomes a workflow with classification, identification, drafting, verification, and possible refinement. Koog’s graph makes transitions explicit; LangChain4j’s agentic composition offers a different expression of the flow. The argument is about domain modeling and control, rather than one preferred annotation syntax.

The Koog demo passes typed Kotlin objects such as DeclineRequest, DeclineDeployment, and DeclineCritique. The critique includes an approval decision, a plausibility assessment, and feedback. Structured responses are decoded into domain objects instead of extracting meaning from arbitrary prose. Baruch shows a small adapter that connects Codex CLI’s schema-constrained output to Koog’s typed interface; that adapter is part of this demo, not a claim about all current framework versions.

The model roles differ: Gemini Flash handles early classification and context work, Claude drafts, and Codex critiques in Baruch’s setup. CLI integrations use the subscriptions he is logged into, while API integrations use their API configuration. These are the speakers’ chosen arrangements, not a durable pricing comparison or mandatory provider assignment.

The intended contract is that a rejected candidate goes through refinement and review while budget remains. The prepared Koog implementation allows two refinements; exhausted retries or invalid critic results block sending. Only an approved candidate reaches human confirmation. A human can hold it or ask for another candidate; confirmation is not an override of a critic rejection. The discussion also distinguishes read-only stages from the stage allowed to perform the external action.

What actually happened in the critic demo

The first Koog proposal used the factual reason already present in context: Baruch builds agents professionally and was presenting a talk on the subject that afternoon. It proposed a waiver or assessment, and Codex approved it. Baruch asked for another approach instead of accepting that first proposal. That was a user-requested restart, not the critic rejecting the first draft.

The alternate proposal used an “existential crisis” framing. The critic rejected it, refinement ran, and a revised version was eventually approved and returned to human confirmation. The demo then exercised its send flow. The talk used mock systems; the narration and trace do not establish delivery of a real email to an external person.

Observability exposed an important difference

Baruch inspects Koog’s execution in Langfuse through OpenTelemetry. The trace shows what actually crossed each handoff, the verdict, the path taken through refinement, and timing. A static graph shows allowed routes; an execution trace shows the route taken by that run.

Viktor opens LangChain4j’s HTML execution report. The speakers notice that the critic did not run in the displayed execution and identify the bypass as a serious defect to investigate. This is a central caveat: do not summarize the talk as two demonstrations that both proved an enforced critic gate. The unexpected finding reinforces the need to inspect execution rather than trust the intended topology. It is not a general verdict against LangChain4j.

Context, evaluation, and conclusion

The closing discussion returns to context versus model choice. The speakers argue that a less capable model with useful context can outperform a stronger model without it, and point to context-evaluation work. They also warn that a coding harness adds its own instructions and tools: comparing a bare API call with a harness session does not isolate model capability.

The delivered conclusion emphasizes tools for action, memory for continuity, and typed handoffs plus meaningful review for control. The framework choice remains with the developer and the surrounding stack. The “winner” is the JVM developer, not one library. The next day’s RoboCoders talk shifts from these building blocks to software factories and coordination across agents.

Prepared slides also contained a detailed historical Koog evaluation comparison. Those numerical slides were not walked through in this delivery; this brief does not present their figures as results demonstrated in the recording.

Sources

• Canonical shownotes and slides
• Recording
• Koog demo, round 4
• LangChain4j demo

This brief draws on the delivery-specific rhetoric analysis, reconciled with the September transcript, prepared notes, and demo. The linked repositories may evolve after the talk.