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. 

At dvloper.io, we believe that code quality is not just a nice-to-have. It is the foundation of sustainable software development. As our portfolio grew to include complex platforms like JIRA AI, NationalHR, and Backstage.io, we faced a common challenge: how do we maintain consistent code quality standards across diverse teams and technologies?

SonarQube became our answer, a powerful static code analysis platform that has transformed how we approach quality assurance. In this article, I will share our journey of implementing SonarQube across multiple projects and the lessons we have learned along the way.

The Challenge: Scaling Quality in Microservices

Our flagship project, JIRA AI, is a multi-module Spring Boot microservices application comprising several interconnected services: a core REST API backend, Kafka message producers and consumers, shared utility libraries, and a React frontend. Each module has its own complexity, dependencies, and potential for technical debt.

Similarly, our work on NationalHR and our contributions to Backstage.io required a unified approach to quality that could scale with our ambitions. We needed a solution that would provide consistent standards without stifling the unique requirements of each project.

Our Configuration Strategy

The key to our successful SonarQube implementation lies in a multi-layered configuration hierarchy. At the root of each project, we define core properties: unified project identification, quality gate integration that ensures pipeline failures on violations, and secure environment-based token management. This centralized approach guarantees that all modules inherit the same baseline standards.

Each service module then maintains its own configuration for granular control, including targeted source and test directory mapping, Java version alignment per module requirements, intelligent exclusions for generated code and configuration files, and seamless JaCoCo test coverage integration. We maintain a minimum 80% test coverage threshold across all projects, which has significantly reduced our production bug rate.

CI/CD Pipeline Integration

For JIRA AI, NationalHR, and our other projects, we have implemented sophisticated three-stage GitLab CI pipelines covering build, SonarQube analysis, and deployment. Our configuration features intelligent caching for Maven dependencies and SonarQube results, full Git history access for accurate blame information, and branch-specific analysis with different rules for protected versus feature branches.

A crucial design decision was setting our SonarQube analysis to non-blocking mode. Quality issues are surfaced and tracked without preventing deployments, empowering teams to make informed decisions while maintaining delivery velocity.

The Benefits We Have Realized

Automated Quality Gates: Our quality gates prevent technical debt accumulation by catching issues early. Across all projects, we have seen a measurable reduction in production incidents and maintain code duplication below 3%.

Enhanced Security: SonarQube's vulnerability scanning helps us identify and remediate security issues before production. The OWASP compliance features provide actionable guidance for our security-conscious development practices.

Developer Productivity: With IDE integration and real-time feedback during development, our teams catch issues before they even commit code. Pull request analysis provides automated quality feedback, significantly reducing code review burden.

Lessons Learned

Strategic Exclusions Matter: Do not analyze everything. Exclude generated code, configuration files, and model/DTO classes from duplication detection. This focuses your quality metrics on code that actually matters.

Start with Reasonable Thresholds: We began with achievable quality gate thresholds and gradually tightened them as our codebase improved. This prevented team frustration while still driving continuous improvement.

Leverage Caching: Our caching strategy for both Maven dependencies and SonarQube analysis results significantly reduced pipeline execution times, which is essential for maintaining fast feedback loops.

Conclusion

Implementing SonarQube across JIRA AI, NationalHR, Backstage.io, and our other projects at dvloper.io has been transformative. By combining automated analysis, comprehensive coverage reporting, and seamless CI/CD integration, we have established a culture of quality that scales with our growth.

The multi-module configuration approach provides both unified oversight and granular control, which is essential for enterprise-grade applications. If you are looking to elevate your code quality practices, I encourage you to explore SonarQube. The investment in setup pays dividends in reduced bugs, improved security, and happier developers.

Have questions about our SonarQube implementation? Reach out to us at dvloper.io. We are always happy to share our experiences with the developer community.

About the Author: Bilciurescu Gabriel is a software engineer at dvloper.io, where he focuses on building scalable microservices architectures and implementing DevOps best practices.

The ESTEEC Olympics Hackathon has officially concluded, and the results were nothing short of impressive.

While the energy of a hackathon is often about the "game", this event was rooted in a much larger mission. It served as a promotional platform for the Cyberguard project—a major European initiative where our team holds key development responsibilities.

The Cyberguard Connection

Cyberguard (funded by the European Commission’s Digital Europe Programme) is dedicated to "Fortifying SOCs Against Evolving Cyber Threats." Our day-to-day work in this project involves developing advanced AI-driven technologies to protect critical infrastructure—spanning energy, finance, and healthcare—from sophisticated attacks.

We wanted this hackathon to mirror that level of technical rigor. The goal wasn't just to "spread awareness", but to showcase the intense engineering reality of modern cybersecurity. We challenged participants to step into the shoes of the developers building the next generation of Security Operation Centers (SOCs).

The Challenge: AI/ML SIEM for POS Fraud

We tasked the teams with a highly specific, real-world problem: Building a custom SIEM (Security Information and Event Management) system for Point of Sale (POS) fraud detection.

Participants had to ingest a continuous, high-velocity data stream, analyze it for anomalies, and visualize threats in real-time.

Engineering Under Pressure

To simulate the critical nature of the systems we build at Cyberguard, we introduced strict constraints:

• 30-second live checker: Security is time-sensitive. Once an event hit the stream, teams had exactly 30 seconds to detect the fraud and report it. This forced them to prioritize low-latency architecture over sluggish, heavy processing.
• Real Logic vs. Wrappers: We explicitly banned the "lazy" use of LLMs (simply sending data to a prompt). We demanded genuine algorithmic creativity, hybrid models and custom heuristics that demonstrated true engineering expertise.

From data to decisions

On top of the AI models creation, the hackathon teams delivered on this front with robust dashboards that answered critical business questions instantly:

• What are the top 5 active fraud patterns?
• Which age demographics are being targeted right now?
• How does the current alert volume compare to previous hours?

Summary

This event was a successful extension of our work with Cyberguard. By bringing the complexity of critical infrastructure defense to a hackathon format, we didn't just promote the project—we highlighted the vital importance of integrating AI and machine learning into the fabric of our digital security.

Congratulations to the winners, and thank you for helping us demonstrate what it takes to truly guard the grid.

We’re proud to share that several members of our team won the NASA Space Apps Challenge 2025,  the world’s largest global hackathon for innovation using NASA data.

Their project, AiRo, stood out for its bold approach to one of the most pressing issues of our time: air quality management.

What AiRo Does

AiRo automates industrial air quality management by combining NASA TEMPO satellite data with AI-powered infrastructure analysis.

Traditionally, companies rely on manual environmental consulting - a process that can cost over €57,000 per year. AiRo replaces this with automated, real-time monitoring and reporting for about €10,800 annually, helping organizations save around €47,000 per year while improving environmental compliance and community safety.

The Challenge It Solves

According to the World Health Organization, 99% of people worldwide breathe polluted air. Many organizations still operate reactively - responding to pollution exceedances only after they happen.

AiRo changes that. It shifts industrial facilities from reactive compliance to proactive prevention by continuously analyzing air quality, infrastructure context, and risk factors around industrial sites.

When air pollution levels exceed thresholds, AiRo doesn’t just send alerts - it can call managers directly through AI-powered voice notifications to ensure immediate action.

How It Works

1. Infrastructure Analysis – Uses OpenStreetMap and OpenAI Vision to understand the facility’s surroundings: roads, schools, hospitals, and building density.
2. Environmental Data Integration – Combines NASA TEMPO satellite data (NO₂, HCHO, O₃, AQI) with local measurements and weather data.
3. Contextual Risk Assessment – Models how pollutants move and affect surrounding communities.
4. AI Mitigation Planning – Multi-agent AI systems recommend short-, medium-, and long-term actions with cost-benefit analyses.
5. Automated Reporting – Generates both detailed Markdown reports and executive PowerPoint presentations.
6. Proactive Alerts – Delivers dashboard notifications and AI-initiated phone calls when pollution thresholds are exceeded.

The Impact

For organizations, AiRo means: – Lower compliance costs and fewer consultant hours – Prevention of violations, fines, and permit delays – Access to data that supports grant and tax credit applications

For communities, it means: – Cleaner air – Reduced health risks – Transparent, accessible air quality information

AiRo demonstrates how AI, automation, and NASA open data can come together to protect both the environment and the economy.

Built by the Team at dvloper.io

The project reflects our team’s engineering philosophy: solve real problems with clarity and precision.

AiRo’s technical stack includes React, FastAPI, Kubernetes (K3s), Longhorn distributed storage, and Keycloak SSO, running on Hetzner servers for scalability and performance. Its AI agents leverage OpenAI GPT-5, OpenAI Vision, and Retell AI for data analysis, visual interpretation, and natural-language phone alerts — proving that AI can be both intelligent and actionable.

Why This Matters

Winning NASA Space Apps isn’t just about recognition. It’s about validation that deep tech can create measurable environmental and social impact.

AiRo helps industries become cleaner, smarter, and more responsible and we’re proud of our people who were behind it!

Explore the Project

🌍 NASA: Project Presentation

 📄 Project Report: View Presentation

 💻 GitLab Repository: AiRo on GitLab

At dvloper.io, we believe great systems are never built in isolation.They’re built by teams who see complexity as an invitation to innovate.

Congratulations, Bilciurescu Gabriel-Cosmin, Burea Mihai-Ovidiu, Mitran Andrei-Gabriel, Bazga Mihai-Carol, Pasaroiu Mihai! You did it!

Clarity. Collaboration. Code that matters.

In today's fast-paced IT operations and development environment, teams are drowning in tickets, runbooks, and scattered knowledge across JIRA, and countless documentation repositories. What if you could transform your entire incident history, knowledge articles, and runbooks into a single, secure AI brain – in less than a day?

Meet the AI Ticket Support Assistant by Dvloper.io – a revolutionary solution that super-charges your ticket systems with enterprise-grade AI, turning decades of tribal knowledge into instant, actionable intelligence.

The Opportunity: Your Ticket History is a Gold Mine

Every organization sits on a treasure trove of knowledge:

• Years of Incident Resolution: Thousands of tickets with solutions that worked
• Expert Runbooks: Procedures and workflows refined through experience
• Knowledge Articles: Documentation created but rarely discovered when needed
• Tribal Knowledge: Critical insights locked in resolved tickets and comments
• Repetitive Patterns: The same issues being solved over and over by different teams

Traditional ticket systems treat incidents as isolated events. But what if JIRA, and your other ticket systems could learn from every resolution, every runbook, and every knowledge article to become an intelligent support brain?

The AI Ticket Support Assistant transforms your entire incident history into actionable intelligence – automatically, continuously, and securely.

What Makes This Different: Enterprise AI Done Right

The AI Ticket Support Assistant isn't just another chatbot slapped onto your ticket system. It's a purpose-built, enterprise-grade platform with capabilities that set it apart:

Specialized ETL for Ticket Systems

No more hand-rolled scripts or custom integrations. Our pre-built connectors automatically ingest:

• JIRA: All major deployment types with comprehensive issue tracking
• Multiple Systems: Flexible integration with various ticket platforms

Configure once, and data flows automatically through scheduled syncs or real-time webhooks. Deploy in less than a day.

HybridRAG + GraphRAG Retrieval

This is where the magic happens. Our advanced retrieval system goes far beyond basic semantic search:

• Semantic Understanding: Comprehends the meaning and context of queries, not just keywords
• Relational Intelligence: Discovers connections between tickets, runbooks, and knowledge articles
• Superior Accuracy: Retrieves the most relevant solutions by combining multiple AI techniques

Result? Your team gets the right answer the first time, dramatically reducing resolution time.

LLM-Agnostic Architecture: Your Choice, Your Control

Unlike solutions that lock you into a single AI provider, we support multiple deployment options:

Cloud Options:

• OpenAI (GPT-4, GPT-4 Turbo)
• Microsoft Copilot
• Azure OpenAI Service

On-Premises Options:

• Open-weight models (Llama, Mistral, and more)
• Complete air-gapped deployment
• Zero data leaving your network

Switch anytime. Control costs. Meet data residency requirements. No vendor lock-in. Ever.

Truly Enterprise-Ready Security

Built from the ground up for enterprise security requirements

Any Deployment Model: Your Infrastructure, Your Rules

Every organization has unique security, compliance, and infrastructure requirements. That's why we support any deployment model:

Cloud Deployment

Azure Deployment

On-Premises Deployment

Hybrid Deployment

Choose what works today. Change tomorrow if needs evolve. No penalties. No migration headaches.

The User Experience: Simple Yet Powerful

One dashboard. Complete visibility. Total control.

System Requirements: Flexible & Accessible

The AI Ticket Support Assistant is designed to work with your existing infrastructure:

Ticket System Compatibility

JIRA - All major deployments (Cloud, Data Center, Server)
Multiple Systems - Integrate various ticket platforms simultaneously

LLM Requirements (Choose Your Path)

Cloud Option:

• OpenAI subscription (GPT-4, GPT-4 Turbo)
• Microsoft Copilot subscription
• Minimal infrastructure requirements

Azure Option:

• Azure subscription with Azure OpenAI Service
• Existing Azure infrastructure utilized
• All processing within Azure tenant

On-Premises Option:

• Hardware suitable for hosting local LLMs
• Air-gapped deployment capability
• Complete data sovereignty

Security & Authentication

Enterprise-grade security requirements supported
Keycloak integration for identity management
Compatible with existing SSO and RBAC systems
Compliance-ready for regulated industries

Perfect For These Use Cases

IT Operations & ServiceNow Teams

Transform your incident management process. Instead of escalating tickets to senior engineers, Level 1 and Level 2 support can query the AI system to find similar past incidents and their exact resolutions. Reduce escalations by 60%while improving MTTR (Mean Time To Resolution).

Software Development Teams

Stop reinventing the wheel. When developers hit a bug or technical challenge, they can instantly access solutions from similar issues across all projects. Cut research time by 75% and accelerate feature delivery.

DevOps & Infrastructure

Build an always-available expert system for operational procedures, troubleshooting guides, and infrastructure decisions. New ops team members can understand complex system architecture and common failure patterns in days instead of months.

Customer Support

Enable support teams to provide faster, more accurate responses by leveraging the collective knowledge of your IT operations and development teams. First-call resolution rates increase by 40%.

Compliance & Audit Teams

Maintain complete audit trails and ensure consistent responses to security incidents and compliance queries. Every AI interaction is logged and traceable.

Ready to Transform Your Team's Productivity?

The JIRA AI Producer-Consumer System represents the next evolution in project management – where artificial intelligence doesn't replace human expertise but amplifies it. Your team's collective knowledge becomes a powerful, searchable, and intelligent resource that grows stronger with every project.

Stop letting valuable knowledge get lost in ticket graveyards. Start building your intelligent project ecosystem today.

Key Takeaways

Transform existing JIRA data into intelligent, searchable knowledge
Reduce research time by 75% with natural language queries
Accelerate onboarding with AI-guided project exploration
Preserve tribal knowledge across team transitions
Enterprise-ready security with role-based access control
Measurable ROI through improved productivity and reduced costs

While testing Skyvern with different integrations, our teammate Serena ran into some unexpected authentication issues when connecting it to Bitwarden. She not only solved the problem, but also improved Skyvern so others won’t face the same roadblocks. Here’s what she had to say.

The Problem: Vague Authentication Errors

I kept getting authentication failures with no useful explanation. The output was short and gave no direction. After asking on the Skyvern Discord, I learned this was common. Bitwarden's CLI often produces vague errors that are hard to troubleshoot.

I eventually found the cause and fixed it. But the experience made me think about how Skyvern could make this easier for others.

The Idea: More Helpful Error Messages in Skyvern

The main issue was the lack of guidance. I added an optional extra field in error messages. This field can include:

• Hints that point to a possible solution
• Extra context relevant to the specific error condition

The system is general and can be expanded to include more conditions and hints over time.

The First Use Case

The first condition detects the exact Bitwarden CLI issue I faced. When triggered, it outputs the same fix that worked for me.

Why This Matters

• Reduces guesswork by giving practical guidance
• Helps new users troubleshoot faster without needing deep system knowledge
• Allows easy addition of new error-hint pairs in the future

Closing Thoughts

Debugging is part of development, but vague errors slow everyone down. By adding small, targeted hints to error messages, we make the system easier to work with and reduce repeated troubleshooting. This improvement should help anyone integrating Skyvern with Bitwarden.