Writing code was never the same thing as making software. The typing was always the cheap half, and the cheap half is the one that got cheaper.

Matt Pocock points to the other side: bad code is far more expensive today than it used to be. The reason is speed. The rate at which I can push bad code into production has no ceiling anymore. Whatever I used to get wrong once a sprint, I can now get wrong continuously.

Here is what I see day to day. AI does great work on a good codebase. Well structured, well written, documented, and it just flies. Working with it is a pleasure. On a bad codebase, it goes the other way and starts going nuts.

I once read Venkat Subramaniam stating the sharpest version of why. Developers say AI-generated code is bad. AI was trained on code written by developers. That, he says, is called karma. 🙂

So none of this is a new problem. We have been dealing with design, structure, and documentation for a very long time, and we already know what happens when they are missing. What changed is the clock. The same problems now arrive faster, and usually at a much bigger scale.

If you are running AI on a legacy codebase right now, I would like to hear which of the two you are getting: does it fly, or does it go nuts?

Then I read the code:

@Produces
@ApplicationScoped
public PromptGuardAgent promptGuardAgent() {
    ChatModel guardModel = OllamaChatModel.builder()
            .baseUrl(baseUrl)
            .modelName(guardModelName)
            .temperature(0.0)
            .think(Boolean.FALSE)
            .timeout(Duration.ofSeconds(timeoutSeconds))
            .build();

    return AiServices.builder(PromptGuardAgent.class)
            .chatModel(guardModel)
            .build();
}

This is real output from an agent in one of my projects. It even shows some care: temperature zero, an explicit timeout. But look at what it is: a producer assembling the ChatModel by hand and calling AiServices.builder. That's raw LangChain4j inside a Quarkus application. The Quarkus way is declarative: @RegisterAiService on the interface, the model named in application.properties. And the difference is expensive. With manual wiring you lose what the integration gives you for free: metrics and traces on every model call, declarative fault tolerance, guardrails you can plug in. None of that stops the app from running today. That's exactly where the danger lives: the problem doesn't show up on day one.

The bill always arrives

The gap between "works" and "well built" appears when the system lives on. It appears when someone has to maintain that code six months from now. It appears when traffic grows and resource usage becomes real money. And the pattern multiplies: a class with ten lines that could be one is a detail; ten thousand of them is an extra codebase you didn't need, polluting the context of every future agent session that touches it.

Markus Eisele, who writes The Main Thread and is on my team at IBM, compressed all of this into one line at his JCON keynote this year: "Code is cheap now. Software is not. You just get there a lot faster now." The cost of producing code collapsed. The cost of software (intent, correctness, maintenance, complexity) stayed exactly where it always was. He closes with two variations I keep coming back to: code is cheap, intent is not; code is cheap, verification is everything.

Matt Pocock inverted the same argument at the AI Engineer conference: bad code is the most expensive it has ever been. If your codebase is good, AI multiplies your speed. If it's bad, AI sinks with it and produces more bad code on top. Engineering fundamentals gained value in the age of agents. Good practices stopped being a reviewer's nitpick and became an economic argument.

And none of these pains are new. "It didn't do what I asked": Frederick Brooks, The Design of Design. "Too verbose": Eric Evans, Domain-Driven Design. "Done, but broken": Andy Hunt and Dave Thomas, The Pragmatic Programmer. "Hard to test": John Ousterhout, A Philosophy of Software Design. These books didn't break with AI. They became more important. We don't need new fundamentals; we need the usual ones, written in a format the agent can use.

Venkat Subramaniam summed up the irony: developers say AI-generated code is bad; AI was trained on code written by developers; that's called karma.

A good engineer with no memory

Why does the agent miss what a senior engineer gets right? Because everything an experienced engineer carries implicitly (the house patterns, the known traps, the right way to test) the agent doesn't carry between sessions. It's born again in every conversation. That knowledge has to be written somewhere the agent reads. If it isn't written, for the agent it doesn't exist.

Eisele has a phrase for the consequence, and I've adopted it: any structure you present to the model beats any clever prompt. A good prompt solves the task at hand. Structure (a conventions file, skills, MCP servers) solves every task that comes after. It's the difference between asking well and teaching once.

Fabio Akita put it in a way that lands: AI reflects who you are. If your engineering practice is messy, the agent amplifies the mess. If it's explicit and disciplined, the agent amplifies that instead. So the question stops being "does AI write good code?" and becomes: what am I giving it to read?

All of this lands on one thesis: the agent needs to read before it writes. The good news is that in our ecosystem, that work had already started.

What the Quarkus ecosystem already gives you

The Quarkus team attacked part of the problem with the Quarkus Agent MCP: a standalone Model Context Protocol (MCP) server that teaches your agent to code using Quarkus. It creates projects and manages the app lifecycle. It exposes skills per extension and runs semantic search over the whole documentation. And it carries a design detail I find brilliant: it runs outside the application process, so when the app crashes, the agent stays alive, reads the structured exception and goes fix the problem.

When I started using it, the quality of the Quarkus code my agents produced jumped immediately.

But a real application is bigger than the framework. There are the design patterns of the Java world, there are tests, there's persistence. And there's LangChain4j, which for me is the most critical case: a young ecosystem with a fast release pace, where the model has little training baggage. That's exactly where being specific and opinionated pays the most. The stakes are not small either: the State of Java survey by Azul found that among companies building AI features, half use Java in the implementation. This problem is ours.

Quarkus Agentic Scaffolding

So I built Quarkus Agentic Scaffolding. In one sentence: an installable artifact that puts Quarkus + LangChain4j best practices in front of the agent before it writes the first line.

It's open source under Apache 2.0. The templates are code that compiles, validated in CI. And it installs on practically any assistant that supports the Agent Skills format (Claude Code, Codex, Copilot, Cursor, IBM Bob and others) with one command:

npx skills add eldermoraes/quarkus-agentic-scaffolding

The architecture separates two things that usually come tangled together. On one side, an always-on conventions file (CLAUDE.md for Claude, AGENTS.md for the rest) that declares the rules the code must follow. On the other, three skills that execute procedures. The skills don't repeat the rules; they point to the file. One source of truth.

A sample of what the conventions declare:

• Java 25+ as the baseline
• Virtual threads by default for blocking work
• records, sealed types and pattern matching where they clarify intent
• Platform BOMs instead of pinned extension versions
• CDI-first
• Declarative AI services with @RegisterAiService
• Declarative guardrails
• Easy RAG first, portable to something heavier later
• Zero-code observability with Micrometer and OpenTelemetry

Nothing in that list is generic clean-code advice. It's the current way of building on this stack, and every line exists because it fixes a mistake agents make in the real world.

The plugin ships three skills.

/setup-agentic-scaffolding prepares the ground, and it carries a design decision I care about: the plugin doesn't try to be an island. It verifies your toolchain: JDK 25 / GraalVM, JBang, a container runtime. It registers the Quarkus Agent MCP and Context7, for library documentation fresher than the model's training data. And it recommends the Superpowers skill set for process. Each of these pieces expands what the agent can do well, and the plugin uses all of them along the way.

/scaffold-project covers both moments of creation: the new project end-to-end, and the new component inside a project that already exists (an AI service, tools, agents and multi-agent workflows, RAG, an MCP client or server, guardrails). The project skeleton comes from the Quarkus Agent MCP; the skill applies the layout, the base application.properties and the starter templates. You trigger it in natural language: ask for a RAG pipeline and it enters the flow on its own.

/audit-project closes the loop, because most projects won't be born now; they already exist. It compares the project against the conventions and returns a prioritized list: what's missing, where the evidence is, what the suggested fix looks like. It's read-only by default and only applies fixes with your confirmation. There's a foundation behind keeping this separate, and Andrej Karpathy named it: generating code and judging code are different capabilities. The audit puts the agent in the reviewer's seat with an explicit ruler in hand. The same kind of agent that wrote the code at the top of this post, now enforcing the practices it used to skip.

Does it save tokens?

A fair question: do the skills reduce token usage, or do they only improve quality? Honest answer: I haven't measured it yet. The runs were clearly faster, and my reading is that more upfront direction means less reasoning, because reasoning is largely the agent validating its own inferences. Fewer inferences to validate, fewer tokens burned. I intend to measure it properly and publish the numbers.

Skills: a new kind of open source asset

Conventions rot if nobody maintains them, so the project tracks the releases of Quarkus, Java and LangChain4j: when the stack moves, the target moves with it. Semantic versioning, a changelog, CI making sure the templates still compile.

There's a line from the DevStar working group, inside the Quarkus project, that frames this whole space: tools do things; skills teach how to do things well. I believe this becomes a new kind of open source contribution: library maintainers and platform teams writing knowledge for agents to read. And it works inside your company too. Your team's conventions can live in a file the agent reads before writing. The model is the same.

Try it on your own project

The sentence that made me start this project is the invitation I'll leave you with: I want to shorten your path to building applications that follow best practices while using AI.

Install it, scaffold a new project, audit one an agent already wrote. Then tell me what you find. Issues, pull requests and criticism are welcome: github.com/eldermoraes/quarkus-agentic-scaffolding.

The paper is Harness Engineering for Agentic AI Coding Tools: An Exploratory Study. It builds on work published in AIware 2026. The stated method: identify eight configuration mechanisms spanning from static context to executable and external integrations, then examine whether and how they are adopted across those 2,853 repositories, with a detailed analysis of Context Files, Skills and Subagents.

Two findings carry the paper.

First: Context Files dominate the configuration landscape and are often the sole mechanism in a repository, with AGENTS.md emerging as an interoperable standard across tools.

Second: few repositories adopt advanced mechanisms such as Skills and Subagents. Skills predominantly rely on static instructions rather than executable scripts.

Read those two sentences next to any vendor keynote from the last twelve months and you will notice the gap.

What "sole mechanism" means when you are the one maintaining the repo

The phrase doing the most work in that first finding is often the sole mechanism. Read it literally: configuration begins and ends there. A repository that has configured its coding agent has, in a large share of cases, written one markdown file and stopped.

If you use a coding agent daily on an enterprise Java codebase, that result is either deflating or vindicating depending on what you have been told to feel bad about. The narrative you have been sold says the sophisticated shop graduates from a context file to skills, then to subagents, then to a fleet of them coordinating. The observed behavior says the sophisticated shop writes a good markdown file and gets back to work.

There is a version of this finding that is just "adoption takes time, the advanced stuff is new." That reading is available and probably partly right. But it does not survive the second half of the second finding: Skills predominantly rely on static instructions rather than executable scripts.

The mechanism people adopted, minus the part that made it a mechanism

Skills, as a category, exist to hold something a context file cannot: procedure that runs. A skill can carry a script the agent executes: a deterministic step, a verification, a generator, something with an exit code. Executable scripts are optional in a skill (only the SKILL.md file is required), which is exactly why a skill can collapse into a longer paragraph of AGENTS.md with a folder around it.

The finding says the repositories that adopted Skills largely did not adopt that part. They used the skill container to hold more static instructions. So the file structure changed and the mechanism count went up. The configuration surface stayed exactly where it was: text that shapes what the model reads, with nothing that constrains what the system does.

That is a much more specific result than "advanced features have low adoption." It says people reached for the advanced mechanism, and then used it as if it were the basic one.

Three explanations, and the one you can test

The paper reports what it observed. Why executable configuration did not take is where the argument is, and from here I am reasoning past the data. Three explanations fit the shape of the finding:

Maintenance cost. An executable skill is code. It has dependencies and an owner. It breaks when the repo moves, and it needs updating every time the toolchain changes. A markdown file has none of those properties. It degrades silently where code fails loudly, which is worse in principle and much cheaper in practice. Anyone who has maintained a Makefile that only three people on the team can modify already knows this tradeoff and made the same call.

No visible return. When you improve AGENTS.md, the next agent run reflects it immediately and legibly: you read the output and see your instruction landed. When you add an executable skill, the benefit is conditional on the agent choosing to invoke it, in a situation that matches, on a run you may not observe. Static context pays you back in the same session. Developers optimize what they can see move.

No good way to test it. This is the explanation I would put money on, and it is the one with a concrete fix. We have decades of practice testing application code and roughly none testing agent configuration. What is the assertion for "this skill fires under the right conditions," and what does an error look like? A team with a mature CI pipeline can tell you in minutes whether a change broke the build. That same team cannot tell you whether last week's edit to their agent config made the agent better or worse, and they know it. Executable configuration without a test harness is a component you ship untested into a nondeterministic runtime. Java teams built an entire testing culture around not doing that.

The three are not exclusive. But notice which one you can act on: cost and visibility are properties of the ecosystem, and testability is a thing a team can build.

Claude Code users reach for more mechanisms than anyone else

One result deserves separate treatment: users of Claude Code employ the widest range of mechanisms among the tools studied.

In other words: a particular tool attracts more sophisticated practitioners. Read it as a fact about surfaces and you get something more useful. A mechanism that a tool does not expose cannot show up in a repository, no matter how sophisticated the person typing. If adoption breadth tracks the tool and not the team, what the study measures is the ceiling each tool sets.

What to actually do with this

The paper suggests AGENTS.md as a natural starting point, and the empirical result gives that suggestion teeth: it is the interoperable standard across tools, so the effort transfers when you switch. For most repositories it is also, apparently, where the work ends. Given the state of the tooling, that is a defensible place to stop.

The move that follows from the data has no glamour at all. Write the context file, make it genuinely good, and treat every step beyond it as a claim you have to justify. Before adding an executable skill, answer the question those 2,853 repositories answer with silence: how will you know it works, and how will you know when it stops working? If you have an answer, build it. If you do not, you would be adding a component to your build that apparently nobody will verify, which is the situation the static markdown file quietly avoids.

The market is selling multi-agent orchestration. The configuration files of thousands of repositories describe something plainer: one file, written carefully, doing most of the work. With a gap that wide between the pitch and the practice, the question worth asking is what the executable mechanisms still need before teams reach for them. Testability is the first item on that list.

The AI skill moved inside the extension

The interesting word in "Add AI skill for quarkus-quartz" is for. The skill ships attached to a single extension rather than as a global description of Quarkus living somewhere central.

That placement is the whole argument. A coding agent working in your project does not need Quarkus in the abstract; it needs the version of quarkus-quartz that is actually on your classpath, with the configuration keys and patterns that version supports. When the skill travels with the extension, the agent reads patterns matched to what you installed, instead of patterns averaged over every version ever published to the open web.

The alternative most teams settle for is a single, generic body of "how do I do X in Quarkus" knowledge that an agent queries, one description that knows the framework in the abstract and quickly drifts out of sync. The 3.37.0.CR1 approach inverts the arrangement. Each extension carries its own agent-facing knowledge as a first-class, version-matched artifact, delivered to the agent through the Quarkus Agent MCP server rather than bolted onto the whole framework as one description.

Notice the kinds of extension getting skills in this batch: a scheduler, a reactive ORM, a cache, a security integration. These are the parts where the "right" usage is full of small, version-specific decisions that an agent routinely gets subtly wrong. That is the correct place to start.

Where hallucinated configs actually come from

Most wrong Quarkus configuration an agent emits started as real configuration: for a different version, or a property renamed two releases ago, or an extension that was later split. The agent learned it from public text that carries no version stamp, so it cannot tell that the snippet it is confidently reproducing stopped being correct eighteen months ago.

A skill that ships with the extension carries that stamp implicitly. The knowledge an agent reads is the knowledge that matches the artifact resolved into your build. The failure mode persists, but its main fuel source, version-blind text scraped from everywhere, stops being the default input. For a senior reviewer, that is the difference between catching one plausible-but-stale config in review and catching five.

This is the part of the release that compounds. Skills attached to extensions are something every extension can grow over time, and every one that does makes the agent a little less dependent on the public internet for your stack.

The line that touches your production numbers

"Introduce ability to get response metadata in streamed response" is the entry nobody will quote. The capability it points at, reading what is around a streamed response rather than just the body, is the kind of thing that quietly changes a dashboard. If you stream LLM output in Quarkus with the LangChain4j extension, you push tokens to the client as they arrive. The text is the easy part. The awkward part has always been everything around it: how many tokens the call consumed, and why the model stopped. That metadata is what you bill against, alert on, and debug with. Capturing token usage and finish reason without buffering the whole response is something the LangChain4j extension already supports through the completed ChatResponse. What this changelog line actually adds lives on the Quarkus REST Client side: a way to read the HTTP status code and headers of a streamed response, rather than the body alone. Before it, reading those meant falling back to the raw Vert.x HTTP client.

Here is the shape of consuming it in a real project. The dependencies first:

<dependencies>
    <dependency>
        <groupId>io.quarkus</groupId>
        <artifactId>quarkus-rest-jackson</artifactId>
    </dependency>
    <dependency>
        <groupId>io.quarkiverse.langchain4j</groupId>
        <artifactId>quarkus-langchain4j-openai</artifactId>
    </dependency>
</dependencies>

There is no separate AI service interface here. Quarkus LangChain4j exposes the configured model as a CDI bean, so the metadata work lives in one service: you inject the default StreamingChatModel and drive it with a StreamingChatResponseHandler. Partial responses flow straight out to the caller as they arrive. When the stream completes, you are handed a ChatResponse whose metadata() carries the finish reason and the token usage. You record it at that point. The text was never buffered:

// src/main/java/com/example/story/StoryService.java
package com.example.story;

import java.util.List;

import dev.langchain4j.data.message.UserMessage;
import dev.langchain4j.model.chat.StreamingChatModel;
import dev.langchain4j.model.chat.request.ChatRequest;
import dev.langchain4j.model.chat.response.ChatResponse;
import dev.langchain4j.model.chat.response.ChatResponseMetadata;
import dev.langchain4j.model.chat.response.StreamingChatResponseHandler;
import io.smallrye.mutiny.Multi;
import jakarta.enterprise.context.ApplicationScoped;
import jakarta.inject.Inject;
import org.jboss.logging.Logger;

@ApplicationScoped
public class StoryService {

    private static final Logger LOG = Logger.getLogger(StoryService.class);

    @Inject
    StreamingChatModel model;

    public Multi<String> write(String topic) {
        ChatRequest request = ChatRequest.builder()
                .messages(List.of(UserMessage.from(
                        "Write a short story about " + topic + ". Keep it under 200 words.")))
                .build();

        return Multi.createFrom().<String>emitter(emitter ->
                model.chat(request, new StreamingChatResponseHandler() {

                    @Override
                    public void onPartialResponse(String partialResponse) {
                        emitter.emit(partialResponse);
                    }

                    @Override
                    public void onCompleteResponse(ChatResponse response) {
                        ChatResponseMetadata metadata = response.metadata();
                        LOG.infof("stream complete: finishReason=%s, tokenUsage=%s",
                                metadata.finishReason(), metadata.tokenUsage());
                        emitter.complete();
                    }

                    @Override
                    public void onError(Throwable error) {
                        emitter.fail(error);
                    }
                }));
    }
}

The REST resource stays trivial. It takes input, delegates, and streams the result back as Server-Sent Events. It does not know how the stream is produced:

// src/main/java/com/example/story/StoryResource.java
package com.example.story;

import io.smallrye.mutiny.Multi;
import jakarta.inject.Inject;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.Produces;
import jakarta.ws.rs.QueryParam;
import jakarta.ws.rs.core.MediaType;
import org.jboss.resteasy.reactive.RestStreamElementType;

@Path("/stories")
public class StoryResource {

    @Inject
    StoryService service;

    @GET
    @Produces(MediaType.SERVER_SENT_EVENTS)
    @RestStreamElementType(MediaType.TEXT_PLAIN)
    public Multi<String> stream(@QueryParam("topic") String topic) {
        return service.write(topic);
    }
}

Run it with ./mvnw quarkus:dev and consume the stream with curl, which is the right tool for SSE since the response is open-ended:

curl -N "http://localhost:8080/stories?topic=a%20lighthouse%20keeper"

The token usage and finish reason land in your logs the moment the stream closes, on the same call that streamed the text. The completed ChatResponse from the LangChain4j extension is where that payoff comes from: streaming and observability stop being a trade-off you make per endpoint. The placement of the metadata capture matters as much as the feature. It sits in the service, so the resource stays a thin transport and the orchestration has one home.

Reflection-free serializers, now the default

"Enable Jackson reflection-free serializers by default" is pure plumbing, and it ships switched on rather than waiting behind a flag. Reflection is the part of JSON serialization that GraalVM Native Image has always had to be told about, registration by registration. A reflection-free path is friendlier to native compilation and trims the reflective work the application does to move objects in and out of JSON.

The part that matters is the default. A capability you opt into helps the teams that already knew to look for it. A default helps the apps that never tuned serialization at all, which is most of them, and it applies on the next upgrade with no code change. That is the quiet kind of improvement that shows up as a slightly leaner build and a slightly cheaper request path across a whole fleet of services nobody is actively optimizing.

Reading a changelog like a senior

Most of the noteworthy lines here are about coding agents, so it is tempting to file the whole release under "AI" and move on. The more useful read sorts the lines by what they actually touch.

The AI skills line is architectural: it reshapes how your codebase and your agent relate over the long run, and compounds as more extensions ship skills of their own. The streaming-metadata line is about observability: it changes what you can see in production today, on the calls you are already making. The reflection-free serializer line is about runtime cost: it touches what your app does on every request, by default.

A candidate release rewards a careful read for exactly this reason. The line that gets the attention is the one that demos well. The lines worth acting on are usually the ones that change your numbers without asking for a press release.

What "blackboard" actually means

The blackboard is a coordination architecture from the late 1970s and early 1980s, made famous by the Hearsay-II speech-understanding system. The idea is simple to state and consequential to implement: you keep one shared data structure, the blackboard, that holds the evolving solution. Around it sit independent specialists (classically called knowledge sources). Each specialist watches the blackboard, and whenever the current state matches what it knows how to act on, it contributes by writing back to the board. A control component decides which pending contribution runs next.

The defining property is that no specialist knows the global plan, and the order of contributions is not fixed when you wire the system together. Coordination is opportunistic: whoever can make a useful move given what is currently on the board, makes it. The solution emerges from the accumulated writes, not from a route you drew in advance.

That is a real departure from the agentic workflows LangChain4j already shipped. A sequenceBuilder workflow runs A, then B, then C, in an order you decided at build time. A parallelBuilder fan-out runs every sub-agent and merges their outputs. Even the supervisorBuilder, which is the most dynamic of the three, is still hub-and-spoke: a single controller decides who acts and threads context to them. In all three, you can draw the graph before the first request arrives.

The blackboard is for the case where you cannot.

The decision rule

Here is the rule worth internalizing before you touch the new builder: reach for the blackboard only when the order in which agents should contribute is genuinely emergent, not knowable a priori.

If you can sketch the directed graph of who-runs-after-whom up front, you do not have a blackboard problem. You have a sequence, a parallel fan-out, or a supervisor routing problem, and those are simpler to reason about, simpler to test, and far simpler to debug. Picking a blackboard for a problem whose flow is actually fixed buys you nondeterminism you did not need.

The blackboard earns its complexity when the problem is shaped like this: you have many specialists, any one of which might hold the next useful move, and which one depends entirely on the partial solution built so far. Diagnostic reasoning, planning under incomplete information, multi-source interpretation where one agent's output is what makes another's contribution relevant. Those are the problems where a fixed route is a lie and a supervisor becomes a bottleneck guessing at routing it cannot pre-compute.

If you are building a multi-agent system on the JVM right now, whatever internal name it carries, the honest test is one question: can I draw the flow before the request comes in? If yes, a simpler shape already fits the problem, and the blackboard trades that simplicity for coordination the problem does not call for. If no, keep reading, because the rest of this is what a changelog was never going to cover.

The cost nobody counts

A blackboard is, by definition, mutable state that multiple agents read from and write to. LangChain4j already had shared state in its agentic workflows: the agentic scope that sub-agents access with readState and writeState. In a sequence or parallel workflow, that scope is incidental plumbing, and the framework controls when writes happen, at defined step boundaries. The blackboard pattern promotes that same shared state from plumbing to the central coordination mechanism, and it hands the timing of writes to the agents themselves.

So the prerequisite question before adopting the blackboard is concrete and unglamorous: what does LangChain4j guarantee about concurrent access to the blackboard, and what does it leave to you? Do not assume the shared state is thread-safe because the docs talk about agents instead of threads. Verify the concurrency contract, and design your agents' writes around whatever that contract actually is.

If those opportunistic writes run concurrently, you have reintroduced, inside your agent layer, the exact class of defect that enterprise Java spent roughly two decades learning to avoid: race conditions, lost updates, stale reads, cross-thread visibility gaps, and output that changes depending on which agent happened to write first.

This is not a hypothetical. It is the problem the Java Memory Model was rewritten to specify, the reason java.util.concurrent exists, and the motivation behind a generation of guidance on immutability, defensive copying, and happens-before reasoning. A senior Java engineer reading this already has scar tissue for it. The danger of the agentic framing is that the scar tissue does not automatically transfer: a "shared blackboard between agents" sounds like an AI architecture concept, and it is easy to forget that underneath it is the same HashMap-shaped hazard that has been failing code reviews since 2005.

A blackboard with no defined memory semantics under concurrent writers is a flaky test waiting to happen, and it will get blamed on model quality when the cause is concurrency you never guarded.

Auditability and versioning are not optional here

There is a second cost, and it follows directly from the first virtue. Because contribution order is emergent, you cannot reconstruct why the system produced a given output by reading the code. There is no fixed route to trace. The only place the explanation lives is in the history of the blackboard: which agent wrote what, in which order, in response to what prior state.

That makes auditability a structural requirement, not a nice-to-have you add later. A blackboard headed for production needs every write attributable to a specific agent, timestamped, and ideally versioned, so you can replay the sequence of contributions that led to an answer. This is the same lesson event sourcing taught enterprise Java: when state is mutable and many writers touch it, the durable asset is the log of changes, not the current value. Keep only the final blackboard state and your post-incident analysis of "why did the agents converge on this wrong answer" becomes archaeology without a record.

Treat the blackboard as an append-friendly, inspectable ledger of contributions, and you can debug it. Treat it as a mutable scratchpad, and you have built a system whose behavior you cannot explain to the person who has to operate it at 3 a.m.

The two release notes that change the math

Two other 1.16.0 additions are worth reading next to the blackboard, because they widen exactly the surface this post is about.

The first is the new AgentConfigurator, which the release describes as a way to define an external function for agents retrieval or creation. Listed on its own it reads like an ergonomics improvement. Read against the blackboard it is more pointed: opportunistic coordination sometimes needs an agent that was never pre-registered, summoned based on what is currently on the board. Dynamic creation and retrieval of agents is how you do that. It is also how you end up with writers to your shared state that did not exist at compile time and are not on any static roster. Powerful, and a direct expansion of the concurrency surface you just took responsibility for.

The second is about the Model Context Protocol: surface tool outputSchema on ToolSpecification. Tools exposed through MCP now advertise the schema of their output, not just their inputs. For a blackboard system this lands squarely on the auditability problem. If tool results are going to be written onto shared state, a declared output schema lets you validate and reason about what gets written, rather than parsing free-form text after the fact. Typed writes are auditable writes, and on a blackboard, auditability is the whole game.

The release also tightens state hygiene in a smaller way worth noting: output guardrail failures can now remove the violating AiMessage from memory, so a rejected contribution does not linger to poison later reads. On a board where everyone reads everyone, keeping bad writes out of the shared record is the same discipline as everything above, applied to memory.

Where this leaves you

The blackboard pattern is a genuine tool for a genuine class of problem, and putting it in a mainstream JVM library means Java teams no longer have to hand-roll opportunistic coordination to get it.

It is not a free promotion from the supervisor, though. Adopting it means re-taking on the concurrency reasoning and the auditability engineering that the JVM ecosystem already knows how to do, now applied to a layer where the abstractions are agents and the hazards are still threads. The teams that get value from it will be the ones who treat the blackboard as exactly what it is: shared mutable state, to be guarded, versioned, and logged with the same seriousness they would give any other piece of concurrent state in production.

So the move is unromantic. Reach for the blackboard when the routing is truly emergent and you have a record-keeping plan for the board. Keep your sequence, parallel, and supervisor workflows for everything whose graph you can still draw. The 1.16.0 changelog gave you a new shape of coordination. Whether it is an upgrade depends entirely on whether your problem actually has the shape the blackboard is for.