From September 21–24, I attended “Activating Kubernetes and Private AI on VMware Cloud Foundation,” an advanced bootcamp held at Broadcom’s Atlanta office in Georgia. The four-day program combined technical discussions with hands-on labs, exploring Kubernetes architecture and Private AI infrastructure in enterprise environments.

Designed for Broadcom’s strategic partners, the instructor-led training focused on VCF Architects responsible for developing and delivering VMware Cloud Foundation services and solutions to customers. Throughout the program, the emphasis was on connecting architectural decisions with practical implementation.

Kubernetes: Beyond the Initial Deployment

One of the bootcamp’s two main tracks explored VMware vSphere Kubernetes Service (VKS) architecture. Sessions covered the platform’s full lifecycle, including design, networking, security, migration, and lifecycle management.

GitOps-driven continuous delivery was another important topic, highlighting approaches to managing configuration and changes consistently.

For our work, this broader perspective matters. Building a Kubernetes platform involves planning for day-to-day operations, upgrades, and evolving requirements alongside the initial deployment.

Private AI: From Architecture to Implementation

The second track focused on VMware Private AI Infrastructure, addressing the foundations needed to deploy and operate AI workloads at enterprise scale.

The program progressed from architectural principles to practical deployment, configuration, and optimization. It also explored proven, repeatable implementation patterns that can serve as a foundation for future projects.

This track reinforced the importance of aligning infrastructure decisions with application requirements and business objectives. Platform design, resource allocation, and operational considerations all contribute to how effectively an organization can support AI workloads.

Putting Concepts into Practice

The combination of instructor-led sessions and hands-on labs helped connect architectural concepts with concrete implementation steps. Technical discussions provided context, while the labs offered opportunities to put those concepts into practice.

Together, the Kubernetes and Private AI tracks provided complementary perspectives on developing services on VMware Cloud Foundation, from supporting modern applications to preparing infrastructure for AI workloads.

Bringing the Knowledge Back to Our Team

The bootcamp was an opportunity to deepen my technical knowledge and explore approaches relevant to our customer projects. The topics covered provide useful reference points for assessing requirements, discussing architecture options, and planning implementations.

I return from Atlanta with a broader understanding of VKS and VMware Private AI Infrastructure, along with ideas to share with our team. The next step is to apply that knowledge to the practical challenges our customers face and use it to inform future solution design and delivery.

Not through a course. Through a cloud you build, operate, break, and repair with your own hands.

Cloud computing is usually taught through presentations: architectures, diagrams, definitions. The problem is that no one has ever kept a cloud up and running by looking at a diagram.

That is why, in September, we launched an internal academy based on a different premise — you learn OpenStack exactly the way you will use it: by working hands-on with real infrastructure, from the first day to the last.

What It Is, in Short

A hands-on, eight-module program lasting approximately nine weeks, part-time.

By the end, each participant will have installed OpenStack from scratch twice — once entirely by hand, to see every individual piece, and once using the tool currently used in production.

They will operate it day to day, deliberately break it and repair it without reinstalling it, recreate it through code, and, in the end, place it behind a firewall they configured themselves.

Everything takes place on a real cluster, with dedicated servers — not on a simulator and not in a “toy” environment. Each participant gets an entire server, with production-grade resources at their disposal.

The Journey

The journey starts from the ground up, with the fundamentals — Linux, networking, and Ansible — where each participant builds the lab network they will use throughout the rest of the program.

Only after the groundwork is in place do they move into the OpenStack architecture: what components exist and, more importantly, which components talk to one another and why.

The first installation comes next, done entirely by hand, with no automation whatsoever — a mini-cloud built piece by piece, specifically so that nothing remains a black box.

That understanding then becomes the foundation for the real, multi-node deployment with Kolla-Ansible, the tool currently used in production.

With the cluster up and running, the program continues with day-to-day operations — projects, quotas, volumes, backup and restore — followed by the academy’s core module: troubleshooting.

Toward the end, everything is recreated through code using Ansible and Terraform, and the final piece adds a security perimeter around the infrastructure, configured with pfSense.

The eight modules are not independent: each one builds on what the previous one produced, and nothing is discarded along the way.

The router you build manually in the first week is the very gateway through which OpenStack is installed later — and the exact component you replace with a professional firewall at the end.

That is precisely why the exercises cannot be reordered at will: each one carries an explicit dependency on those that came before it.

The Philosophy: No Step Comes Pre-Written

The essential difference from a tutorial is that the exercise sheets never give you the finished configuration.

They tell you what needs to be achieved and where to look — the rest you have to figure out yourself.

It is the only way an exercise truly builds a skill rather than simply producing a successful copy.

When you get stuck, you are not given the solution, but a question that narrows your search.

It is slower, and that is exactly the point.

The Core Module: Troubleshooting

The part I am most proud of as a mentor is the troubleshooting module.

We deliberately “break” each participant’s own cluster in a controlled way — without telling them where or what was changed — and they have to work from symptom to root cause and prove the fix, exactly as they would during a real overnight incident.

It does not matter that they guessed which file was changed; what matters is that they understand the mechanism and can demonstrate, through a clear verification, that they fixed it.

Every fault is repaired live, without reinstalling — because in production, you never have the luxury of starting everything over from scratch.

What I Believe Matters Most

After all these modules, my conviction is simple: infrastructure can only be learned by working with it hands-on.

A cloud you have built yourself, broken, and brought back to life teaches you in a few weeks what a year of theory could not.

Beyond the technical side, the academy also builds a reflex that stays with you for life: the discipline of always working with a safety net.

You verify before you make a claim, you always have a way back, and you never cut off the branch you are sitting on.

These are not OpenStack lessons — they are engineering lessons.

OpenStack is simply the ground on which you practice them.

An opinion piece by Mihai Chihaia, Chief Revenue Officer at dvloper.io

Artificial intelligence is rapidly changing the way software is built. Generative models can now write code, generate tests, document applications, and automate an increasing share of tasks that, until recently, required a developer’s direct involvement.

But if AI can generate code increasingly well and increasingly fast, what role is left for the person who writes it?

In these exceptional circumstances, both in their nature and significance, technical expertise is not becoming less important. Quite the opposite.

As the volume of code we can generate increases, it becomes even more important to have people who can understand what needs to be built, why it should be built in a particular way, and whether what AI has produced is actually correct.

“The problem is not that AI can write code. The problem is that we can now generate a huge amount of code, very quickly. If this process is not governed by people who understand architecture, security, performance, and the long-term implications of technical decisions, we can accumulate technical debt at a much faster rate than before.”

This is one of the major changes AI is bringing to software development. The tools are getting faster, but speed is not necessarily, or always, synonymous with value.

A system can be built faster while also becoming harder to maintain, more vulnerable, or more expensive in the long run. That is why the skills that will matter increasingly are those that allow developers to see the problem end to end.

Understanding business requirements, knowing when to challenge a requirement, choosing the right architecture, assessing security and performance risks, and validating AI-generated outputs are becoming at least as important as writing the code itself.

As code becomes easier to generate, the developer’s value therefore shifts from the ability to write code to the ability to decide what code is worth writing, how it should be built, and whether the outcome is the right one.

This transformation, however, is not limited to technical departments.

Across organizations, the temptation to view AI as a direct substitute for people is growing. Some companies have tried to reduce headcount quickly, assuming that AI agents would be able to take over employees’ work.

In practice, however, the limitations of this approach are becoming apparent. AI is an extremely powerful tool, but its value depends on how it is integrated into the organization.

AI needs context.

To operate effectively within a company, it needs to understand processes, data, the relationships between them, business rules, and the boundaries within which it can make or recommend decisions.

“That is why I believe the real transformation is not ‘humans versus AI,’ but a redesign of how work gets done. Some activities will be automated, others will be augmented by AI, and people’s roles will evolve toward areas where judgment, context, accountability, and creativity remain essential. I do not think the main question should be how many people AI can replace, but what we can build differently when people and AI systems work together.”

In this new context, the software development services market is changing as well.

The traditional model, based largely on the number of people and days required to deliver a project, is being challenged by the productivity gains enabled by AI. We are already seeing, and will increasingly see, hybrid teams in which people work alongside AI agents throughout the development lifecycle, from coding and testing to documentation and code review.

A Technical Lead with strong AI expertise can coordinate not only a team of developers, but also multiple specialized agents.

Under these conditions, the number of man-days no longer necessarily reflects actual delivery capacity. If an activity that previously required several days or several people can be completed much faster with AI, the value of the service can no longer be defined solely by the time spent.

We can therefore expect a shift from capacity-based models toward services evaluated on outcomes and value.

Clients will be less interested in team size and more interested in what a provider can deliver, how quickly it can deliver it, at what level of quality, and with what degree of accountability for the outcome.

The same principle applies at the management level.

Solutions marketed as an “AI CTO,” “AI CFO,” or even “AI CEO” are already appearing on the market. AI can analyze vast amounts of information, quickly identify correlations, build scenarios, and synthesize data in a very short time.

For an executive, these capabilities can radically change how decisions are made.

But leadership is not just about processing information. It means taking responsibility, understanding context, managing people, negotiating conflicting interests, and making decisions when the data is incomplete.

AI can support these processes, but accountability for the decision does not disappear.

This need for transformation also underpins AI Factory, a framework developed by dvloper.io to standardize the components and processes that recur across AI implementation projects, from access to data and models and integration with existing systems to agent orchestration, identity and access management, security, observability, and outcome evaluation.

The goal is to enable organizations to move from experiments and proofs of concept to AI solutions that can operate effectively in production, without having to build every project from scratch.

In early September, part of the dvloper.io team was in Las Vegas for VMware Explore 2026, the annual Broadcom / VMware event for the people who build and operate private cloud. Four days at the Venetian, 400+ technical sessions, Hands-on Labs, certifications, and plenty of hallway conversations with people facing the same problems our customers face. Here is a short recap of what we did there and what we brought back.

What we did there

We worked on three fronts: technical sessions on Private AI and agents, the Private AI workshop, where we went hands-on with the VCF + Private AI Services stack, and direct conversations with Broadcom teams and ecosystem partners about what already works in production versus what is still on the roadmap. That last part matters: with AI, the gap between a slide and a shippable product is exactly what you need to understand before promising anything to a customer.

The technical themes that matter

The message of the year: AI is becoming a normal workload in the private cloud, and VMware Cloud Foundation 9.1 is the platform everything runs on (models, data, agents) without data ever leaving the datacenter. A few concrete things we took note of:

• Private AI Services in VCF: model serving, data indexing and RAG directly on existing infrastructure; model-as-a-service with validated models (Gemma, Qwen, Nemotron, GLM) selected per workload, rather than a single "official" model.
• VMware AI Factory: from hardware (GPUs, bare metal through the MetalSoft integration) to an operable AI environment, treated as an operating model rather than an isolated data science project.
• AgentMinder: the governance layer for AI agents, covering identity, authorization, policy and observability. Once an agent is calling APIs and touching data at machine speed, the question "who is it, what is it allowed to do, and what did it actually do" becomes mandatory. For us, the most relevant announcement at Explore.
• Tanzu Platform 10.4 agent foundations: agents become a normal application workload. AGENTS.md + manifest → cf push, service binding to a platform-hosted LLM and tools through an MCP gateway, with observability built in. No separate stack just because the application became agentic.
• AI-ready data: an ingestion, structuring, governance and lineage pipeline that publishes data products with semantic context for agents. The least glamorous topic, and the one that decides whether an enterprise AI project succeeds.
• AI in operations and security: AI Assistant for VCF (conversational diagnostics, AI-assisted Management Pack Builder) and AI assistants in vDefend / Avi for multilayer defense against AI-accelerated attacks.

This is exactly the direction we are already taking with our enterprise customers: private AI, on their own infrastructure, with agents that reach production only if they are governable.

dvloper.io on stage

Marian Tudosoiu, CTO of dvloper.io, delivered a presentation at Explore on The Database Modernization Ladder, explaining VMs to Containers on VMware Cloud Foundation.

What's next

Explore moves to Resorts World Las Vegas in May 2027. Until then, what we saw in Vegas goes straight into our projects. If you want to talk about what Private AI or AI agents would look like in your infrastructure, get in touch.

SharePoint is often seen as a place to store documents, publish announcements, and share information.

For this project, we wanted to take it further. The goal was to create a central platform for internal ISO compliance information and the processes that sit around it. Employees needed a clear place to find published policies, acknowledge the ones assigned to them, access training material, and follow their own deadlines. Administrators and process owners needed dedicated areas for managing policies, controls, evidence, risks, training, and reporting. Rather than treating those activities as separate tools, we brought them together within Microsoft 365. The result was a SharePoint website designed to make structured compliance work feel more connected, easier to follow, and easier to maintain over time.

SharePoint as the Foundation

Modern SharePoint pages provided the foundation, but the core of the experience came from custom SharePoint Framework web parts built with React. This allowed us to create focused interfaces around the work people actually needed to do, instead of sending them directly into raw Lists.

The portal includes dedicated experiences for policy management, controls, evidence, risks, training, dashboards, tools, and the homepage. A policy owner can create or update a policy, submit it for review, and follow it through approval and publishing. A reviewer can open a control or evidence item, add review notes, and update its status. A user can see assigned policies and training, confirm acknowledgment, and update training progress.

Behind these pages, SharePoint Lists provide the structured data layer. They store the records and relationships that make the portal work: policies, controls, risks, evidence metadata, training courses, assignments, events, categories, frameworks, and other reusable reference data. This keeps information consistent across the different web parts. A risk can be connected to relevant controls, evidence can be connected to a control and related policies, and training can be assigned to people or groups.

Document libraries complete the picture. Evidence files and training materials are stored in SharePoint, while the portal provides the task-focused interface around them. Native SharePoint version history also supports the policy lifecycle, allowing new versions to be created while retaining the history of the previous record.

This combination gave us the flexibility of SharePoint as a Microsoft 365 platform, while still allowing the website to feel tailored to the process rather than to the underlying data structure.

Creating Clear Handoffs for Power Automate

Not every part of a process needs to happen in a flow. We kept immediate actions inside the web parts wherever possible: creating records, changing statuses, acknowledging policies, uploading evidence, assigning training, and updating progress.        

For work that can take longer or needs to continue in the background, the portal creates a dedicated SharePoint request record or updates a flag that an automation can process. This creates a clear handoff between the website and Power Automate.

One example is the audit evidence package request. A user can create the request from the evidence area, choose the relevant audit period and framework, and then see the request status in the portal. Power Automate can process that request in the background, assemble the required information, update the same request record, and add a package location when the result is ready. The website can then expose the completed package from the request history.

The same pattern is used for policy upload requests. The web part extracts the information from an uploaded policy document and creates a structured request record for the next stage of processing. This keeps the browser experience responsive while preserving a visible history of what was requested and when.

The repository also contains workflow specifications for policy approvals, reminders, reviews, training notifications, risk follow-up, and audit activities. These flows are tenant-side components and are managed separately from the SPFx package. Keeping the boundary explicit made the solution easier to reason about: the web parts manage the user interaction and the List records, while Power Automate can manage the asynchronous work around them.

Bringing Reporting Into the Portal

The portal needed to show more than individual records. It also needed to make the overall state of the compliance programme easier to understand.

The homepage brings operational information together from SharePoint Lists. Depending on the user's role, this can include policy status, framework coverage, evidence activity, training completion, open risks, recent activity, and upcoming events or deadlines. Employees can focus on their own assigned policies and training, while administrative users can access broader indicators and navigation into the relevant areas.

For more advanced reporting, we embedded Power BI reports inside SharePoint. The dashboard web part supports configurable report URLs for the executive overview, audit status, policies, training, risks, evidence, and controls. That keeps reporting close to the processes and information it represents, without forcing users to move between a separate reporting portal and the operational website.

Power BI has a specific role in this solution: reporting and monitoring. It provides visibility into trends, status, and coverage. The website does not use it as a decision engine. Decisions such as approving a policy, reviewing evidence, or changing a risk status remain part of the defined process and the responsible user's work.

Authentication and Role-Based Access Control (RBAC)

Security was a core design principle of the solution. Instead of implementing a custom authentication system, the website leverages Microsoft Entra ID for identity management and SharePoint's native permission model for authorization.

Authentication

Users authenticate using their organizational Microsoft Entra ID accounts through Microsoft 365's Single Sign-On (SSO). This provides:

• Secure enterprise authentication
• Seamless access without additional logins
• Centralized identity management
• Multi-Factor Authentication (MFA) support (if enabled by the organization)

Because authentication is handled by Microsoft 365, the React-based SPFx components automatically execute within the authenticated SharePoint context.

Authorization (RBAC)

Role-Based Access Control (RBAC) is implemented using a combination of Microsoft Entra ID groups, Microsoft 365 groups, and SharePoint site permissions.

The access model consists of:

• Microsoft Entra ID Security Groups for managing organizational user memberships.
• SharePoint Modern Site Permissions (Owners, Members, and Visitors) to define site-level access.
• SharePoint Groups to simplify permission management for pages, lists, and document libraries.
• Modern Page Audience Targeting and page permissions to ensure users only see content relevant to their roles.

Rather than assigning permissions to individual users, access is granted to groups, making administration scalable and reducing maintenance overhead.

Development and Deployment

The portal was developed using the SharePoint Framework (SPFx) with ReactJS, enabling reusable, component-based development while integrating seamlessly with SharePoint Online.

Development

The application was built as a collection of independent React components and SPFx web parts, where each major page or feature was developed as a separate component. This modular approach improved maintainability, simplified testing, and allowed features to evolve independently.

Although the functionality was split across multiple web parts, they were packaged together as a single SPFx solution, making deployment and version management much simpler.

The development workflow included:

• ReactJS for building responsive UI components
• SharePoint Framework (SPFx) for SharePoint integration
• TypeScript for type-safe development
• SharePoint REST APIs and Microsoft Graph for data access
• Reusable components shared across multiple pages
• Local Development and Testing

During development, SharePoint's standard SPFx development workflow was used for local testing.

The application was tested using the local SharePoint Workbench and hosted Workbench, allowing individual web parts to be validated before deployment to SharePoint Online.

Deployment

After development was complete, the project was bundled and packaged into a single SPFx solution package (.sppkg).

Deployment was performed through the SharePoint App Catalog using the Manage Apps interface.

The deployment process consisted of:

• Bundle the solution using the SPFx build tools.
• Generate the .sppkg deployment package.
• Upload the package to the SharePoint App Catalog.
• Deploy the solution across the tenant.
• Add the required web parts to modern SharePoint pages.

Packaging all web parts into a single solution simplified application updates, versioning, and deployment across environments.

Power BI Development

Reporting and analytics were developed directly within the Power BI Service using its web interface.

Interactive dashboards were connected to SharePoint data sources and published for secure access within the SharePoint portal. Reports were then embedded into modern pages, allowing users to view analytics without leaving the application.

Power Automate Development

Business workflows were implemented using the Power Automate web portal.

Flows were designed to automate processes such as:

• Approval workflows
• Notifications
• List item updates
• Document processing
• Integration between Microsoft 365 services

These cloud flows were connected to SharePoint lists and document libraries, enabling business processes to run automatically without requiring custom backend services.

Conclusion

This project demonstrates that SharePoint can be much more than a document repository. By combining SharePoint Online, React-based SPFx web parts, Microsoft Entra ID, Power Automate, and Power BI, we built a unified platform that supports the day-to-day activities of an ISO compliance program while remaining entirely within the Microsoft 365 ecosystem.

Rather than relying on multiple disconnected applications, the solution brings together content management, business processes, reporting, authentication, and automation into a single experience. SharePoint Lists provide the structured data layer, document libraries manage files, SPFx delivers task-focused user interfaces, Power Automate handles long-running workflows, and Power BI provides operational visibility through interactive dashboards.

An important design decision was to keep responsibilities clearly separated. The web application focuses on user interaction and data management, Power Automate executes asynchronous business processes, Power BI delivers reporting and analytics, and Microsoft Entra ID, together with SharePoint permissions, enforces security and role-based access control. This separation makes the solution easier to maintain, extend, and evolve over time.

The result is a scalable, modular, and maintainable architecture that demonstrates how the Microsoft 365 platform can be used to build modern line-of-business applications—not by replacing SharePoint, but by extending it with the capabilities of the wider Microsoft ecosystem.

At the end of August, our team, together with our strategic joint venture partner AxelCore, will be in Las Vegas for VMware Explore 2026, where we'll be meeting with customers, partners, and members of the VMware community to discuss the future of enterprise private cloud.

Every year, VMware Explore brings together customers, partners, architects, consultants, platform engineers, and technology leaders from across the VMware ecosystem. But beyond the product announcements and technical sessions, its greatest value has always been the conversations.

This year, we expect many of those conversations to revolve around a common theme: the renewed strategic importance of private cloud. 

The Conversation Has Changed

For years, enterprise infrastructure discussions revolved around one destination: the public cloud.

Today, the conversation is different.

Organizations are increasingly prioritizing control, resilience, predictable costs, AI readiness, and operational consistency. Rather than asking whether to move to the cloud, they’re asking what kind of cloud architecture will best support the business they want to build over the next decade.

For many enterprises, Vmware Cloud Foundation has become a key part of that conversation.

Why VMware Cloud Foundation Matters

Modern infrastructure is no longer just about virtual machines.

It must provide a consistent platform for enterprise applications, Kubernetes workloads, AI initiatives, networking, storage, automation, and security, all operating as a single, integrated environment.

VMware Cloud Foundation helps organizations move beyond managing individual infrastructure components toward operating a unified private cloud platform. The result is greater operational consistency, simplified lifecycle management, and an architecture designed to evolve alongside changing business needs. 

What Enterprise Leaders Are Prioritizing

Across the organizations we work with, several strategic priorities continue to shape infrastructure decisions:

• Accelerating VMware Cloud Foundation adoption.

• Simplifying infrastructure operations through unified management.

• Modernizing data centers without increasing operational complexity.

• Expanding Kubernetes and platform engineering capabilities.

• Building secure, resilient, AI-ready infrastructure.

• Delivering consistent operations across on-premises, edge, and cloud environments.

These aren't isolated technology initiatives.

They're strategic business decisions that determine how quickly organizations can innovate, adapt, and scale in the years ahead.

Technology Alone Isn't Enough

Choosing the right platform is only the beginning.

Successful VMware Cloud Foundation adoption depends on sound architecture, careful planning, implementation expertise, and practical operational experience. The organizations seeing the greatest success are those that combine the right technology with experienced engineering teams capable of delivering complex enterprise transformations.

That's why Professional Services continue to play a critical role in helping organizations turn strategy into successful implementation.

A Community That Continues to Move the Industry Forward

One of VMware's greatest strengths has always been its community.

From VMUG events to VMware Explore, architects, consultants, platform engineers, customers, and partners openly share ideas, lessons learned, implementation experiences, and best practices. That collaborative culture has helped shape the VMware ecosystem for years and continues to accelerate innovation across the enterprise infrastructure landscape.

It's one of the reasons we look forward to VMware Explore every year.

Meet the dvloper and AxelCore Teams in Las Vegas

Together with AxelCore, dvloper delivers VMware Professional Services to Broadcom customers across North America. As a Broadcom Expert Advantage Partner, we help enterprise organizations accelerate VMware Cloud Foundation adoption through consulting, implementation, and modernization services.

If you'll be attending VMware Explore 2026, we'd love to connect.

Whether you're planning your next VMware Cloud Foundation initiative, evaluating your private cloud strategy, or simply interested in exchanging perspectives on where enterprise infrastructure is heading next, we'd welcome the opportunity to continue the conversation.

See you in Las Vegas.

In today's fast-paced tech landscape, traditional education often falls short of preparing developers for the realities they'll face in production environments. Our Core Competencies Academy bridges this gap—not by lecturing from a textbook, but by immersing learners in authentic, end-to-end application development with experienced mentors guiding every step.

From Linux Basics to Kubernetes: A Practical Progression

The academy's curriculum isn't designed around theoretical milestones. Instead, it mirrors the actual journey developers take in their careers. Students begin with the fundamentals—setting up Linux environments, configuring networks, and learning to work with the command line—skills that form the bedrock of professional development. This hands-on approach immediately builds confidence and removes the intimidation factor that often accompanies technical education.

But the magic happens through collaboration and mentorship. Rather than working in isolation, students have access to experienced mentors who understand the "why" behind each technology choice. When architecting a Document Manager application, mentors help students make informed decisions about databases, APIs, and security frameworks. This real-world guidance prevents the common pitfall of learning technologies in a vacuum without understanding how they work together in production systems.

Building Teams, Not Just Individuals

As students progress through backend development, frontend integration, and containerization, they're not just accumulating technical skills—they're learning to think like production teams. The curriculum deliberately intertwines frontend and backend tasks, forcing students to consider API design from both consumer and provider perspectives. When configuring Docker containers and Docker Compose, they experience firsthand the challenges of service orchestration and inter-service communication.

This integrated approach teaches the collaborative mindset essential in real workplaces. Students learn that a great API means nothing if the frontend can't consume it efficiently. They discover that containerization isn't just an operations concern—it directly impacts development workflow and deployment reliability. These insights come through doing, with mentors available to help when assumptions prove incorrect.

Authenticity in Learning: From Local to Production-Ready

The academy emphasizes real-world constraints. Students don't deploy to magical cloud environments; they build on personal VMs and local Kubernetes clusters, managing volumes, configuring ingress controllers, and setting up CI/CD pipelines. When they encounter the friction of managing secrets, configuring CORS, or troubleshooting container networking, they're experiencing the genuine problems that senior developers solve daily.

Setting up a self-hosted GitLab Runner, configuring kubectl, and deploying with Kubernetes manifests—these aren't academic exercises. They're the exact workflow that modern DevOps teams use. By traversing this path with mentorship, students don't just learn how to do these things; they develop intuition about why each step matters and how to adapt these patterns to new challenges.

A Culture of Continuous Improvement

Perhaps most importantly, the academy fosters a culture where questions aren't obstacles—they're opportunities. Mentors encourage students to design their own application architecture, choose their own technology stack (with guidance), and make decisions about trade-offs. When a student chooses Go over Java, or Vue over React, mentors help them understand the implications and learn from those decisions.

This approach transforms technical education from passive consumption into active collaboration. Students leave not just with a portfolio project, but with the problem-solving mindset, the confidence to make architectural decisions, and the experience of working with mentors who've walked the same path before them.

The Core Competencies Academy recognizes that great developers aren't created by completing tasks—they're forged through authentic challenges, thoughtful mentorship, and the collaborative spirit that defines modern software teams. It's education that prepares you not just for your first job, but for a career of continuous growth and meaningful contributions to real-world systems.

The journey from Linux basics to Kubernetes deployment is more than a technical curriculum—it's an apprenticeship in the craft of software development.

When a system is down, a token has expired, or the process just died mid-investigation - is the part you actually have to build.

Anyone can build the support-bot demo. Wire a capable model to a ticket, give it read access to a couple of APIs, and watch it diagnose a clean failure on stage. It looks like magic. It is also the easy 20%.

Then you put it in front of a real queue. Unattended. Overnight. Reaching into half a dozen live systems, any of which can be slow, broken, or mid-deploy at the exact moment the agent knocks. The demo agent doesn’t survive that. It stalls on the first timeout, loses its place on the first restart, and the next morning you find a row of half-finished investigations and no record of what they tried.

The hard part of an autonomous support agent isn’t the diagnosis. It’s persistence, the unglamorous discipline of not losing your place when the world around you misbehaves.

We borrowed the idea from the agentic coding tools we already live in, like Claude Code: a loop that keeps its footing. It remembers what it’s done, retries what failed, adapts when a step is refused, and picks up where it left off. None of that is the model. It’s the scaffolding around the model. So when we built our support agent, we treated that scaffolding as the product, not an afterthought. Here is what it actually takes.

1. The work has to outlive the process

Every ticket becomes a durable job, not a request held in memory. It lands in a queue that lives outside the agent, so if the worker is killed mid-investigation (deploy, crash, OOM, a careless kill -9), the job is still there when the lights come back on.

And it comes back honestly. On restart, anything that was “running” when the process died gets caught and marked, not left hanging as a zombie that the dashboard quietly lies about. The state of every job is always queryable, always truthful. That’s the floor: the agent can die, the work cannot.

2. The agent has to remember what it did

Every step the agent takes (each model turn, each tool call, the command it ran, the result it got back, the action that was blocked, the assumption it had to make) is written to an append-only log as it happens, one line at a time. Think black-box recorder, not a summary written at the end (the end is exactly when you don’t get to write anything).

So any investigation can be replayed after the fact, in order, by anyone. This is the difference between “the agent failed, please investigate” and a complete transcript of what it tried, in what sequence, and where it hit the wall. One of those is a ticket nobody wants. The other is a colleague’s handoff notes.

3. Degrade, don’t die

The agent depends on systems it doesn’t own: a secrets store, an orchestration API, the ticketing system, the platform’s own APIs, the log store. In production, “all of them healthy at once” is the exception, not the rule.

So a dependency being down is a condition the agent handles, not an exception that kills it. If it can’t resolve a particular tenant’s credentials, it doesn’t abort; it proceeds with whatever it can reach, and it says so plainly in the record. If an access token expires mid-run, it refreshes and keeps going. The agent is built to do useful work with partial information, because partial information is the normal case.

4. A blocked action is a message

The agent is read-only by construction. Anything that could change state is blocked at the gate before it ever runs: no writes, no deletes, no destructive commands, no exceptions. You don’t trust an unattended agent not to do damage; you make damage impossible.

But here’s the part that matters for persistence: when the sandbox refuses a command, it doesn’t throw an error that unwinds the whole run. It hands the agent a readable reason (“that path is read-only; use the query endpoint instead”), and the loop continues, with the agent adjusting its approach. Same trick the good coding agents use. A denied tool is feedback, not a fatal error.

5. Exhaust the layers before you escalate

The agent investigates in layers, from the cheap broad signals down to the specific deep ones, trying alternatives and dropping to the next source when one comes up empty. It only escalates to a human after it has actually run out of things to check.

And when it does escalate, it doesn’t dump a shrug into the queue. It hands over the full context, what it confirmed, what it couldn’t reach, what it had to assume, and what it recommends next:

Investigation: Inconclusive, escalated to on-call.

Confirmed:
• Instance exists, in ERROR state, on a region reporting healthy capacity.
• Tenant quota not exhausted.

Could not reach:
• Per-tenant secrets (store timed out) → continued with reduced access.

Assumptions logged:
• Fault attributed to scheduler, inferred from the most recent platform signal.

Recommended next actions:
• Route to on-call with the trace below; confirm scheduler health for that region.

That is not a bot giving up. That is a co-worker who did the legwork, knew the limits of what it could see, and tapped the right person on the shoulder with everything they need.

The business case, said plainly

The reason this is worth the upfront work shows up in four places:

• Continuity. It survives the 3 a.m. restart. The queue doesn’t lose tickets and the agent doesn’t lose its place, so unattended actually means unattended.
• Trust. It tells you what it knew, what it didn’t, and why. People stop second-guessing it, which is the only way they ever start relying on it.
• Auditability. Every run is replayable, step by step. When someone asks “why did it say that” three weeks later, the answer is a file, not a guess.
• Throughput. Humans only see the tickets that genuinely need a human, each one arriving with the investigation already done.

The closing thought

The model is what makes the agent smart for a single step. Persistence is what makes it dependable across ten thousand of them. One of those you can buy off a leaderboard. The other you have to build, and it is mostly queues, logs, fallbacks, and the discipline to assume every dependency is having a bad day.

If your agent looks brilliant in the demo and brittle in production, the gap usually isn’t the model. It’s everything underneath that lets it keep going when something breaks, because in production, something always does.

That’s the part we build.

Want to talk about where your agent gets brittle between the demo and production? Get in touch at dvloper.io.

Razvan Georgescu, VP of Data & AI, dvloper.io

Your AI assistant works. That’s not the problem. The problem is that nobody is actually using it.

It passes the demo, the answers are solid, and stakeholders sign off. It looks like a success. Then it goes live, and usage quietly drops. People tried it, found it helpful enough, and then returned to their usual way of working. No complaints. No escalation. Just silence.

This is usually where most companies get it wrong. The issue is labeled as adoption. More training is proposed. Internal nudges are introduced, but none of it changes much. Because the issue isn’t adoption.

Using the assistant creates more work than it removes.

A user asks a question and gets an answer. Then they have to stop, read it, decide if they trust it, and manually apply it somewhere else: another system, another tool, another conversation. The AI helps, but only partially. The rest of the process is still on them.

Over time, that trade-off becomes obvious. Saving time on information retrieval doesn’t justify adding friction to everything that follows. So people adapt. They route around it. That decision exposes the real problem. 

The assistant isn’t failing. It’s simply not part of the workflow.

When your agent sits next to the process, it’s optional. It depends on someone choosing to use it and doing the extra step of translating its output into action. That extra step is exactly where things get stuck. It’s also where our system-building work begins. 

If your team isn’t using AI, it’s worth asking a simpler question: What happens after AI gives an answer? 

If the answer is “a person takes it from there,” you don’t have a system.

Most teams don’t know exactly where that break happens. That’s usually the first thing worth mapping. → Schedule a System Review

Key European Cybersecurity Events — January to March 2026

The first quarter of 2026 marked an intense period of engagement for our teams across Europe. Our people participated as speakers, presenters, and technical contributors in four major cybersecurity events — spanning Greece, Italy, and Romania — all tied to EU-funded projects in which we are active consortium partners. Here is a summary of what took place and how we contributed.

1. CYBERGUARD — 1st General Assembly Meeting

29 January 2026  |  Thessaloniki, Greece  |  International Hellenic University (IHU)

The CYBERGUARD Consortium launched its First General Assembly Meeting at Thessaloniki City Hall, hosted by the International Hellenic University (IHU). The event brought together over 40 participants and marked the first major project milestone since implementation began on 1 December 2024.

CYBERGUARD aims to strengthen Security Operations Centres (SOCs) through AI-driven technologies and an efficient Cyber Threat Intelligence (CTI) sharing framework, improving the resilience of SOCs against complex and evolving attack vectors. The meeting covered project objectives and guidelines, management progress, AI-driven cybersecurity system design, CTI and offensive strategies, threat detection achievements, and technical partner demonstrations. Partners also reviewed Pilot Use Cases in terms of usability, performance, and operational relevance.

Dr. Mihai PĂUN (I-ENERGYLINK), consortium coordinator, opened the meeting. Mrs. Malgorzata Agata KOWALSKA (ECCC Project Officer) joined remotely to address the consortium. The project is funded under the Digital Europe Programme and brings together 13 partners from Cyprus, Greece, Spain, and Romania.

Our contribution

DVLOPER was represented by Tudor Chihaia, Mihai Chihaia, and Răzvan Georgescu. The team delivered a live demonstration of the CYBERGUARD Dashboard to consortium partners, showcasing its current state and capabilities. They also conducted a technical demonstration of Suricata intrusion detection rules, explaining their structure and operational logic within the CYBERGUARD architecture.

2. INTERSOC — 2nd General Assembly Meeting

10 February 2026  |  Terni, Italy  |  Hosted by ASM TERNI

The INTERSOC (INTERconnected Security Operation Centres) project held its 2nd General Assembly in Terni, Italy. The project focuses on disruption preparedness and resilience of digital infrastructures through advanced threat forecasting, cyber-incident detection and response, and the development of a user-centric intelligent threat defence platform.

The agenda included work package progress updates, Final Review Planning, a visit to the ASM TERNI pilot site, and a dedicated workshop — "Overall INTERSOC Architecture, Main Solutions and Demos" — covering the technology stack, integration interfaces, dashboard, and SOC-targeted system architecture. A workshop on Pilot Testing and Evaluation also took place.

INTERSOC is coordinated by EXIMPROD ENGINEERING (RO), funded by the ECCC under the Cybersecurity and Trust Programme (Grant No. 101145853), and gathers 13 partners from Spain, Italy, Greece, Cyprus, and Romania.

Our contribution

DVLOPER was represented by Louis Sardarescu and Adrian Batanu. Louis presented the latest Dashboard updates to the consortium, walking partners through the current development status and upcoming features. Adrian participated in the technical working discussions around the SOC Connector, contributing alongside the other technical partners in the consortium to define integration approaches and next steps.

3. SECUR-EU — 2nd General Assembly Meeting

12 February 2026  |  Terni, Italy  |  Hosted by ASM TERNI

Two days later, also in Terni, the SECUR-EU Consortium held its 2nd General Assembly. The project — "Enhancing Security of European SMEs in Response to Cybersecurity Threats" — focuses on open-source security solutions for SMEs, white-hack testing via the HackOlympics initiative, and improving cybersecurity preparedness across the SME market.

The agenda covered work package progress, Final Review Planning, an architecture and demos workshop, and an open debate on SME training activities and stakeholder involvement — addressing capacity-building strategies and how to maximise the project's reach and sustainability. A Pilot Testing and Evaluation session was also held.

SECUR-EU is coordinated by EXIMPROD ENGINEERING (RO), funded under the ECCC Cybersecurity and Trust Programme (Grant No. 101128029), and gathers 14 consortium partners and 2 supporting organisations from across Europe.

Our contribution

DVLOPER was represented by Carol Bazga and Adrian Batanu, both actively engaged in the pilot use case discussions. Carol also delivered a dedicated presentation on the status of DVLOPER's pilot — the Distributed IDS System Deployed on the Edge for IoT Cyber Attack Detection — covering current implementation progress, technical findings, and next steps within the SECUR-EU validation framework.

4. CRA EUROPE 2026 — Cyber Resilience in Action

4 March 2026  |  Romanian Parliament, Bucharest  |  CYBERFORT Consortium, coordinated by I-ENERGYLINK

The flagship event of the quarter was the CRA EUROPE 2026 conference, held at the Romanian Parliament in the Hall Nicolae IORGA. The event was organised by the CYBERFORT Consortium and coordinated by I-ENERGYLINK, with the support of the Romanian National Cyber Security Directorate (DNSC). It drew over 200 participants and 35 speakers and moderators from across Europe.

The event focused on the practical implementation of the Cyber Resilience Act (CRA) and its implications for SMEs, public authorities, and critical sectors. Three thematic sessions addressed CRA compliance frameworks, the role of standardisation, European policy perspectives, CYBERFORT project outcomes, pilot use case showcases, and the path from compliance to capability. Key representatives from ENISA, DNSC, ELECTRICA, ASRO, Deloitte, and the Authority for the Digitalization of Romania (ADR) were among the contributors.

Dr. Mihai PĂUN (I-ENERGYLINK, CYBERFORT Coordinator) opened the conference, framing the event as a transition point: "CRA EUROPE 2026 is moving from Policy to Practice, from Compliance to Capability, and from Ambition to measurable Cyber Resilience."

Our contribution

Mihai Chihaia, CIO of DVLOPER, participated as a speaker in Session 2 — "Cybersecurity Projects, CRA Compliance & European Policy Perspectives" — as the Manufacturer/Vendor voice on the panel. His intervention addressed three interconnected themes:

• The standards gap as the primary compliance blocker — with Type C product-specific standards still pending publication and SBOM format not yet mandated, manufacturers face the risk of building compliance processes that require rework once final standards are issued.
• The underestimated complexity of SBOM — arguing that an SBOM is not a document but a living, automated process embedded in CI/CD pipelines, particularly challenging for products built on deep open-source dependency stacks (such as DVLOPER's MultiCloud platform, which integrates 30+ OSS tools).
• SME resource asymmetry as the harmonisation gap — large enterprises can absorb compliance costs, while SMEs building digital products cannot staff dedicated compliance teams. EU-funded projects like CYBERFORT and CYBERGUARD are essential complements to regulation.

In a solo intervention later in the session, Mihai also addressed how CRA compliance can become a competitive advantage — positioning it as a market access strategy rather than a cost centre, drawing on DVLOPER's experience serving US-based enterprise clients through Broadcom's partner network.

What Q1 2026 Meant for Us

Across four events in three countries, our teams contributed technically, strategically, and publicly to some of the most important conversations in European cybersecurity today. From SOC architecture and intrusion detection to CRA compliance and SME readiness, Q1 2026 has reinforced our position as an active and relevant voice in the ecosystem. We look forward to continuing this engagement in the months ahead.

In most enterprise deployments, the model is not the limiting factor. The failure appears at the system level, once the AI is exposed to real operational conditions.

In a controlled demo, inputs are predictable, context is bounded, and retrieval pipelines operate on clean, well-structured data. Latency is stable, and responses are evaluated in isolation. Under these conditions, the system performs as expected.

Production introduces a different set of constraints.

Queries are less structured and often underspecified. Input data is distributed across systems with inconsistent schemas and varying levels of reliability. Retrieval pipelines must handle partial failures, timeouts, and conflicting signals. Context windows become a constraint as the system attempts to combine multiple sources into a coherent response.

These are not edge cases. They are the baseline conditions of real usage.

The architecture decisions made during development become visible at this stage. How the system prioritizes sources when signals conflict. How it maintains state across multi-step workflows. How it degrades when a dependency is unavailable. How it handles concurrent requests without compounding latency or reducing accuracy.

Most implementations are not designed for this level of complexity. They are optimized for single-step interactions, not for sustained, multi-step reasoning under load.

The result is predictable. Accuracy degrades as query complexity increases. Latency becomes inconsistent. Failure modes are unclear or poorly handled. Trust declines, and usage shifts toward low-risk scenarios.

The model has not changed. The environment has.

The difference between a working prototype and a reliable system is the architecture that accounts for these conditions — before they surface in production.

Schedule an AI System Diagnostic

Or, if you want to understand how this is built in practice: See how the AI Factory works → https://dvloper.io/ai-factory

How we at dvloper.io build enterprise agentic AI that actually ships, and why the model isn't where your agent lives or dies.

Every enterprise AI program starts with the same enthusiasm and ends with the same question: “Why does the demo look so sharp and the production pilot look like a toddler with a search engine?”

We see this constantly. A team picks a model, wires it to a handful of tools, builds a nice chat UI, and ships something that crushes the happy-path scenarios the product owner demoed. Then it meets real enterprise data, real business rules, real ambiguity, and it collapses. Outputs drift. Trust erodes. The project quietly gets re-labeled as “exploratory” and everyone pretends the roadmap always had that caveat.

The thing nobody wants to say out loud is this: the LLM is not where your agent lives or dies. The model is a commodity. GPT, Claude, Gemini, Llama. Swap them, benchmark them, argue about them on Twitter. None of it will save an agentic system that doesn't understand your enterprise.

The layer that actually determines whether your agent survives contact with production is the one underneath the model. The one that tells it what your enterprise actually means.

That layer is an ontology. And building it properly is what we do at dvloper.io.

What a production-grade enterprise agent actually requires

When we talk about agentic AI at dvloper.io, we mean something very specific: a system that encodes the data, logic, actions, and security of the enterprise into a coherent semantic model, and then lets humans and agents operate on top of it with full fidelity. We call the capability we build for our clients the AI Agentic Factory, and it rests on four things, not one.

Strip away the buzzwords, and an enterprise-grade agent has to do four jobs simultaneously:

• Encode the data of the enterprise. Unify the vast and fragmented sources of truth: CRM, ERP, systems of record, ticketing platforms, document stores, operational telemetry, into coherent objects, properties, and links. Not a dashboard. Not an API gateway. A single semantic model the agent can actually reason over.
• Capture the logic of the enterprise. The rules, constraints, and decision frameworks currently living in someone's head, in a PDF from 2022, or worse, buried in fifteen different stored procedures nobody has touched since the person who wrote them left. Encoded once. Consistent everywhere.
• Model the actions of the enterprise as first-class primitives. Not just “the agent can generate an answer,” but “the agent can write back to the system of record, with the right approvals, the right audit trail, and the right rollback path.” Simple transactions and multi-step workflows, both governed the same way.
• Govern both humans and agents under one security model. Same identity, same permissions, same audit logs, whether the actor is a senior analyst or an autonomous agent. No CISO is going to sign off on “the LLM decided what was allowed.”

None of that is LLM work. All of it is semantic-layer work. And it is exactly what most agentic AI programs skip in the rush to ship a demo, which is exactly why most agentic AI programs stall between demo and production.

Why agents fail without a semantic layer

Let's be specific about what actually breaks when you skip the ontology.

1. The same term means five different things. A “customer” in CRM is not the same as a “customer” in billing, is not the same as a “customer” in the churn model, is not the same as the entity your contract says you owe money to. Your agent sees all five and averages them.

2. Business rules live in humans, not systems. The rule that “we never onboard vendors from jurisdiction X without a Tier-2 compliance review” exists in someone's head and in a PDF from 2022. Your agent has no idea.

3. The agent can't tell when it doesn't know. This is the failure mode that destroys enterprise trust faster than any other. An agent that confidently answers with incomplete information is worse than no agent at all, because you stop checking it.

4. Nothing is explainable. When the agent produces a decision, nobody can reconstruct why. No auditor will sign off on that. No compliance team will let it run unsupervised. No regulator will let it touch a regulated workflow.

5. Every new use case is a from-scratch rebuild. Without a shared semantic backbone, each agent is its own snowflake. Pilots never become platforms. Year two looks exactly like year one except with more sunk cost.

These are not model problems. No amount of swapping from GPT-4 to Claude to Gemini to Llama will fix them. They are architectural problems, and the architecture is the ontology.

How we actually build these systems

Here is the pattern we use at dvloper.io, and what makes the Agentic Factory approach different from “hook an LLM to LangChain and hope.”

1. Ontology-first, model-second

Before we pick the LLM, we model the domain. What are the entities? What are the relationships? What are the rules, constraints, and required properties? What does “done” look like for each workflow? What does every actor (human or agent) needs to know to make a safe decision?

This is boring, unglamorous, diagram-heavy work. It is also exactly what separates the systems that ship from the ones that don't.

2. The agent's job is semantic translation, not answer generation

Once the ontology exists, the LLM's job gets narrower than people expect. It is not “generate the answer.” It is: take the user's request, map it to ontology concepts, identify what is being asked, and route to the right tools.

That is a much more tractable problem for an LLM. It is also much easier to make reliable, testable, and debuggable. Most of what people call “hallucination” in production agents is actually the LLM being asked to do a job the architecture should have handled for it.

3. Tools are first-class citizens, and they are boring on purpose

We build tools as small, deterministic, testable pieces of code that the agent composes into workflows. Boring tools are good tools. They fail predictably. They log cleanly. They don't hallucinate.

The tools that show up in every ontology-driven agent we build:

• The Gap Capture tool. Identifies what is missing before the agent acts. If an onboarding request does not have a jurisdiction, the agent does not guess. It records the gap.
• The Question Generation tool. Turns gaps into targeted follow-up questions, grounded in the ontology rather than generic “can you clarify?” prompts. “Is this vendor operating in a restricted jurisdiction?” beats “Tell me more about the vendor” every time.
• The Assumption Logging tool. When a workflow has to proceed with a temporary assumption, the agent records it explicitly. Every decision becomes auditable. Every assumption becomes a conversation the team can later have.
• The Validation tool. Checks that requests and resolved entities satisfy ontology constraints before any action is taken. Every contract must be linked to a legal entity. Every change request must have a rollback path. Every product must have a capability owner. The ontology says so; the validator enforces it.
• The Reasoning tool. Applies rules over ontology relationships to derive facts the input didn't explicitly contain: eligibility, risk tier, dependency chains, blast radius. This is where ontology stops being a dictionary and starts being an inference engine.
• The Escalation tool. When the agent can't safely complete a task, it routes to a human with full context (gaps, assumptions, partial work, recommended next actions), not a generic ticket with “agent failed, please investigate.”

These are the tools that make the difference between an agent that answers fast and an agent you would actually put in front of a regulator.

4. Observability on top, governance on the side

Every agent call, every tool invocation, every assumption, every escalation, all logged, queryable, auditable. This is not bolted on at the end. It is part of the architecture from day one. When an agent makes a decision six months from now, you can reconstruct exactly why.

5. The platform compounds

This is where the “Factory” in Agentic Factory matters. The first agent we build comes with a semantic model, a tool library, and observability plumbing. The second agent reuses all of it. By the third or fourth use case, the incremental cost of a new agent is a fraction of the first one.

That is when agentic AI stops being a project and starts being a capability.

A real example: agent-driven network operations

Some of our most demanding work lives in network operations: proactive monitoring, configuration validation, incident triage. Real-time, high-stakes, zero-tolerance-for-wrong-answers territory. An agent that confidently pushes a bad change into a production network does not produce a bug. It produces an outage with a name.

What does ontology look like here?

• Entities: devices, interfaces, links, policies, tenants, service paths, SLAs, maintenance windows.
• Relationships: which device serves which tenant, which policy applies to which interface, which link is primary versus backup, which tenant shares which blast radius.
• Rules: what constitutes a valid configuration change, what requires tenant approval, what can be auto-remediated, what must never be touched outside a maintenance window.

A traditional agent asked “Can we push this configuration change?” might confidently answer yes based on syntactic validation alone. That is dangerous.

An ontology-driven agent answers a different question entirely: given the ontology of this network, is this change safe, for which tenants, with what downstream effects, and what assumptions is it making?

It might conclude:

Change validation: Blocked.

Gaps detected:

• Affected tenant SLA window not confirmed

• Rollback path for interface bundle not verified

• Peer link redundancy currently degraded

Questions requiring human input:

• Is this change scheduled inside the tenant's approved maintenance window?

• Has the peer-side team acknowledged the redundant-link status?

Assumptions logged:

• Tenant SLA tier inferred from most recent service catalog snapshot

• Rollback path assumed to be the previously-deployed configuration baseline

Recommended next actions:

• Route to on-call network engineer with full context

• Hold change until peer-side redundancy restored

That is not a chatbot. That is a co-worker with enough context to be trustworthy, and enough self-awareness to escalate when it shouldn't proceed alone.

The business case, said plainly

The reason this architecture is worth the upfront work is not theoretical. It shows up in five places:

Trust. The agent shows what it knows, what it doesn't know, and why. Users stop second-guessing outputs, which means they actually start using them.

Explainability. Every decision is grounded in ontology, rules, and traceable gaps. Regulators, auditors, and internal risk teams can follow the reasoning end-to-end.

Reusability. The ontology becomes a shared asset across every agent and workflow you build. Second use case costs a fraction of the first.

Governance. Assumptions, questions, unresolved issues, and escalations are explicitly captured, not hidden inside model weights you cannot inspect.

Scalability. Different domain agents share the same semantic backbone. Your platform grows as a coherent system instead of a collection of disconnected pilots.

These are not theoretical benefits. They are the reason enterprises that adopt this pattern end up with agentic AI running in production, and the ones that don't end up with a graveyard of demos.

The closing thought

LLMs are excellent at generating language. Enterprise decisions require structure, meaning, constraints, and the discipline to recognize when an answer is incomplete. One of those things is a commodity in 2026. The other is the work.

At dvloper.io, the work is what we sell. The ontology-driven agent is not a demo pattern for us. It is how we ship.

If you are stuck somewhere between a promising POC and a production agent you'd actually trust with a regulated workflow, the missing layer is probably not a better model. It is the ontology underneath.

We would be happy to talk about yours.

Want to discuss where your agentic AI program is stuck, or how an ontology-first architecture would fit your stack? Get in touch at dvloper.io.

Razvan Georgescu, VP of Data & AI, dvloper.io

At some point, every team stops being able to remember everything it has already learned. The knowledge is there sitting in ten thousand Jira tickets, buried in comment threads, resolution summaries, and carefully-written post-mortems of incidents from years ago. All of it is searchable, technically. None of it is findable in the way a human actually asks questions.

New team members spend their first weeks asking questions that have been answered a dozen times before. Senior engineers get pulled off their own work to explain history they’ve already explained, which isn’t just a productivity tax it’s one of the quieter reasons people burn out. Incidents drag on longer than they should because nobody can remember whether this exact symptom has happened before, or whether a similar issue in a different service was already root-caused and resolved.

The organization owns the answers. It just can’t access them at the speed of conversation. That gap between “we know this” and “we can retrieve this” is worth closing. That’s the problem JiraAI was built to solve at dvloper.io.

Why we built our own product layer

Before we wrote a line of code, we spent serious time evaluating RagFlow, the open-source RAG engine that has become one of the most capable platforms in its category. It’s genuinely impressive: deep document parsing, intelligent chunking, multi-modal retrieval, grounded citations, agent workflows, and native Jira support since v0.22.0. For many teams, it’s an excellent starting point. Three concerns ruled out a direct deployment for us.

Access control you can prove

Engineering managers and security leads don’t just want “a chatbot over Jira.” They want to prove that a contractor on Project A has no path through the UI, through the API, or by guessing identifiers to data from Project B. RagFlow’s open-source edition is designed around workspaces, not per-user per-knowledge-base grants. The maintainers confirmed this when they closed the RBAC request in May 2025: granular permission control is a commercial-tier feature. For our use case, this wasn’t a limitation we could work around it was the core of what we needed to deliver.

Roadmap autonomy

Building entirely on a third-party platform means your product’s future is tied to their release schedule and licensing decisions. Owning the application layer while leaning on RagFlow as the retrieval engine underneath meant we could ship the features our teams actually asked for, on our timeline, without waiting for an external roadmap to catch up.

Technology vs. product

A RAG engine does one thing extraordinarily well: retrieve. A knowledge product is the onboarding flow that makes a junior engineer feel supported, the audit trail that satisfies a security review, the dashboard that justifies the budget. None of that ships inside a retrieval engine by default. JiraAI is the product. RagFlow is the engine. Keeping those two things separate, and letting each do what it’s best at, is the most important architectural decision we’ve made on this project.

What JiraAI delivers

1. Real RBAC tied to your existing identity

JiraAI integrates directly with Keycloak (or any OIDC-compliant IdP). Access is enforced at three independent levels: site-wide roles (site.admin, project.admin, project.user), per-user knowledge base grants for contractors and cross-functional contributors, and project-to-knowledge-base mappings that make tenancy clean and auditable. One Keycloak change grants access; one change removes it entirely. MFA, session policies, and password rotation are all inherited JiraAI can’t accidentally weaken them. For a security review, this is the difference between a two-week conversation and a two-day one.

2. An admin dashboard for decision-makers

Every early demo ended with leadership asking the same three questions: Is anyone actually using this? Are the answers good? What are we getting for what we’re spending? The /admin view answers all three adoption by team and project trended over time, per-response helpfulness signals captured directly in chat, and LLM usage tied to specific tickets and projects. It’s a product owner’s view of whether the thing is working, not a RAG operator’s view of embedding health and vector metrics.

3. Jira data understood before it’s indexed

Raw Jira tickets are noisy: triage summaries written before the problem was understood, low-signal comments (“bump,” “retry,” “any update?”), attachments in mixed formats, and resolutions buried in the last reply of a long thread. Feed that directly into a knowledge base and you get answers that reflect the noise.

JiraAI’s ingestion pipeline runs every ticket through an AI enrichment step before it reaches the knowledge base restructuring it into what the problem was, what was tried, what was ruled out, and what finally worked. Atlassian Document Format comments are parsed correctly. A single ticket can fan out to multiple knowledge bases without duplicating the enrichment work. The result is cleaner retrieval and more accurate, more specific answers.

4. Project-centric UX and a resilient pipeline

Instead of navigating a list of opaque knowledge base identifiers, users start from a project, intuitive and familiar organizing unit they already work in every day. The assistant, access controls, and analytics all follow automatically. Behind the scenes, a decoupled producer/consumer pipeline handles incremental Jira polling, enrichment, and fan-out independently. If the downstream is temporarily unavailable, the producer keeps collecting and the consumer catches up. Single-ticket failures don’t affect the batch. Idempotency is enforced at the database level. Reliability isn’t a feature you market it’s the absence of the outages you didn’t have.

How a question becomes an answer

An engineer hits a familiar-looking Kafka consumer timeout and types: “Have we seen this lag spike before, and what was the fix?” JiraAI authenticates them via Keycloak, resolves their project memberships, and queries only the knowledge bases they’re allowed to see the access boundary is enforced at the retrieval step, not just at the UI. Enriched ticket chunks are retrieved, re-ranked, and passed to the LLM with a carefully designed system prompt. The answer streams back with citations to specific tickets.

The engineer clicks through to an eleven-month-old ticket and finds the root cause in three minutes. They mark the response helpful that signal feeds the admin dashboard, where a product owner can see which teams are getting value and which knowledge bases have gaps. Nobody thought about knowledge base IDs, RAG configuration, or which model is powering the response. It just worked, and it was safe, and it was measurable.

The lesson

Retrieval engines don’t ship with the parts that make them products. Access control, audit trails, domain-specific data handling, a UX that fits how engineers think about their work none of that comes in the box, regardless of how good the underlying engine is. A thin interface on top of RagFlow would have passed the demo. It would not have passed the security review.

So we built those parts ourselves and layered them on top of RagFlow’s retrieval quality, which we trust and don’t have to maintain. The hard foundational work is someone else’s problem. The product experience the part our teams open every morning is entirely ours to shape and iterate on.

Further reading

–  RAGFlow on GitHub

–  RAGFlow v0.22.0 data sources, admin UI, parser improvements

Dvloper is entering Phase 3 of a strategic AI collaboration with a Fortune 10 infrastructure leader, evolving an enterprise assistant into a more advanced agentic system designed to reason across complex internal knowledge and support real operational workflows in production environments.

Enterprise AI rarely fails during training. It fails in production.

That reality has shaped our collaboration with a Fortune 10 infrastructure leader, where the goal was never to build another impressive assistant, but a system capable of navigating complex internal knowledge and supporting real operational workflows.

After successfully delivering Phase 1 and Phase 2, we are now entering Phase 3 - the biggest stage of the partnership so far.

From Early Validation To Deeper Operational Value

The earlier phases of this collaboration were centered on building the right foundation: understanding the problem space, shaping the assistant architecture, integrating knowledge sources, and validating how AI could be applied in a way that was actually useful inside a real enterprise environment.

That part matters more than people think.

In enterprise settings, AI is not valuable just because it can answer questions. It becomes valuable when it can work within complex systems, reason through fragmented information, and produce outputs that are relevant, reliable, and aligned with how teams actually operate.

That is exactly where this collaboration has been heading.

With the first two phases successfully completed, with great feedback from the stakeholders of going beyond the initial scope - the project is now moving post foundational capability and into a more advanced stage focused on broader reasoning, stronger orchestration, and deeper operational fit.

What Phase 3 Is About

This next stage focuses on expanding the agentic capabilities of the platform so that it can do more than respond, it becomes a proactive agentic framework instead of a reactive agentic mechanism. It needs to reason across enterprise context, coordinate specialized workflows, and support more structured decision paths in environments where accuracy and traceability matter.

At a high level, this phase builds on the progress already made in areas such as:

• Agent orchestration for more structured task handling
• Context aware reasoning across multiple internal knowledge sources
• Improved routing between specialized flows and capabilities
• Stronger support for complex operational investigations
• A more production minded approach to integration, validation, and rollout

The goal is not to build AI for the sake of AI.

The goal is to build a system that can genuinely support teams operating in complex technical environments, where the volume of information is high, the paths to resolution are rarely linear, and trust in the output matters just as much as speed.

Why This Work Matters

A lot of AI content today focuses on generic assistants and surface level automation. But enterprise reality is different.

Real internal systems are layered. Knowledge is distributed. Processes evolve over time. And the people using these tools are not looking for novelty; they are looking for practical value in their day to day workflows.

That is why this collaboration has been shaped around a more grounded engineering approach.

Instead of treating the assistant like a standalone chatbot, the system has been designed as a more structured, agent driven capability: one that can connect to enterprise knowledge, follow defined reasoning paths, and support users in a way that feels closer to an operational companion than a generic interface.

That distinction is important, especially in larger organizations where adoption depends on whether the solution can fit into real workflows, not just perform well in a controlled demo.

In most large organizations, operational teams deal with high volumes of structured and unstructured information coming from multiple systems that were never designed to talk to each other. The people doing the work are experienced - they know how to navigate the complexity - but they spend a disproportionate amount of time on the repetitive cognitive work: gathering context, cross-referencing sources, triaging what matters from what doesn't. That is not an automation problem. It is a reasoning problem. And that is where agentic AI actually starts to make sense - not as a replacement for expertise, but as a layer that handles the heavy lifting before a decision needs to be made.

What Makes This Phase Different

What makes Phase 3 significant is not only the scale of the work, but the level of maturity behind it.

By this point, the collaboration is no longer about testing whether the idea has potential. That has already been demonstrated through the earlier phases. Phase 3 is about extending that success into a larger, more capable system with stronger real world value.

For our team, this is also the kind of work we care deeply about: combining modern AI frameworks with disciplined engineering, thoughtful architecture, and a strong understanding of how enterprise systems actually behave.

It is one thing to prototype an assistant.

It is another to design one that can evolve responsibly inside a large operational environment.

That is the challenge and the opportunity in front of us now.

Looking Ahead

We are excited to begin Phase 3 and continue building on the trust, momentum, and technical foundation established so far.

This next chapter represents more than just another milestone. It reflects the strength of a partnership built through delivery, iteration, and a shared commitment to building AI systems that are useful, reliable, and grounded in real operational needs.

For Dvloper, it is also a strong example of how we approach enterprise AI, not as a trend, but as an engineering discipline.

The companies that will lead with AI are not the ones moving fastest. They are the ones building systems that their teams actually trust.

My time at the dvloper.io academy was a transformative experience designed to bridge the gap between basic programming knowledge and enterprise-level software development. The primary objective of the program was to familiarize students with real-world applications, full-stack development, and professional workflows, all within a structured Agile methodology emphasizing continuous delivery and iterative improvement.

The curriculum followed two-week sprints, with tasks building on each other and increasing in complexity. Agile practices guided the process: sprint planning to set goals, bi-weekly meetings to stay aligned, code reviews for quality, and retrospectives to reflect and improve. Mentorship was a key part of the academy experience. 

The first month at dvloper.io focused on laying a stable foundation for enterprise-level development. I began by setting up Virtual Machines, installing development tools, and configuring all dependencies required to run complex applications. Understanding the infrastructure behind these systems was equally important, I learned how enterprise applications rely on interconnected services and environments to function reliably. Alongside this, I worked on designing application workflows, planning scalable structures, and mapping how different components would interact. This phase was critical for building core technical skills, developing a structured approach to problem-solving, and learning how to manage tasks efficiently through the two-week sprint structure.

With the technical foundation in place, I moved on to backend development and enterprise data workflows. I focused on writing robust backend logic capable of handling complex business processes and designing REST APIs to facilitate smooth communication across application layers. Integrating these backend components into a cohesive system taught me to think in terms of system architecture and data flow management, reinforcing how enterprise applications are designed for scalability, reliability, and maintainability. By the end of this month, I felt confident tackling enterprise-level backend challenges and understood how backend services support the overall functionality of large-scale applications.

The third month emphasized full-stack development and integration. I shifted my focus to building interactive, responsive frontends and connecting them to the backend APIs I had developed. Testing and refining the end-to-end workflows gave me a clear view of how all components of an application come together to create a seamless user experience. This stage reinforced my understanding of full-stack development and highlighted the importance of integration and user-focused design in enterprise applications. By seeing how each part of the system interacts, I gained hands-on experience in managing complexity in a way that mirrors real-world professional environments.

The final month introduced enterprise DevOps practices, ensuring the applications we built could be deployed and maintained reliably. I learned how to package applications with containerization for consistent environments, deploy and manage them at scale using Kubernetes, and automate testing and deployment through CI/CD pipelines. This phase enhanced my skills in automation, deployment, and scalable system management , all essential for enterprise software development. It also demonstrated how modern development workflows rely on collaboration between developers, operations, and continuous delivery systems to maintain reliability in production environments.

Takeaways

The program provided an invaluable start to my career, equipping me with both the technical expertise and professional skills required in real-world software development. I am now confident to approach other challenges, and continuously improve in a professional environment.