From my experience talking to community members, platform teams inside large organizations, and consultants in different industries, the key point that all make is that their platform teams are struggling to enable teams requesting more and more GenAI services. Every developer, SRE, DevOps person currently has access to Claude Code, Codex, Copilot among others. This is generating an explosion of tools that can be applied at different stages into the Software Development Life Cycle (SDLC). With more and more agents / services offered for teams to use, platform teams are feeling the heat of supporting a wide range of internal, external and SaaS services that solve very specific problems.

To be honest, this is nothing new. Every platform engineering presentation that I’ve seen in the last three years makes reference to the CNCF ecosystem, which we used to explain how hard it was for teams to keep up. The problem has now been multiplied hundred times.

Dealing with Multi-Agent distributed Systems

Let me put on my practical hat, and let’s be concrete. We are experiencing first hand the journey for hyper-automation. We are not talking about tools for GitOps, Security, Observability. We are talking about “autonomous” agents that perform very specific tasks. In general, one of the main characteristics of these agents is that they use GenAI to evaluate the context and produce an output. Examples of these agents are extremely popular these days:

• Coding Agents: such as Claude Code, that based on a prompt will produce code
• Pull Requests Review Agents: that review the code proposed in a PR and provide feedback, comments or automatically reject
• SRE Agents: that monitor a Kubernetes Cluster and can help SRE teams to troubleshoot issues
• Business Agents: agents that deal with customer requests, for example a chatbot that is connected to internal systems and can answer business requests.

I am pretty sure that platform teams didn’t ask for Claude Code to be given to all the organization developers, but platform teams are the ones responsible for making sure that accounts are managed, keys can be distributed and (if you are lucky) some reports about usage are generated.

We have reached a point where there is no way out, platforms need to rise to meet the demand of all these new workloads, which in most cases are far from our production environments. Some of these agents might run on Kubernetes, but some of them will run on your CI infrastructure (GitHub, Gitlab), some will run on each developer laptop, pushing your platform initiatives way outside of Kubernetes and your cloud provider accounts.

Another by-product of adding all these agents to the SDLC is that the shape of what it means to deliver software is mutating. If we are hyper-automating every step of the SDLC, human involvement and intervention shifts. This great article by Joe Kutner from Saleforces/Heroku makes it clear, our old SDLC was created for humans, so it must change now that we have agents.

But, Why?

Automating just for the sake of automating, usually doesn’t make sense. But automation always sounds nice, as it is commonly associated with saving money. I am quite happy to see that the industry is slowly aligning on a taxonomy/terminology about what we want to achieve.

Blog posts like this one from Dan Shapiro’s early this year are resonating hard in the industry as they start hinting at a concrete plan for what agents, but most importantly platforms will need to evolve. Dan’s blog post uses autonomous self-driven cars as an example which creates a perfect analogy for what your platform needs to be prepared for.

The goal: to build autonomous software factories.

The role of your platform: connect all the agents, internal systems and provide contracts that agents, humans and operators can use to operate the autonomous factory.

How?

To build such autonomous systems, you need to build strong foundations that agents and humans can use to drive things forward. Having a set of levels to gauge where your organization currently is, is extremely helpful to plan what your next move will be.

You will find these levels with different names and with slightly different descriptions, but it feels like we are getting close to some sort of industry-wide agreement.

Here are the five levels of Agentic Engineering that I see the industry is starting to align with:

1. Level 1 - GenAI Assisted: agents assist the user by providing alternatives and suggestions, the user drives the interaction and accept or reject suggestions. There are two examples that clearly resonated with me Grammarly and IDE auto-completion based on GenAI models.
2. Level 2 - GenAI Augmented: agents generate code, perform a task, the human needs to review the output. Tools like Claude Code, Codex, and tools like Cursor fits this level quite nicely. The question that most organizations are starting to ask is around how do they can manage all these tools using a platform approach.
3. Level 3 - Spec-Centric: agents generate and modify resources, but also review and provide proof/validation of behavior (tests reports, screenshots, etc) so the human only reviews intent, not line by line diffs. Specs need to be written to define intent and how it needs to be validated. This is closer to defining business requirements. Agents need to understand architecture, conventions and style that goes beyond a single repository. When you start writing specs, you need to go down to specific technology choices, so agents know what is off limits and what decisions have already been made.
4. Level 4 - Selective Autonomy: based on existing data (from previous executions in similar contexts) agents can make decisions on their own to move things forward autonomously in the SDLC. Agents can check and have clear guidelines to when they are authorized for example to approve and merge a pull request. At this level, a trust model needs to operate at the platform level to progressively let agents be more autonomous. To build trust models the big challenge is to collect and summarize data about previous executions, so agents can use evidence to make grounded on data decisions. Humans still need to handle escalations and override agents when things go off rails.
5. Level 5 - Full Autonomy (Dark Factories): humans provide specs, agents produce, review and ship changes. Humans intervene to improve the factory when failure emerges. Agents notify humans, but don’t ask for permission. It feels impractical to talk about this level as most teams are trying to progress from Level 2 to Level 3.

As you can see the level of sophistication required to move from level two to three is what is stopping organizations reaping the benefits of autonomous agents.

Unfortunately, to move from one level to the next, you need to fully master the previous level, as each level builds heavily on the previous one.

So what does this mean for our platforms?

If your platform already took care of packaging applications CI, CD with GitOps, security, observability you are well positioned for further automations. If you are already using DORA metrics to measure how your teams are performing you are in a really good spot. If you are not there yet, it is time to double down the investment on core infrastructure for your platforms, as highlighted by the DORA report on AI ROI.

Imagine that your developers are already generating code with tools like Claude Code, or that you can do automatic code generation from looking at issues descriptions. As teams have increased agentic generation of code, the review phase is still manually handled by humans, they are hitting a bottleneck. Adding agents to review your pull requests might be the next step for you but it will be clearly not the last one.

From GenAI Augmented to Spec Driven (L2 -> L3)

Your platform needs to understand what the intent of the change was being introduced so it can validate its behavior.

From a customer request ticket it needs to be able to validate that the change is not only correct at the code level, but at the behavior/intent level too.

By using GitOps tools like Flux CD or Argo CD, the creation of preview environments to validate changes is something that platform teams have automated already. The big shift here is to perform automated validations using specialized agents that by reading the issue description and proposed fix can validate the fix in a preview environment. I’ve seen companies using tools like vCluster to make preview environments (which are most of the time ephemeral) cost efficient.

Notice that for this flow to happen, the platform should already provide a set of mechanisms that set things up for agents to use and perform validations. Notice how different is to let agents use your existing platform constructs, compared with creating agents to use low-level APIs in a non-deterministic way to implement complex flows.

Implementing different release strategies at this stage might be also a good idea to perform deeper validations that might require live traffic or A/B testing. Using tools like Knative Serving or service meshes like Istio or Linkerd play a fundamental part of how platforms can enable this more complex validations.

Fine tuning this process is hard, and only by mastering this loop can you move forward to Level 4.

Before jumping to Level 4, there are two things that I would recommend platform teams to do to build a solid Level 3: Measuring the impact and dealing with non-determinism at the platform level.

Measuring the impact (DORA)

Generating, validating and making sure that changes follow all the way through production is expensive and time consuming. If the changes that we are making in favour of automation are not improving our delivery practices, investment funds will run out.

That is why I strongly recommend checking the “DORA: ROI of AI-assisted Software Development report” which helps organizations to plan for the AI tuition tax.

Organizations should expect a dip into their software delivery pipelines while adopting new tools. This usually materializes in a speed up on deployment frequency which is compensated by an increased failure rate. We are pushing for speed and we get instability in return.

But once again, in order to see what is going on, we need to observe/record way more than our production environment. We now need to ingest data from our delivery pipelines (CI/CD, preview environments), from our source version control platform (Github Issues and PRs, for example) and our customer support tickets.

Understanding the impact of AI adoption, follow similar patterns as adding any new tool to our stack. Without having hard data to compare, you are operating in the dark.

Dealing with non-determinism, a platform play

Quality stills matter. Every generated change that ends up in a Pull Request, will go through an expensive (resources and time) pipeline before it hits your customers, hence making sure that changes gets validated before pushing them through is a new platform concern.

Organizations have myriads of models to choose from and it is becoming a standard pattern to choose the best model for a given task as well as reviewing generated code from one model using another one.

To reduce cost and optimize resources, platforms need to provide golden paths to simplify these checks and evaluation loops. Developers shouldn’t worry about these checks and as mentioned before, validation can happen at a higher level (intent), but with a detailed technical report about which evaluations were executed for a given change.

A concrete example of a platform capability that a platform should provide is model selection based on previous performance or benchmarks. You can use external benchmarks or benchmarks based on data that you collect from previous code generation or previously executed tasks. To collect data, you can enable as a platform capability to run agents using different models for a given task (for example code generation for a given issue) and then use platform services to evaluate which performs better. While this is more expensive to start with, in the long run you will have enough data to make the right choices based on the tasks that your platform is performing more often.

From Spec Driven to Selective Autonomy (L3 -> L4)

In this scenario, to approve changes automatically means that you trust your validations/evaluations to be good enough to not impact your customers.

To build trust across your autonomous agents that the resources that they are managing (code, services, environments), you need data.

The only way to build trust is to record previous approvals, but also to measure how these changes are affecting your customers’ experiences. This requires being able to confidently say that your evaluations have been consistent for a set of services that your organization is ok to be driven by these agents.

The human involvement shifts from approval to trust validation. Where the task of the operators is to review the trust gates for services to be shipped and handle escalations when they happen.

From Selective Autonomy to Dark Factories (L4 -> L5)

The ultimate goal is to build a set of agents that can produce and ship new features, fixes bugs in a completely autonomous way. This level of sophistication requires a strong platform, a strong harness and a lot of data that needs to be used to make continuous decisions as new scenarios need to be managed.

The first players to build these advanced solutions will be the ones heavily invested in providing GenAI services. Claude Managed Agents, OpenAI Frontier, AWS Bedrock Managed Agents,  Google Gemini Agents Platform, the Langchain ecosystem, Crew AI, among others are paving the way in terms of requirements, developer experience and expectations.

Following the same approach to build our internal platforms to manage and operate distributed multi-agent enabled SDLCs is not a bad idea.

My experience in the tech industry tells me that these managed platforms aim to target 70% of the use cases, while most large organizations will struggle to re-platform their existing solutions to these new breed of managed services.

Similarly to what happened with Cloud Providers, when organizations go over acquisitions, mergers it will be quite difficult to escape a world where multiple of these managed platforms will need to co-exist and integrate. Keeping an eye on the standards that these platforms use, or to put it in another way, the decisions that they make to platform sticky are the core things to look out for.

Don’t Panic

As platform engineers we are now in charge of a fleet of agents, running all across our software delivery pipelines. We need to deal with how these agents access different models/services and make sure that these agents get the best model for the work that they are doing. In some ways, the platform is responsible for the output of these agents, as the platform must provide the validation/evaluation mechanisms to guarantee that agents are not going off the rails.

But, we have the tools, and the learnings from the Kubernetes, Cloud Native and Platform Engineering ecosystems. We know how to extend Kubernetes to support GPUs and host LLMs, we know how to efficiently create preview environments and do very advanced GitOps workflows, we know how to observe distributed systems.

The next layer on top of Kubernetes that we need to build, is the learning layer. To be able to learn, you need to record information and synthesize durable knowledge. If all these agents use the same standard format to export agents’ telemetry (such as the OpenTelemetry GenAI Semantic Conventions) this new layer can benefit from a huge ecosystem of components already using this format.

It is important to recognize that agentic engineering is not Kubernetes-first, agents will run inside and outside of our Kubernetes clusters and our platforms need to cater to both.

If you come from the Cloud Native ecosystem, you are trained to recognize the patterns and the tools to solve specific challenges. My recommendation today is to focus on unification, specs and standards.

As a practitioner, I am looking at what cloud providers and AI providers are building. I am taking notes and mapping the tools that we have in the cloud native ecosystem to help organizations to reuse the infrastructure we already have. GenAI providers are running LLMs on Kubernetes, they are running their managed agent platforms on top of Kubernetes.

As we learned from cloud providers, organizations can go that far only relying on cloud provider services. They need to build their internal practices, pay the AI tuition tax and at the end of the day build their internal platforms that adapt to their structure and operations.

As always, if you are working in this space and seeing similar things, do get in touch. I would love to collaborate with people building tools and pushing standards forward.

That question has no clean answer right now. And I think that’s worth talking about.

The fragmentation problem

When you instrument a Spring AI application with spring-boot-starter-opentelemetry, you get spans decorated partially decorated with OpenTelemetry’s GenAI semantic conventions: gen_ai.request.model, gen_ai.usage.input_tokens, gen_ai.system, and so on. These are vendor-neutral, CNCF-backed, and the right default if you’re running a general-purpose observability stack like Dash0, Grafana, or Honeycomb that support OpenTelemetry.

But the moment you start evaluating your AI application — looking at retrieval quality, latency by prompt type, model comparison — you’ll discover that the popular evaluation platforms don’t speak OTel natively. Arize Phoenix expects OpenInference attributes like llm.model_name and llm.token_count.prompt. OpenLIT and Traceloop’s OpenLLMetry each have their own naming schemes. LangSmith has yet another one.

Miguel Luna comparison of these schemas is the clearest breakdown I’ve seen of how deep this split goes. Take just the model attribute:

With these naming differences, creating a dashboard becomes a nightmare. These schemas reflect genuinely different philosophies about how AI operations should be categorized. OpenInference has a strict span.kind taxonomy (LLM, EMBEDDING, RETRIEVER, TOOL, etc.). OTel uses operation names and leaves categorization to consumers. Langfuse adds its own observation types (GENERATION, EVENT). While I see some convergence slowly happening towards OTel, these different conventions are definitely locking you in to a specific vendor.

So if you’re building a Spring AI application today and you want to send traces to both Dash0 and Arize Phoenix, you have a problem. With the standard Spring Boot starter, you’d need to write a custom ChatModelObservationConvention to emit different attributes per backend, and maintain it yourself as each upstream spec evolves. There is also no support for capturing LLM input/output,  and tool calls parameters and results which can be very useful for debugging and understanding sessions.

Enter Arconia

Arconia is a framework built by Thomas Vitale that sits on top of Spring Boot and Spring AI. I’ve been watching it closely, and its approach to semantic conventions is the most practical solution I’ve seen to this fragmentation.

The core idea: Arconia decouples your instrumentation code from the semantic convention schema. You write your Spring AI application once. You choose a convention by setting one property.

Pick any of: opentelemetry, openlit, openllmetry, langsmith

arconia.observations.conventions.opentelemetry.ai.flavor=opentelemetry

Note that to use openinference you need a separate dependency, as OpenInference don’t share any properties with Otel semantic conventions.

That’s it. No custom beans. No overriding getHighCardinalityKeyValues(). No convention adapter classes. The same application, five different schemas, zero code changes.

Setting it up

The dependency swap from spring-boot-starter-opentelemetry to Arconia is straightforward. In your pom.xml:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>io.arconia</groupId>
            <artifactId>arconia-bom</artifactId>
            <version>0.27.1</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>
...
<dependencies>
    <dependency>
        <groupId>io.arconia</groupId>
        <artifactId>arconia-opentelemetry-spring-boot-starter</artifactId>
    </dependency>
    <dependency>
        <groupId>io.arconia</groupId>
        <artifactId>arconia-opentelemetry-semantic-conventions</artifactId>
    </dependency>
</dependencies>

Check the Arconia recipe to migrate from Spring Boot OpenTelemetry to Arconia.

Arconia’s starter replaces spring-boot-starter-opentelemetry. It wraps the same OpenTelemetry SDK and Micrometer integration but adds a pluggable convention layer on top, unified configuration for different semantic conventions and expand the support for OpenTelemetry Metrics and logs instrumentation, not provided by the Spring Boot OpenTelemetry starter.

Where Spring Boot requires you to set spring.ai.chat.observations.log-prompt=true and write a custom observation convention bean to get prompt/completion content into spans, Arconia handles it through configuration:

arconia.observations.conventions.opentelemetry.ai.capture-content=none|span-events|span-attributes arconia.observations.conventions.opentelemetry.ai.include-tool-definitions=true arconia.observations.conventions.opentelemetry.ai.include-tool-call-content=true

These three properties replace the custom ChatModelObservationConvention I described in the previous post. That’s a real improvement. Custom beans that override framework internals are fragile. They break silently when upstream changes the API. A config property is a contract.

Five apps, five conventions

I’ve set up five variants of the Spring Merch Store application in the observing-ai GitHub repository. Each one is the same application (same tools, same chat client, same Anthropic model), differentiated only by which semantic convention it emits.

To run any of them:

git clone https://github.com/salaboy/observing-ai.git cd observing-ai/java/spring-ai-with-arconia/spring-merch-store-arconia export ANTHROPIC_API_KEY=sk-ant-... ./mvnw spring-boot:run

Swap the directory name to switch conventions. That’s exactly how thin the difference is.

What changes between conventions

Switching from opentelemetry to openinference doesn’t change the span hierarchy you saw in the previous post. You still get an HTTP span at the top, a ChatClient span, the advisor chain, the LLM call spans, and the tool call spans. What changes is the attributes on those spans.

Under OpenTelemetry conventions, a chat span looks like this:

gen_ai.system           = anthropic
gen_ai.request.model    = claude-haiku-4-5
gen_ai.usage.input_tokens  = 1308
gen_ai.usage.output_tokens = 58
gen_ai.response.finish_reasons = ["end_turn"]
Under OpenInference, the same span emits:
llm.provider            = anthropic
llm.model_name          = claude-haiku-4-5
llm.token_count.prompt  = 1308
llm.token_count.completion = 58
span.kind               = LLM

Both express the same information. But if you point your OTLP exporter at Arize Phoenix and your spans carry gen_ai.* attributes, Phoenix won’t know what to do with them. It expects llm.* and a span.kind label from its taxonomy. Without span.kind, Phoenix can’t categorize the span as an LLM call, and your evaluation dashboards break.

The OpenLLMetry flavor aligns closely with OTel’s naming but enables content capture by default, matching the behavior of the official OpenLLMetry SDK instrumentation. LangSmith defaults to span-events rather than span-attributes for content capture, which affects how prompt and completion text surfaces in the trace.

What Arconia adds

The standard spring-boot-starter-opentelemetry approach gives you auto-configured OTLP exporter for traces and logs (via the OpenTelemetry SDK) and metrics (via Micrometer), however, there is no instrumentation for logs, so no logs are actually exported. Spring AI’s built-in gen_ai.* span attributes, and ChatModelObservationConvention beans you can extend or override.

Arconia gives you all of that plus convention portability (switch backends without touching application code), built-in content capture without a custom observation bean, and convention isolation so upstream spec changes get absorbed by the Arconia dependency rather than landing in your code.

A word about convergence

I’ll be honest: I don’t think semantic convention fragmentation in the GenAI observability space is going away soon. OTel optimizes for vendor neutrality. OpenInference optimizes for evaluation workflows. OpenLLMetry optimizes for developer ergonomics. LangSmith optimizes for the LangChain ecosystem. These are legitimate differences, not just naming preferences.

The practical recommendation from Miguel’s comparison is to emit OTel SemConv as your baseline — every backend reads it — and layer on convention-specific attributes where your evaluation tooling needs them. Arconia puts this into practice: emit OTel to your primary observability backend, point an evaluation pipeline at the same app running with OpenInference conventions.

In my opinion, what we actually need is a clearer separation between operational observability (where OTel wins) and AI evaluation observability (where none of the schemas is good enough yet). I expect that separation to become clearer over the next 6 months as the OTel GenAI working group moves these conventions out of experimental status.

Until then, tools like Arconia that abstract the convention layer are doing genuinely useful work. Clone the observing-ai repository, run the five variants side by side, and see what the same application looks like through each backend’s eyes.

As always, if you have questions, opinions, or build something on top of this, find me on X/Twitter or LinkedIn. I’d love to see what you’re building.

The Workshop: Testing and Observing Agentic Applications with Spring AI

The week kicked off with a workshop I ran alongside Laurent Broudoux — from Postman / Microcks / Reshapr — focused on testing and observing agentic applications built with Spring AI. We had a great crowd in the room, and the conversation went deep fast. The workshop walked attendees through real patterns for asserting agent behavior, mocking LLMs’ responses, testing and mocking MCP servers, and making the invisible visible through traces.

The workshop code that can be found here https://github.com/salaboy/spring-io-2026-workshop shows how to start simple with a Spring AI application with local/internal @Tools to then expand to use MCP to consume REST and gRPC APIs. The workshop ended with Dapr Workflows for building durable orchestrations and running all the components inside a Kubernetes cluster.

We had fun with Laurent preparing and running the workshop, so expect more content, talks, and workshops around Observability, OpenTelemetry, MCP servers, Reshapr, and of course, Microcks for mocking.

Spring AI 2.x and the Agentic Push

The buzz around Spring AI 2.0 was impossible to miss. The project is maturing fast, and the upcoming 2.0 release brings a serious set of new patterns for building agentic systems. Two things stood out to me in particular.

First, Spring AI 2.0 ships with first-class MCP (Model Context Protocol) client and server libraries built in. MCP is the protocol that has quickly become the standard way for agents to expose tools and for orchestrators to consume them. Having that integrated natively into the Spring ecosystem rather than bolted on as an afterthought is a big deal for teams already invested in the Spring Boot programming model.
Second, the project is actively addressing patterns across the emerging protocol landscape — MCP, A2A (Agent-to-Agent), and ACP (Agent Communication Protocol) are all on the radar. Running multiple protocols concurrently and understanding the observability challenges that come with that is genuinely non-trivial. When you have agents calling other agents through different protocols, tracing a single logical operation end-to-end becomes a real engineering problem.

Congrats to Christian Tzolov, Mark Pollack, and the rest of the Spring AI team for all the insights they shared over the conference.

If you want to learn about Agentic Patterns with Spring AI, you should check this repository: https://github.com/tzolov/voxxeddays2026-demo,

Observing AI: Semantic Conventions, OpenInference, and a Maturing Ecosystem

The OpenTelemetry Gen AI semantic conventions are starting to stabilize, and this is genuinely exciting. For the first time, we have a shared vocabulary for what an LLM span should look like — what attributes to capture, how to represent tool calls, how to model embeddings. Without agreed conventions, every vendor builds their own schema and you end up with a bunch of incompatible dashboards.

On that note, OpenInference from Arize AI deserves a mention. OpenInference is an open standard for capturing traces from AI applications — it sits on top of OpenTelemetry and adds the AI-specific semantics. Arize has been pushing hard on tooling here, and I think the approach of building on OTel rather than replacing it is the right call.

At its core, the Spring team’s investment in Micrometer as the single abstraction over metrics, traces, and soon logs is paying off. Teams using Spring Boot get a coherent observability story without having to wire everything together manually. I want to thank Jonatan Ivanov and Tommy Ludwig for the very insightful session and the deep conversations on the observability roadmap.

The Arconia moment for observability

More observability conventions and challenges are popping up, and this is where I need to share my excitement about the Arconia project, introduced by my friend Thomas Vitale, who has built a bunch of features to improve the developer experience on top of the Spring Boot framework.

One of those improvements actually comes from expanding Spring’s support to the Otel GenAI semantic convention and supporting the OpenInference conventions while at the same time providing dev services to bootstrap tools like Phoenix Arize using Testcontainers.

I will be writing more about this, as I believe that, with the accelerated pace in the agentic and observability space, you sometimes cannot wait for frameworks to catch up; we all need to collaborate to bring solutions to new challenges. I am really looking forward to contributing my findings back to the Arconia project.

Big congrats to Thomas for the announcement 🥳🥳🥳

Barcelona, the Community, and What Comes Next

Beyond the technical content, Spring I/O is just a genuinely very special conference. Sergi Almar put together something that feels like meeting friends who share the same passion as much as a conference. I ran into so many familiar faces and met a bunch of new people I hope to stay in touch with.

I am super hyped about Spring I/O 2027, as it will happen in Valencia for the first time ever!!

The energy around AI in the Spring ecosystem right now is real, and it’s moving fast. Spring AI 2.0, the maturing observability stack, and the protocol convergence around MCP, Skills, A2A, and ACP are all happening simultaneously.

My personal takeaway matched what was shared at the conference: the Java ecosystem is strong because, with a flexible, agent-based programming model, organizations can build robust solutions that leverage all the enterprise integrations built over the last 20 years in the Spring ecosystem.

If you attended Spring I/O and want to compare notes, or if you’re working on anything in the AI observability or Spring AI space, reach out — you can find me on Twitter/X @salaboy or LinkedIn.

I’m not saying this to be critical of the Agent Skills specification. The spec, which Anthropic published in December 2025 and is now stewarded at agentskills/agentskills, does something important: it defines a shared format for knowledge assets that coding agents — Claude Code, Cursor, GitHub Copilot, Codex, and others — can discover and use to do their work more accurately. That’s genuinely useful. But the spec stops there. It says nothing about how to distribute skills, version them, verify their integrity, or consume them from inside a corporate firewall. And in my opinion, that gap needs to be closed, the sooner the faster we can move on to other more interesting topics.

We’ve Been Here Before

The cloud-native ecosystem spent years learning hard lessons about artifact distribution. Helm charts were shared as files attached to GitHub releases. WebAssembly modules were uploaded to ad-hoc buckets. Configuration bundles were copied between teams via Slack DMs. Each of these approaches had the same failure modes: no canonical discovery mechanism, no integrity guarantees, no reproducibility, and no supply chain security story.

The solution the community eventually converged on wasn’t a new protocol or a new registry format. It was OCI — the Open Container Initiative standards that most people associate with container images, but which are actually a general-purpose artifact store. Today, Helm charts live in OCI registries. WebAssembly components are distributed via OCI. FluxCD manifests, SBOM files, Sigstore attestations — all OCI. The lesson the cloud-native world learned is that you don’t need to reinvent infrastructure when battle-tested infrastructure already exists and runs at every major cloud provider, in every enterprise, and even on your laptop via Docker Desktop.

I strongly believe the same lesson applies directly to Agent Skills and other knowledge assets (that influence your coding agent and AI-infused applications’ contexts).

Distributing Artifacts using OCI

I’ve been talking with a bunch of people about this topic, including Thomas Vitale, who finally published a detailed proposal for packaging Agent Skills as OCI artifacts, covering the spec proposal and why this matter. He did a great job at going over the gap that the spec is trying to fill, for example having a OCI Image Manifest with a custom artifactType (application/vnd.agent-skills.skill.v1), and its contents — the SKILL.md, scripts, and resources already defined by the spec — are packaged as the artifact’s layers.

On the consumer side, a skills.json declares which skills a project depends on by OCI reference, and a skills.lock.json pins the exact digest of each skill at install time. This is the same model Go modules, npm, and Cargo use — and it works. You get reproducible installs across your whole team, clear upgrade paths, and a paper trail.

Because these are standard OCI artifacts, any compliant registry works. Docker Hub, GitHub Container Registry, Harbor, Zot, your company’s internal registry — it doesn’t matter. No new infrastructure to run, no new accounts to create, no vendor lock-in on the registry side.

Packaging and Sharing a Skill with skills-oci

Ok, but specs are hard to evaluate and understand, they require consensus, which is already very difficult but then adoption that can only be driven by people fully understanding the problem space.

For that reason, I’ve been building skills-oci, a CLI built on the ORAS Go client that implements the spec proposed by Thomas, and it shows an end-to-end experience to manage (package and publish) and consume skills. I am a practical guy, so I wanted a clean experience that integrates with the tools you are already using.

The core workflow — four commands to go from a local skill to a shared, versioned artifact on Docker Hub:

Package and push your skill:

To package and publish a skill to a container registry (in this case Docker Hub):

cd my-skill/
skills-oci push docker.io/salaboy/my-skill:1.0.0

Adding Skills to your Projects

From any project where you want to use the skill:

Inside your project directory, where you want to add a managed skill. Add it as a dependency to your project:

skills-oci add docker.io/salaboy/my-skill:1.0.0

Adding skills will create the skills.json and skills.lock.json file.

Cosign,

Install (re-fetch) all declared skills (resolves and locks digests):

skills-oci install

Verifying Skills signature and provenance

Using Cosign, you can check the container image signature and SLSA provenance:

skills-oci verify

That last command is not just cosmetic. Because the artifact is content-addressed via digest and can be signed with Cosign, verification is a real guarantee—not a checkbox. The full source and examples are at github.com/salaboy/skills-oci.

Registering the skills with your coding agent

Notice that I wanted to hook into the existing coding agent ecosystems, so I’ve included a command that automatically registers a startup hook with your coding agent, which will install (fetch and download) your skills when starting a new session.

skills-oci register

If we can distribute versioned skills that can be verified and dynamically loaded into our coding agents, we don’t need to push them to our git repositories, where they will diverge across projects and be hard to maintain. By default, the skills-oci CLI will add the .agents/skills/ directory to your .gitignore file so you don’t need to worry about stale copies of your skills. If you want to upgrade your skills for a given project, all you need to do is update the version in the skills.json file.

Free Supply Chain Security — No Extra Work

This is the part that genuinely excites me, and I think it’s undersold in most conversations about OCI for non-container artifacts. Because a skill packaged as an OCI artifact is just an artifact like any other, the entire cloud-native supply chain security toolchain applies immediately — with zero additional format work.

You can sign a skill with Cosign and attach a SLSA provenance attestation so consumers can cryptographically verify who built it and from which source commit. You can generate an SBOM with Syft and attach it as a referrer via the OCI Referrers API. You can run a vulnerability scan with Grype and attach the results so downstream teams can make informed decisions about which skills to adopt. None of this requires any new tooling — it all already works against any OCI-compliant registry.

For enterprises, this is the difference between “we allow skills” and “we have a governed, auditable skills pipeline”. That distinction matters as agent-assisted development moves from hobby projects into regulated industries.

What Still Needs to Happen

Let’s be honest, standardization takes time and it is really hard, companies want to own the space to control the ecosystem and to drive business their way. Companies like Vercel with skills.sh, Tessl, and other communities (for example, the skillsjar project) are pushing for their own solutions, their own packaging formats, and targeting audiences that are not particularly interested in reusing existing infrastructure at this point.

On the other hand, any seasoned engineers can point out, this is just the begining, as packaging skills only solves distribution, but not dependency management and relationships between skills and other artifacts, hence it feel like there will be a long journey ahead.

Regarding, the skills-oci CLI, I wanted to show the experience I want as a user when working with skills, but the tools aren’t important here; the spec is. The skills-oci CLI is written in Go and it can be also consumed as a Go library.

I feel quite optimistic about where this is heading — but optimism doesn’t write specs. If you’re building in this space, come help shape it. Try skills-oci, open issues, push back on the proposal if you think something’s wrong. The cloud-native ecosystem emerged through open debate, and I expect the agent skills ecosystem will need to do the same.

Drop me a message on Linkedin, X or open an issue at github.com/salaboy/skills-oci if you want to collaborate on this.

Last Thursday was my last at Diagrid, where I went knee-deep for the last three years into developer tooling, workflow engines, and, more importantly, how to smooth developers’ journeys when building complex distributed systems with a constantly evolving set of tools.

Today I am hyped to be joining Dash0 as an Ecosystem Engineer, because observability, and to be more concrete, OpenTelemetry has a big role, not only on the new stacks that companies are building, but also in how developers gain visibility about what their coding agents are doing. It is becoming clear to me that OpenTelemetry is the foundation for understanding agentic systems.

While companies are building new stacks using mature ecosystems such as Kubernetes and OpenTelemetry, new use cases are emerging as developers push more code than ever before, using tools that haven’t been tested at scale. Understanding what is going on is more important than ever.

Unfortunately, to safely deliver all the software generated today into production, understanding our production environments is not enough. We will need to understand: how code is generated?, how that process works for your organization?, how generated code behaves in production environments (is it deterministic or not)?, how do we evaluate non-deterministic errors?, and, more importantly, how to revert changes based on observed errors?.

I strongly believe that to answer these questions, we need standards that span developer tooling and the infrastructure that will run that code in production. Open Telemetry is strategically positioned to lead the way to other standards, such as the OCI (Open Container Initiative), for packaging and distributing knowledge artifacts so we can reuse not only existing infrastructure but also the practices we have evolved over the last 10 years. These standards are relevant to all the phases of the SDLC (Software Development Life Cycle), not only to developers, not only to DevOps, not only to production.

But let’s be honest: none of the mainstream tools being developed today have observability or industry standards (distribution provenance, security, auditability) as top priorities on their roadmaps. Hence, it is up to us, the “consumers”, the organizations, and the communities evaluating these tools to figure out how they map to the problems that we are trying to solve and how we can build production-ready solutions with them.

As always, you will see me out in the open, collaborating with and learning from the industry’s smartest people. I look forward to collaborating, building cool stuff, and interacting with communities spanning from developers and developer tooling to infrastructure and SREs.

When we started with Thomas Vitale on the project to write about Developer Experience for Kubernetes, we knew we would need to cover AI, LLMs, and other strange tools that would pop up as we wrote the book. This is the rule in our industry: nothing stays the same for a year.

Writing a book is always messy, and ideas tend to change a lot. To define core and fundamental topics that continue to affect developers working with cloud-native technologies, we focused on tools and practices that will remain a must for engineering teams moving forward.

But it is true: the industry has massively changed, both in terms of speed and the kinds of tools popping up. In the last year, we have seen new protocols, libraries, CLIs, and IDEs popping up like crazy and also changing at unprecedented speed. A tool you learn today may not be around tomorrow, and developers need to adapt.

In this blog post, I wanted to cover my biased journey to the land of coding agents and, instead of comparing the features of the different tools available in the market, focus on the fundamentals.

Stepping back from the day-to-day of using code-generation tools might help us seize opportunities and avoid mistakes that push us several steps backward. Based on my experience writing the Platform Engineering on Kubernetes book, I can assure you that whenever you talk about Developer Experience, you will, in some way or another, involve Platform Teams, so expect to see a lot of parallelism in this blog post. Whenever you need to deal with constant change and new tools, you can use all the things we learned when building platforms.

Before we start, a bit of a disclaimer: this blog post is not about building domain-specific or business agents. There are tons of frameworks popping up to create business agents, rather than code-generating agents. I’ve been following agentic frameworks for business purposes, and I am sure I’ll write about them in a separate article.

All the examples from the tools described in this blog post can be found in the following GitHub repository: https://github.com/salaboy/kubecon-eu-2026

Coding, before agents

The developers’ inner loop is a term that has been used for more than 20 years to describe the tasks that developers perform in a loop to get stuff done  (that is, creating new features or fixing bugs). These loops are well understood and learn by heart by developers (no matter which company they work for).

code → build → test → debug → repeat

These loops are time-consuming, as coding requires understanding what needs to be done and where the changes need to happen. Building is usually automated, but unless you work for a company with only one application, testing tends to be complex. If you are like me, when writing a feature or fixing a bug, you can plan for a couple of happy paths and some edge cases, but for the most complex scenarios, debugging is required.

Each of these activities takes time, and no matter which company you are working for, there are a couple of things that you, as a developer, need to master to be efficient while going through these loops several times a day:

• Tech stack-specific libraries and tools
• Company-specific (homegrown) frameworks and tools
• Company culture, practices, processes (where the source code repositories are, what my team can change and what we can’t, and already discussed and defined architectural patterns)

Moving companies means you, as a developer, will need to relearn most of this. While you can leverage your knowledge about a given framework or a programming language, getting accustomed to the company-specific procedures is just a painful process.

Over time, programming practices like TDD (Test-driven development) and BDD (behavior-driven development) have been adopted by different organizations, but I wouldn’t dare to call them standards. The larger the organization is, the more complex the code they need to produce, so more complex practices are required. Spec-driven development was also a thing back in the 2000s, with UML (Unified Modeling Language) as the de facto standard for defining software specs.

While these loops are focused on a single developer, it is important to add additional context on how they work.

requirements → inner-loops → code(PR) → outer-loops

These inner-loops main mission is to transform requirements (what needs to be done) into code. In my opinion, the value of a developer performing an inner loop lies in learning to translate ideas into code and mastering the technical skills required to do so. When I am performing manual inner loops, I am learning how complex systems work. It is totally valid to argue that after you have done several features and fixed bugs, there is not much more to learn, the learning process decreases over time, and tasks become repetitive and mundane.

After having produced code to implement a set of requirements, this code needs to be shared (usually in the shape of a pull request, if we are using Git), so the code can be reviewed, tested, and validated against other components, and finally merged into the main code base of our applications.

Note: other practices, like pair programming during inner loops, have proven very beneficial, boosting productivity and knowledge transfer, but, once again, these practices are in no way industry standards.

The outer-loop is when collaboration happens. As part of reviewing a pull request, I need to use the same mental model the creator used to produce the code and to apply my assumptions and understanding of the application to validate their changes. Once again, while reviewing pull requests, I do learn quite a bit, not only about the code changes, but also about the architecture of the application and how it will run in a production environment.

Coding, with agents

Let’s now talk about coding agents.

I will use Anthropic’s Claude Code because I’ve been following and using it more often than other tools. I do think that Claude Code is representative of the evolution of these coding agent tools.

Claude Code is designed to replace all activities in the inner loop by transforming prompts into code, running tests, debugging, and troubleshooting until the requirements are implemented. Someone can argue that you can give Claude code the credentials to also automate deployments and control the full software delivery cycle, but I haven’t seen this implemented at scale yet. If we focus only on the inner loop, it is important to say that Claude Code is a generic agent. Using an LLM model, an agent harness has been built to help replace the inner-loop tasks that developers used to perform. These coding-agent harnesses include all the workflows, tool calling, memory, guardrails, and understanding how to use local tools to get stuff done.

Claude Code is a CLI (terminal application), an IDE plugin, or even a web app that allows developers to write their prompts to generate code. I’ve tried IDE plugins, but the CLI still works best.

To see the level of change in these tools, Claude Code consistently requires you to upgrade its version every day, which forces users to fetch a 200~MB (monolithic) binary containing improvements (we all assume). How many large companies can accept this speed of change in a secure and reliable way?

I want to reemphasize that Claude Code is a generic tool that uses different LLMs depending on the task that we want to perform. On the CLI, you, as the user, can select which model to use, which prompts you to decide whether you are after a complex task or something that can be considered a “quick answer”.

Because it is a generic tool, there are things that can be done, but defeat the purpose in my opinion. For example, if you create an empty directory, run the Claude CLI inside that and prompt:

“Create a Spring Boot application that implements some REST endpoints to manage Customers”

It will do as told, but there are a few caveats. First, it doesn’t know which versions of the frameworks to use, so it will choose a popular version; it doesn’t understand your domain models, so the concept of a Customer will be defined as part of a generic code-generation process.

While this works, Claude is much more effective when context and guidance are provided. Unfortunately, context and guidance are what make Senior Developers, senior.

I know this sounds obvious, but after using Claude for quite a while, I’ve noticed a boost in my productivity when I scope the problem at hand. This is not only for Claude to be more efficient, but it also helps me think and learn while I let Claude generate code that it can test and debug until it does what I need. So here are a few practical examples:

• Instead of asking Claude to create a project, I create it and define the core versions of the frameworks I want to use for the application. I need to make sure that Claude does not change these versions or add new libraries without my approval. This can be done in different ways, such as using skills and guideline files, such as Claude.md (Agents.md) . There is a parallelism with creating templates in Backstage for developers to use when starting a project.
• Designing domain objects and APIs for a given problem is such a fundamental part of the process that providing that context helps, since the code generation is bound to those APIs. Having a centralized database of datatypes and structures that must be used by code generation would make sense for a large enterprise scenario where data standardization is a must, think about healthcare scenarios.
• Architectural decisions are always implicit in a senior developer’s mind when deciding on how to implement features. For coding agents, providing architectural guidelines completely changes the output. Failing to provide sufficient architectural guidance (only needed when building distributed applications) allows the model to make changes beyond what is already defined in the architecture. Think about how to provide coding agents with ADRs (Architectural Decision Records) related to the task at hand. Tools to find these ADRs and categorize them so coding agents can fetch the relevant ones sounds like a sensitive thing to explore.
• Using TDD is very rewarding, as you focus on writing tests first, covering happy paths and some edge cases, and then the code follows. If the APIs are already defined, then multiple features can be implemented in quick iterations. For me, this is where I’ve refocused my learning process. I force myself to identify which tests I need to pass so I can spend time reviewing the generated code.
• How we define what a development environment is (the tools needed to run all the tasks in the inner loop) is critical for the coding agent to perform these tasks. Currently, coding agents request many permissions, and if you mistakenly grant them too much freedom, unexpected things can happen. Sandboxes and control over which tools the coding agent can use are critical to making the whole process more reliable.
• It goes without saying, but if you don’t use version control, tracking iterative progress becomes really hard. There is a fine line between understanding what the coding agent is doing and complete chaos. If you cannot review a whole changeset at once, it is hard to keep up with the changes, and more importantly, it is hard to revert to a previous state.

Interestingly enough, coding agents are now introducing what is known as “planning mode”, where you can ask the coding-agent to question you about these topics, so it can have enough context to produce what is expected.

At this point, I tend to say these practices apply to all coding agents, but there is a problem…

Who owns the experience?

If I am upgrading a monolith 200~MB CLI (claude-code) every 8 hours as a user (or organization), I don’t have any control over the experience that I have with these coding agents.

As we experienced with cloud providers, organizations will want to craft their own custom experiences, moving away from generic workflows and guardrails that are not sufficient for their more specific scenarios. In the cloud space, this led to Kubernetes becoming the building block for companies to build their custom platforms. I see something similar in the coding agent space, tools that provide the basic building blocks so teams can craft and share their own experiences.

In that space, I see tools like Docker Agents showing some very interesting ideas enabling teams to own and share custom agents definitions.

Using a declarative approach (YAML) with Docker Agents we can define a team of agents, where each agent can use a different model to perform tasks and specify which tools are available for the agent.

You can run this team of agents now using docker agent run agents.yaml

This experience is available as experimental if you have Docker Desktop installed on your laptop. And I know, at first I was like, ok .. declarative team of agents, definitions, custom UI, cost control, and tools restrictions, cool. But what really caught my attention is that teams can share these definitions as OCI images.

By running docker agent share push ./agents.yaml salaboy/my-agent you can publish your agent definition to Docker Hub https://hub.docker.com/r/salaboy/my-agent . Now, if you have a team of developers all using coding agents, you can share these teams of agents with all the teammates and control these agent versions with all the tools that we already use for our application containers.

Are Docker Agents the solution to all your problems? Definitely not, but I do expect more tools following up on these lines.

Who controls the experience?

Well, if we can share agents’ definitions as OCI images, we should be able to also define with a high degree of control what these coding agents can see and do, but that is quite a hard task if the coding agent binary is running on a host machine (workstation).

Just to show an example, if you have the following directory structure:

And you move the project/ directory and start a claude code session:

You can prompt the agent to go, read and print the secrets in the ../secrets/ directory. The agent will ask for permission because it is outside of the scope of the project/ directory where the session was started.

This is not a problem per se, but it becomes a problem when the developer in charge has answered hundreds of similar questions. Wouldn’t it be nice to let the agent run in YOLO mode?

That is the problem Docker Sandboxes are to solve. With Sandboxes, you can control what a coding agent can see and do by running each session inside a microVM.

With a single command, I can start a Claude code session inside a sandbox and I can “mount” whatever directories I want the agent to have access to:

docker sandbox run --name my-demo-sandbox claude ./project

Mount is not the right word here, because sandboxes do file syncing between the microVM and the host machine. This also allows setting up directories of files in read-only mode, which makes the agent able to access the files but never (accidentally) change them.

Now, your coding agent (in this case, Claude code) can only see the contents of the projects directory and try to perform the same prompt as before to read the secrets, it will fail as the microVM doesn’t have access to those files:

That is a good first step; now we can limit the file system, but what about network calls? Sandboxes also include a network proxy that enables us to define network policies. For example, we can deny all connections to all hosts and only allow requests for api.anthropic.com and api.github.com by running the following command:

docker sandbox network proxy my-demo-sandbox \
  --policy deny \
  --allow-host api.github.com \
  --allow-host api.anthropic.com

If the coding agent tries to fetch content from different domains, it will be blocked by the network proxy:

We can control the file system access and the network access. Docker Sandboxes allow us to create sandboxes from templates,starts so we can control which tools the coding agent has access to inside the microVM. Once again, will sandboxes solve all your coding agent challenges?

Definitely not. I couldn’t find a declarative way to define these sandboxes, so we can encapsulate all the filesystem, network, and tooling rules in a single file that can also be shared among teammates as OCI images. Another big challenge for me, is that both Docker Agents and Docker Sandboxes are experimental features on the Docker Desktop app, so if you are using Podman or Rancher (with containerd) these features are not going to be available making me question Docker’s decision of bundling these tools exclusively Another big challenge for me is that both Docker Agents and Docker Sandboxes are experimental features on the Docker Desktop app, so if you are using Podman or Rancher (with containerd), these features are not going to be available, making me question Docker’s decision of bundling these tools exclusively with Docker Desktop.

Some big mental model upgrades

For a developer who has been coding for 20 years, having a coding agent handle all the coding was personally hard to accept. I think, in some ways, it’s a matter of personal preference; some people like using IDEs for large projects, refactoring, and code assistance, while others don’t.

I jumped from having maybe two or three sessions in my IDE where I could perform one task at a time to having five terminals with Claude code-crunching. I am still using my IDE to review code and run tests.

Is this truly progress? I think it is, but it also comes with some downsides, for example:

• The more senior you are (in both the developer and business domains), the easier it is to refine prompts. If you have done a similar task in the past, it is easier to define what it is and also what is expected.
• It is really easy to prompt for refactorings, even when it is faster to do them by hand. I do notice that I’ve become lazier because I can ask the agent to do it, but sometimes it is counterproductive
• Review time has skyrocketed; I’ve spent more time checking that what was generated actually works, and because I have five agents running in parallel, this is what consumes most of my time.
• Without guidance, some projects require more context than what is available. I’ve seen Claude choke on open-source projects that require scanning multiple dependencies to implement changes. Once again, if you have no idea how to scope the scanning, you end up wasting tons of tokens without achieving any usable results. Scenarios where Claude clones dependencies and leaves patched source code all over the place have become part of my day-to-day cleanup process.
• It is too easy to go into the crazy-loop-of-hell: prompt for a new feature -> tests are broken -> ask for tests to be fixed -> code is broken -> prompt to fix code -> other tests are broken -> code agent starts changing code in libraries that you depend on -> hell.

I am still typing to create prompts, I haven’t made the final leap of faith where I speak to the terminal :)

As a developer in 2026, besides all the specifics of the project that I am working on, I need to learn:

1. MCP: model context protocol to let my coding agents communicate with other tools
2. Skills: to provide context and specific knowledge to the coding agent about the tasks it will be performing
3. Agents.MD: to provide context, ADRs, and general guidelines that will be included with every prompt we send to the agent

Still, I feel that what I’ve delegated to coding agents is the coder in me, but I am still acting as the engineer in charge when I use these tools. I still need to review the tool; code review can also be assisted by an agent, but I still need to judge what is good or bad for a given context, and this is not an easy task when building complex distributed applications.

From a one developer mindset to enterprises

Projects in large organizations require much more than code generation, and I think we are, in some ways, missing the point. Deciding what to do has always been the most time-consuming task for companies. What made a company better than its competitors was never about how much code they could produce; it was always about what that code would automate or enable. Now, code is cheap, and we can produce it fast (if we have enough senior engineers to guide coding agents), so what is missing? Where are companies going to spend most of their valuable time?

• I think about collaboration among multiple developers in the outer loop. Right now, the focus is on assisted reviews, but we are still using Git as the central hub for collaboration. Is there a more efficient way to do this? Can this be abstracted away? I do see teams fighting over large pull requests where every team member is trying to defend what their coding agent generated.
• For teams using coding agents, I think about a prompt-to-code log: we don’t have a standardized way to track which prompt (context) generated each line of code. Imagine git blame but for coding agents. This can be used for learning and for refining context.
• It feels to me that it will be quite important for large teams to validate code complexity across entire applications, as well as for new features and changes. Right now, I see teams prompting for a feature or a bug fix without evaluating multiple parallel options. Again, we are overloaded with review tasks now, so adding parallel options evaluation at this point sounds crazy. Can this be automated?
• How requirements are mapped to code using the Gherkin format (GIVEN/WHEN/THEN) sounds like a good idea, but is it? Having pointers that trace code back to the requirement has always been a great idea, but it is becoming increasingly critical as the amount of code we generate grows day by day.
• Monitoring coding agents and observability on the developer side (in contrast to infrastructure) is becoming key to understanding how software is produced within an organization. Without having metrics and analytics about how this process is working, it will always be hard to measure what is working and what is not.

Working with platform engineers for a while now, we have already seen some common patterns in the cloud-native ecosystem. Let’s start with the most obvious one, vendor lock-in.

Claude code is a provider-specific tool; we have seen how companies have specific requirements, so a generic coding agent might not work for every context. The experience is 100% defined by Anthropic and constantly evolving; some companies will not accept 200MB black-box upgrades every day. Companies will want to define their own developer experience, tailored to their company’s needs and restricted to use the company guidelines. Providing the tooling with building blocks to build these coding agents makes total sense. Tools like cagent from Docker provide some of the building blocks to create your own experiences. Is cagent the ultimate solution? I don’t think so.

The collaborative aspect of coding agents remains unresolved. This raises several questions:

• Do we change the way we used to collaborate?
• Do we still need to use tools like git for version control? Can an abstraction layer be built to simplify collaborations?
• Do we use agents for pair programming?
• Multi-channel agents make a lot of sense, why not collaborate via Slack with your agents? -> https://github.com/sttts/slagent from Stefan

Next, how do we map intent to generated code? I want to be able to track down which prompt generated which code and the thought process (context, tools, and reasoning) behind the generation. Using the Gherkin (Given / When / Then) Definitelyformat might be part of the answer, as it helps us to connect requirements to code, as we can see here:

To this:

Related to this is the problem of keeping track of prompts, because with tools like Cucumber and Gerkin, we are tracking intent to code, not how the context is used to create that code.

This takes me to the final point. In 2026, observability in the inner loop becomes a key feature for teams using coding agents. Which prompts were executed, by which agent (sub-agent), how much did they cost, and did the code generated make it into the main project branch? Tools like cc-session by Roland or Argus for VSCode make the point that we need to understand how these coding agents are used to refine and improve our practices.

Sum up

The coding agents space is very vibrant, but it will need to undergo a similar transformation to the one we saw in the cloud-native ecosystem. Standards, common practices, and tooling that provide the building blocks for large organizations to build their own experiences.

Similarly to platform engineering, if we don’t have the right metrics and analytics to measure how these coding agents are working, it is really hard to tell whether things are working or just wishful thinking.

It does feel that we are still trying to figure out what kind of experiences we want for developers controlling or interacting with coding agents, and that is all good and interesting, but at some point, as we always do, we will need to take some of the core concepts and tools to be able to define what are the must building blocks that large organizations needs to enable teams of developers to control these agents.

I am eager to see where we reuse the tools that we already have to boost these experiences, such as OCI registries, declarative agent definitions, existing proxies and policies to secure our coding agents in the same way that we secure our workloads, and finally, standards like OpenTelemetry to observe and understand how these agents are operating at scale.

It is clear that even mature tools like Kubernetes need to adapt to this new agent era, but because coding agents are closer to developers and their workstations, the question remains: how do we bring all we have learnt from the cloud-native space to our developers’ laptops?

Ok, now time to go to KubeCon EU in Amsterdam. I hope to see you all there!

In this blog post, I will outline some ideas about the patterns I observe across various communities and vendors. Most of these tools, patterns, and approaches to using GenAI on platforms have been covered by my friend Viktor Farcic on his YouTube channel, which I strongly recommend you follow.

Here is my personal take on the matter.

A bit of context before we jump straight into the questions that we want to answer. We used and extended Kubernetes to build our platforms. We focused on APIs to simplify the consumption of platform services. We wrote a lot of glue to make this happen. Now that we have GenAI capabilities, teams consuming platform services want access to GenAI, platform engineers want to use GenAI to enhance their platforms, and there is a budget to adopt GenAI across the board.

The question is: how can we use GenAI to support platform initiatives while also providing GenAI capabilities to other teams that want to integrate these features into their applications?

Using GenAI for our platforms

With the rise of MCP, Agents, and prompt-based interactions, it makes sense to replace or extend our core platform APIs, which were built on top of Kubernetes APIs (REST endpoints), with an LLM-based prompt approach. This is not only for the sake of improving the experience, but also to gradually add capabilities emerging in the Gen AI space to our platforms.

Some basic prompts that can be used to demonstrate the value of this approach can be:

• “I want to provision a new development environment for Team A, which uses NodeJS and MongoDB to build their applications.”
• “I need a new S3 bucket for application X which will store a huge number of PNG pictures, provide connection details after provision and connect the application to the bucket.”
• “Which services can I use to obtain the latest updates on Customer X from our organization’s services?”
• “Look at all the Issues on these 100 repositories, and for every issue created, try to provide a solution by sending a pull request with fixes.”
• “Monitor all my continuous integration pipelines. If something fails, try to troubleshoot the error and send a fix, and run again.”

First of all, this is not revolutionary; we have done this with our documents (Grammarly), with our code editors (Copilot, Cursor, etc), and in almost every industry, you will find services that are now frontfaced by what looks like an LLM.

Let’s assume we want to go this way. What would be the challenges that you will face on day one?

First and foremost, you need to decide not only where to start but also if you are going to use Public or  Private LLMs. I will not go into the details, but at a high level, you will need to evaluate which option fits better for your organization, tomorrow and in the long run.

• Public LLMs
  • Is the LLM Service just calling public LLMs like OpenAI, Anthropic, and Gemini? Well, this is going to cost you a lot of money, directly proportional to the use of your platform services. Can you afford this cost?
  • The LLM will need to be enhanced with your organization’s information to be valuable, in this case by providing access to your platform APIs and other services. Are you working in a startup where there are few regulations on where data goes or which services you can expose to LLMs?
• Private LLMs
  • The real value of LLMs for organizations is having a custom set of models to perform very specific tasks tailored to the organization’s context. While a fair amount of use cases can be covered with generic models, if you want answers from your prompts that take only your organization’s knowledge into account, you need to train your own LLMs. This is not only costly, but laborious and requires a lot of expertise. Guess what, hiring people to do this is hard, and these experts are in high demand.
  • Whether you train or not, you still need to run your models. If your organization is highly regulated and you cannot interact with public services, you have no other option but to host your LLMs yourself.

No matter whether you decide to go with public LLM services (get your wallet ready) or if you want to host your LLMs on-prem, there are a few projects that you should check out:

• vLLM: full-on solution to manage, host, and route traffic to your LLMs that run on Kubernetes. This project helps you schedule LLM workloads that require GPUs to run at a usable speed. People from Google, Red Hat, and other companies are collaborating on this project.
• AI Proxies
  • Envoy AI Gateway (token-aware router): No matter which LLM provider you are using, having a proxy layer between your consumers and the LLM service allows you to set up quotas, filters, and policies for cost control or transformations to reduce the burden on consumers to know which LLM service to consume.
  • Dapr Conversation API: a higher-level abstraction to enable applications/agents to talk to LLMs without the need for a specific provider SDK to be included inside your app/agents.

System Integrations, we know how to do this

Going back to the challenges, I wanted to touch on the system integration issues teams will face when implementing such an extension to the existing platform APIs.

To make the LLM do more than just reply to text, we need to connect it to services so it can actually do something useful, such as automating platform tasks. To do this, the industry has settled on using the MCP protocol to connect LLMs to other services, so that, as part of user interactions with the LLM, the LLM can trigger actions on external systems.

Besides the network complexities required to secure and make these interactions resilient, MCP serves as the glue between a text-based world and a very service-oriented world, where APIs are the default way for developers and machines to interact with services. Here, I want to reflect on how APIs have served as contracts to define system-to-system and human-to-system interactions, with well-defined inputs and outputs and non-functional requirements. This makes the MCP protocol the perfect place to bridge the purely unstructured world of prompts to the heavily structured world of APIs.

In the world of MCPs, APIs are considered tools, and tools have their own contracts, so a translation layer is still required between the APIs in our organizations and the tools in the context of MCPs. This forced translation has led to an industry-wide push to advertise that every project, product, and service includes a built-in MCP server.

For example:

• Kubernetes MCP Server
• Argo CD MCP Server
• Crossplane MCP Server
• Awesome MCP severs list proves the point

What this means for an organization trying to enable its internal systems to be accessed by LLMs is some work to figure out how to call these services using the MCP protocol. Tools in this space are popping up to help companies create MCP tools from their existing service APIs.

An important change is that, as shown in the previous diagram, the services that were previously handled and hidden behind the Platform API can now be accessed directly by the LLM. In some way, this means that as platform builders, we will be in charge of defining how low-level we want our LLMs to be able to perform actions. Do we want the LLM to have access only to platform APIs, or to all the tools used to build the platform?

So at the end of the day, there is no centralized MCP server with a huge list of tools for an LLM to access all the services, but it follows a more distributed approach:

If we follow this approach, we can control, using RBAC, which tools each MCP server exposes and provides to the LLM.

If we focus on our platforms, it is difficult not to look into Kagent, a project created by Solo.io and donated to CNCF, which has attracted attention in this space, as it provides out-of-the-box agents that work with the Kubernetes APIs and other, more specific Kubernetes-based projects, such as Istio, Cilium, Helm, and Argo Rollouts.

Check kmcp and the agents registry announced last week at KubeCon

NOTE: You will find several reports about LLMs hallucinating and using way too many tokens if you give them a large number of tools [1], [2], [3]. This not only raises a scalability issue but also questions the need to craft custom solutions to give LLMs what they need at the right time.

The problem with this approach is that the LLMs have very limited tools for performing actions. This means that tools related to interacting with the Kubernetes APIs will require the LLM to know about Deployments, Services, StatefulSets; hence, achieving higher-level automations such as “connect my application to a database” could be extremely hard to achieve, as the Kubernetes APIs do not expose higher-level concepts such as applications and databases.

This takes us to the next iteration of this pattern. Let’s enhance our LLMs with concepts and their relationships.

Softening the contracts

What does a “Customer” mean? What does “Application” mean? What does “deploy to production” mean?

If you ask a public LLM about these concepts, you will get very generic answers, mostly coming from the training data (the internet), which will not make much sense for your organization.

One way to solve this problem is to use vector embeddings to represent concepts and their relationships (links), so that LLMs, when asked about Customers or Applications, understand exactly what this means for your organization.

With vector embeddings, we can ingest concepts and create relationships between these concepts, so when we create a fuzzy prompt to LLMs, we can use RAG(Retrieval augmented generation) semantic searches to supplement the LLM’s knowledge base.

By doing this, when prompting, we can be less specific about implementation details and focus more on the prompt’s desired outcome.

To give a more specific example, let’s imagine a team has been developing a new application that they want to deploy into a given environment. This new application depends on a relational database that hasn’t been provisioned yet.

A prompt to the platform can look like this:

“Deploy the application hosted in the following GitHub repository Y to environment X, but before make sure that a new database is provisioned for the application to use.”

To determine what needs to be done and where, the LLM can run a RAG search against the vector database to identify which tools from the Platform and Kubernetes APIs can be used to make that happen.

By looking at the platform APIs, it can retrieve the given environment, where a new application can be deployed. Also, by looking at the platform APIs, the LLM can understand how to build the application source code and create deployment manifests. Depending on whether the platform provides APIs to provision databases, a RAG search can identify which databases are available for applications to use, and applications can then directly use the available cloud provider APIs to create a new instance. Finally, it can use the Kubernetes APIs to bind the database to the application after deployment.

We have configured our setup to handle higher-level concepts and perform lower-level operations against the Kubernetes APIs when needed.

Using RAG to filter which tools LLMs can use to perform a given task is a pattern that is maturing quite quickly; hence, new tools to help teams implement these interactions are popping up in the market. The rise of tools like PG Vector (PostgreSQL vector database) are in high demand.

So the question is now: how does it know which database to use for a given application? How does it know which region this database needs to be provisioned in? How does it know how long this database should store data?

Companies’ guidelines, best practices, and policies

Providing our LLMs with access to Cloud Provider APIs, Kubernetes APIs, and third-party service APIs sounds really cool, but brace yourself: you are opening the door to pure chaos. As with people, when having access to all these resources, it is a good practice to have strict rules and policies on where resources are created, quotas, and which credit card is used to pay for them.

LLMs are no different; hence, providing access to our platform APIs should encode some of these policies, but we want to enable low-level interactions when needed. This means that we will need to teach our LLMs to also learn about our organization’s guidelines, policies, and best practices.

While we can provide LLMs with knowledge about company guidelines, best practices, and policies, it is recommended to have one last line of defence. Using policy engines such as Kyverno as part of our platform will let the LLM decide what to do, but it will not allow it to proceed with operations that do not adhere to company policies.

On this note, you can find the folks from Nirmata mixing kagent and Kyverno in this video. Where they show how the Kyverno MCP server can be used by Agents to create, check, validate and enforce policies.

If we stop for a second to recap what we have achieved so far, we can see that we have enabled LLMs with a bunch of new tools to perform actions on our behalf, we have softened our contracts by using vector embeddings and RAG semantic queries for the LLMs to be able to bridge the gap between fuzzy prompts and structured APIs, and we have provided the LLMs with organization knowledge to constrain its suggestions and actions to follow what the organizaiton is already doing in other projects. Still, the more tools and concepts we provide to the LLMs, the more coordination these interactions will require to be useful. Going step-by-step with an agent-assisting platform engineering team to achieve their goals requires more advanced state and resource management; we need workflows.

Workflows & Context Management

LLMs are stateless, have limited context sizes, and can get confused if we provide too many tools. This means that if we have a long chain of tasks to perform, we need more complex coordination and a state machine to track all the interactions.

It is also important to consider interaction patterns with platform builders and teams that consume platform services. Going back to the example that we used before:

“Deploy the application hosted in the following GitHub repository Y to environment X, but before make sure that a new database is provisioned for the application to use.”

Instead of expecting all this to be resolved in the background, our platform front-facing LLM-enabled service should guide the user to accomplish the goal by performing a well-defined set of interactions that provide advice on every option along the way.

What do we need to implement this to make sure that:

1. We have a way to define concrete and consistent steps that our agents will execute
2. Make sure we have a way to control what is set into the context for the LLM to have the right information to perform the task at a given point in time
3. Keep track of where the agent is at all times, so we can report back to the user, but also make sure that if something goes wrong, we can resume from where the agent left off

Guess what, Workflow and durable execution runtimes were created to solve these challenges. Imagine the following workflow that the agent can call to perform a set of actions in a sequence:

At each step, we can retrieve information from the vector database to refine the task at hand, check with other systems to gather more information, and perform and validate actions.

With workflows, we can break complex tasks into more manageable steps that can also be used to reduce “context pollution” and tool overload.

Using workflows, we can mix and match, letting our agents decide when to perform a chain of well-known tasks or execute separate actions based on user prompts.

The advantages of using durable execution frameworks to run our workflows include visibility into the agent state (since LLMs are stateless, the agent is responsible for maintaining state and progress for its operations) and durability. Durability is important because each interaction between our agents and LLMs costs money.

In a world where everything becomes a Tool exposed using the MCP protocol, workflows are here to provide a middle ground where the LLM can choose which workflow to execute in a non-deterministic fashion, but when a workflow is started, a set of steps will be performed in sequence to completion.

Workflows-as-tools is already a term that is being used to bridge this gap between the fully non-deterministic agents and agents that can choose to execute a set of tasks that require special and deterministic coordination across multiple steps.

If you are considering building these kinds of agents or applications, you should check out Dapr Workflows, which provides a Workflow-as-Code alternative for building durable agents.

If you are working with Python already, Dapr Agents provides a more opinionated programming model to create durable agents that implement all these mechanisms out of the box.

Other tools and specs that I am keeping an eye on are:

• Compass for context tracking and clean up
• Recursive RLMs instead of LLMs
• vLLM semantic router for tool selection, providing

Sum up

Bringing GenAI closer to our Kubernetes-based platforms requires platform engineers to wire a new array of services and tools. When I look at the patterns described earlier, I don’t see anything beyond new constraints and integration challenges.

As part of bringing GenAI services closer, our platform surface will expand we will need to manage more infrastructure, tokens, and services. Expertise in RAG frameworks and vector databases will become essential for platform teams in the near future.

As we have covered what it means to bring GenAI to our platforms, enabling development teams with GenAI services or features becomes a natural extension to the same problem. In the same way that our Kubernetes-based platforms became an enabler for teams that needed a Kubernetes-based environment for their applications, platform teams that manage to integrate GenAI services will be able to understand the nitty-gritty details of how these services are consumed, providing them as a service to others.

<Begin of AI Rant>

The fact that a presentation includes AI in its title or proposal doesn’t necessarily make it interesting.

I had the opportunity to talk to many folks who raised a very important issue. While AI is in hype, let’s make sure that we don’t forget about how we actually deliver software, the core libraries and tools that will not change even if AI takes full control of the development process. Logging remains essential for humans, testing is still necessary, APIs are important, and specs benefit both machines and humans in conceptualizing and architecting large-scale systems.

A constant across communities that I found fascinating is the lack of clear direction in tooling within the GenAI space. While numerous frameworks are emerging to build agentic systems, the clarity of the use cases these systems will implement remains a significant open question. As is typical in the industry, we are developing solutions for problems that have yet to arise.

<End of AI Rant>

With all that being said, I had a fantastic time at both Cloud Native Denmark, happening in the beautiful city of Aarhus, and Devoxx Belgium, happening in Antwerp.

The software industry is vibrant with the GenAI bubble, but the good thing is that all this movement promotes new ideas, new patterns, and new challenges that we will need to tackle in order to keep our software development and delivery practices updated and efficient.

Cloud Native Denmark

Organized by Cloud Native Nordics (with around ten thousand members) and previously part of the KCD events, this was the third edition of the conference. With around 450 attendees, the conference is very targeted to platform engineers in the cloud native space.

If you are in the Nordic countries and haven’t attended these events, despite working daily with Kubernetes, I strongly recommend checking out the next edition in Copenhagen, Denmark, in 2026.

As I shared in my keynote session, these events are where you meet people from whom you can learn. In our field, where we learn almost every day, attending these events not only fosters personal growth but also creates opportunities for cross-organizational collaborations.

I had great chats with Mads from Lego about Open Source, and my good friends Andrea from Overstory, Kasper from Dash0 (and organizer), and Abdel from Google.

It was interesting to see, as part of Andrea’s keynote, how important Dagster (a data orchestration platform, mostly Python) was to the journey to improve operations. Seeing real-life use cases where technology is applied to solve concrete problems is always refreshing, as it demonstrates the before and after of adopting new tools to improve company operations.

From Abdel, I took a lot of notes about llm-d (llm-d: a Kubernetes-native high-performance distributed LLM inference framework), a tool I’ve been looking for a while but haven’t had time to dig deeper into. Learning about the architecture and reasons behind this tool’s existence was also refreshing. In a saturated market of tools, unification, reuse of common specs, and existing components to solve new problems only start to emerge where the problems we are trying to solve make sense.

Running GenAI on Kubernetes is not easy, and you need ot be ready to spend some money on GPUs, but understanding how these projects work and which components from other projects are being reused is quite important to mature the ecosystem.

Check out all the professional pictures from the Conference here

Devoxx Belgium

At Devoxx Belgium, you have the opportunity to mingle with a lot of Java Developers. With more than three thousand attendees, I had the pleasure of presenting with my good friend Laurent from Postman / Microcks about creating and testing distributed applications that include workflows and LLM interactions.

Here are the slides for the presentation:

In this session, we focused on an updated version of the Pizza Store, which uses Dapr Workflows, Spring AI to handle pizza orders across multiple services. You can find the source code of this demo that you can run on your laptop in the following repository https://github.com/salaboy/pizza (notice we used the agentic-workflow branch)

If you are interested in this topic, you can check the following article in Dzone that goes into more details around Dapr workflows and Spring AI

https://dzone.com/articles/durable-agents-with-spring-ai-and-dapr

I had the chance to hang out with old colleagues from Drools/JBPM (Red Hat / IBM now) from the Quarkus team, including Roberto, Mario, Kevin, Kris, and Geoffrey, who provided me with a lot of insights about the Quarkus community. They are doing an amazing job with Langchain4j, hence it is worth keeping an eye on. I was fortunate to attend the Langchain4j BOF, where discussions centered on implementing new agent interaction patterns and the value of developing more complex mechanisms, given the unclear use cases.

I find it fascinating how all the agents’ discussion is leaning towards re-implementing mechanisms that we have implemented 100’s of times before such as human in the loop pattern highlighted by the linked example.

I had the opportunity to spend some time with Roberto Cortez discussing the Dapr Quarkus Extension, which Matheus Cruz has been working on extensively, and I’m pleased to report that progress is being made. Expect a blog post about this soon, too.

I would say that Roberto’s session about how to create Quarkus extensions and Quarkus internals takes the prize of most valuable session.

Spring presented Spring Boot 4, and although it’s bringing some good features, I wasn’t particularly excited. That’s why I was happy to see Thomas Vitale over the weekend about the Arconia been working on.

Stay tuned for more news! The next stop is KubeCon NA, happening in Atlanta, US, in November.

As an industry, we have made significant leaps forward to fill the gaps and created new practices and frameworks to help organizations keep pace with these technological changes. While there is hype around AI today, and how LLMs will produce code for us, we are still in an industry that is measured purely by how good or how innovative the end-user solutions we create are. We need to deliver changes to our users; it doesn’t matter how we do it, but we just need to ensure that we are efficient and serious about the whole process.

Writing, talking, and sharing with organizations extensively about Platform Engineering in the Kubernetes space led me on a journey where the tools being discussed are often closer to infrastructure than to developers. The natural next step is to bring developers closer to platform engineering teams, but different expectations, backgrounds, tooling, and priorities from both sides make these conversations slow and unproductive.

In November 2024, Thomas Vitale (author of Cloud Native Spring in Action, with Kubernetes) and I signed a contract with Manning Publishing to co-author a book on Developer Experience on Kubernetes. The Manning Early Access Program (MEAP) was announced at KubeCon EU 2025 (check our KubeCon session about the topic), and it is now available on their website.

Manning Early Access Program - DevExp on Kubernetes

Writing a book is not done in a basement, away from everyone; similarly to my previous book, we are writing this book with the help of different communities that provide advice, reviews, early feedback, and valuable input to make the book more useful for a wider audience. As it is a tradition for technical books, we are hosting all the examples on GitHub, free of charge and totally independent from the book https://github.com/devex-on-k8s/book

If you are interested in developer experience in the cloud native space, we encourage you to get in touch, check the examples, and explore the MEAP.

Our current table of contents is divided into three parts:

1. The inner loop: tasks, friction points, and tools
2. The outer loop: optimization, APIs, system integrations, and observability
3. How to bring Platform Engineers and Developers to collaborate more efficiently

We aim to provide practical experience with open-source tools to solve real-life problems and identify how we can create smoother developer experiences by leveraging the expertise of cloud native communities. With Thomas, we are extremely passionate about helping platform teams understand the value of crafting end-to-end developer experiences. At the same time, this book helps developers understand the value of platform services and initiatives that can simplify the entire software development lifecycle.

To keep this blog post short, please check my DevBCN presentation on the topic, which provides an overview of what the book is about and showcases some of the tools we are covering.

My week is going to be hectic, but as usual, the most important factor for me is to meet people, make new connections, and learn about what is going on in the cloud native space.

Before we start all activities on Sunday with Cloud Native Rejekts, I am joining the “Is it Observable?” webinar with my friend Henrik Rexed today, Friday 28th, at 4pm. You can join us here: https://www.youtube.com/watch?v=7Pv2ktWr2cw

Cloud Native Rejeckts (30th/31st March 25)

Starting with Cloud Native Rejecktsexcellent on Sunday, I am looking forward to that pre-conference vibe with extremely good speakers and smaller rooms for deeper conversations.

Highlights on Sunday:

• Podman and Podman Desktop: State of the Union
• Building Air-Gapped Control Planes for a Global Pharma Leader Using Crossplane and ArgoCD

Highlights on Monday:

• Simplifying cross-cloud, cross-cluster connectivity with Dapr & Cilium
• Making GenAI CLI Agents Work for Your DevOps Day-to-Day Operations

Unfortunately, on Monday, I cannot attend the presentation from Alice Gibbons and Manuel Zapf, who will be showing Cillium and Dapr working together across clusters. If you have the chance to participate in the session, I totally recommend it.

Maintainers Summit (31st March 25)

On Monday, I am eager to see how the Maintainers Summit goes. While this event is not for everyone, I will take enough notes to share with a broader audience. I am really looking forward to the TAG restructuring workshop as this represents a significant re org of how advisory groups inside the CNCF will work. Specifically, I am keen to see how I can be part of the TAG Developer Experience, which is key to bringing developers closer to the cloud native space.

Co-located events (1st April 25)

On Tuesday, life gets busy at the co-located events.

Starting with a presentation at 9:45am with Julia Morgado Furst titled Streamline Your App Development With the Power of Cloud Native Tools - Julia Furst Morgado, Veeam & Mauricio Salatino, Diagrid for the first ever Cloud Native university co-located event.

CNCF-hosted Co-located Events Europe 2025: Streamline Your App Development With the…
View more about this event at CNCF-hosted Co-located Events Europe 2025

This will be followed by a presentation at 10:40am at the Platform Engineering Day co-located event with the legend Viktor Farcic. Titled The Past, the Present, and the Future of Platform Engineering - Mauricio Salatino, Diagrid & Viktor Farcic, Upbound

CNCF-hosted Co-located Events Europe 2025: The Past, the Present, and the Future of…
View more about this event at CNCF-hosted Co-located Events Europe 2025

While these are two completely different presentations and co-located events, I am super hyped to collaborate with such a diverse group.

Next, I will be doing some book signings at the Synstasso booth at 12pm at their booth, you can find more details here.

Later at 3:30pm, there will be more book signings with my friends at Loft Labs, who are always happy to promote the book.

As you can see there will be more signings on Wednesday and Thursday.

KubeCon Keynotes and sessions (2nd, 3rd and 4th April 25)

There will be a lot of interesting sessions and keynotes happening during the week. I recommend looking at the schedule to see who is presenting and where before arriving at the event.

If you want to follow along and visit the Diagrid booth to say hi, here are all the sessions about the Dapr project: https://www.diagrid.io/events/diagrid-dapr-kubecon-cloudnativecon-europe-2025

I strongly recommend you folks to attend

• Marc’s session about durable executions with Dapr Workflows: Failure Is Not an Option: Durable Execution + Dapr = 🚀 - Marc Duiker, Diagrid
• AndI am very hyped to see Yaron and Roberto from Nvidia to present about Dapr Agents: Dapr in 2025: Durable Execution for Agentic AI Systems and Becoming the Backbone of App Platforms

On Thursday, I will be doing a short presentation at the Learning Lounge, where I will be sharing some tips about how to progress your career from being a developer to a platform engineer:

Super important! Don’t miss out your spot in the Diagrid + Upbound party! Sign up now!

Finally, on Friday, I am presenting with my friend Thomas Vitale about developer experience on a presentation titled: Breaking Barriers: Bringing Application Developers Closer To the CNCF - Thomas Vitale, Systematic & Mauricio “Salaboy” Salatino, Diagrid

This presentation aims to create and promote more specific channels to bring application developers closer to platform engineers so we can build better platforms.

As always, I will take a lot of notes during the event and share my slides, demos, and pictures at the end of the event.

Say hello! Don’t be shy!

If you see me running around the conference, please stop me to say hi! Let’s talk tech!

If you want a copy of my book, check out the book signing times!

See you all there!