Andreea Pleşea, PhD, COO and Co-Founder of Druid AI – Interview Series

Andreea Pleşea, PhD, COO and Co-Founder of Druid AI, is a technology executive and entrepreneur with nearly two decades of experience spanning software engineering, enterprise technology, artificial intelligence, operations, and customer success. Since co-founding Druid AI, she has held several senior leadership roles across the organization, including Chief Operating Officer, Chief Revenue Officer, and Chief Customer Success Officer, giving her experience across both the technical and commercial sides of scaling an enterprise software company. Before Druid AI, Pleşea spent nearly a decade at TotalSoft, progressing from .NET programmer to Software Development Manager and ultimately Charisma Business Applications Director, where she oversaw product development, implementation, technical support, solution architecture, and P&L responsibilities. Her academic background also includes AI research at the University of Rome Tor Vergata, where she worked with the university’s Artificial Intelligence Research Group on technology for extracting and structuring information from unstructured data. She also serves on the Board of Advisors for Women in Tech Romania.

Druid AI is an enterprise AI company focused on building and orchestrating AI agents that can automate complex business processes across organizations. Its platform combines natural language understanding, generative AI, retrieval-augmented generation (RAG), enterprise integrations, workflow automation, analytics, and governance, with Druid Conductor coordinating multiple specialized agents and systems toward business outcomes. Organizations can connect Druid’s agents to systems such as enterprise resource planning (ERP), customer relationship management (CRM), IT service management (ITSM), and human resources platforms, while deploying the technology in cloud, hybrid, on-premises, or air-gapped environments. The company says its technology is used by more than 300 enterprise customers and supported by over 200 global partners, with applications spanning areas including employee support, customer service, healthcare, higher education, and shared services.

You co-founded Druid AI in Bucharest in 2018 after spending nearly a decade at TotalSoft, where you progressed from .NET development into senior technology and business leadership. What convinced you at the time that conversational AI could become a core layer of enterprise technology, and how has that original vision evolved as Druid has moved into agentic AI? 

The convergence of two distinct paths – academic rigour and frontline enterprise pain – shaped my train of thought while I was doing my PhD. However, it was not until Liviu Dragan, an extremely visionary leader, came up with the idea of founding Druid AI that made me realise how the research I did could finally be used in real life.

Between 2008 and 2011, my PhD research focused on autonomous AI agents communicating via semantic web technologies and ontologies, exploring how intelligent systems could replace or sit atop traditional enterprise software. Shortly after, working in enterprise technology leadership exposed me to a stark reality: we were asking employees to manage untenable complexity.

Completing a single routine task meant knowing which application to open, where data lived, which policy applied, and who owned the next step. Meanwhile, outside the office, messaging was becoming the dominant interface for human interaction.

When we founded Druid AI in 2018, our vision was straightforward yet ambitious: give every employee and customer a virtual assistant capable of orchestrating work across the entire enterprise.

Nearly a decade later, that core vision hasn’t changed – the technology has simply caught up. Conversational AI was largely about intent recognition, retrieval, and triggering static scripts. Agentic AI changes the boundary of delegation. Modern agents assess goals, collaborate with specialised sub-agents, navigate disparate systems, and execute complex, multi-step workflows autonomously.

For us, the current agentic revolution is not a strategic pivot away from conversational AI. It is the natural realisation of our founding thesis: enterprise technology must become simpler for humans to help them get the job done, even as the orchestration behind the curtain grows infinitely more sophisticated.

Much of the AI industry has concentrated on building increasingly powerful foundation models, while Druid AI has focused on connecting different models to enterprise data, systems and workflows. As models become increasingly interchangeable, do you believe orchestration will become a more important competitive advantage than the underlying model itself?

At Druid AI, our core mission is simple: extract the extraordinary from every human interaction by efficiently getting the job done. But as the market matures, the key to delivering that value is shifting away from the underlying technology stack.

We are witnessing a classic pattern in enterprise tech: capabilities that once served as early differentiators are rapidly commoditising. Today, foundation models are accessible to every player. Enterprises will inevitably deploy a hybrid matrix of models selected for specific performance, cost, security, or regulatory needs. As intelligence becomes a commodity, the strategic battleground moves up the stack.

Today, the hardest problems in enterprise AI are about execution context: governance and access (which data can the AI touch, and under what policies), agentic routing (which specialisded agent should handle a given task), system integration (how do multiple transactional systems coordinate safely), autonomy vs. control (when can an agent act independently, and when is human approval required), Auditability (If a workflow fails, can you reconstruct the decision trail step-by-step).

This is why orchestration has become the ultimate strategic lever. Models produce intelligence, but enterprises require dependable execution.

Druid AI is built to serve as that definitive control and orchestration layer. It bridges different models safely across enterprise data, workflows, and people. Crucially, it provides the reference framework to measure execution effectiveness, evaluating true business outcomes.

In the long run, the winning question won’t be, “Which model are you using?” It will be, “How effectively can you turn raw intelligence into completed work for your employees and customers?”

Druid Conductor can coordinate multiple specialized agents across knowledge retrieval, decision logic and system actions. What becomes technically difficult when an enterprise moves from a single AI assistant that answers questions to multiple agents that can independently execute multi-step business processes?

The shift from simple conversational interfaces to multi-agent architectures fundamentally changes the engineering challenge. You stop managing a linear conversation and start managing a distributed decision-and-execution system.

With a single Q&A assistant, the core obstacles are intent recognition, retrieval, and response generation with a high level of accuracy. Multi-agent ecosystems introduce an entirely different class of distributed systems and questions:

1. Which agent holds authority to act, and how do you prevent domain drift?
2. How is state maintained as responsibility handoffs occur between agents?
3. How are contradictory decisions between specialised agents reconciled?
4. How do sub-agents inherit access permissions dynamically and safely?

These challenges compound when applied to real-world enterprise infrastructure. A single workflow might span a CRM, ERP, identity management platform, ticketing system, and legacy databases. Each operates under distinct business logic and failure modes, but in the end the conductor agent needs to get the job done right.

If step four of a six-step process fails after three systems have already executed transactional changes, a basic agentic pipeline breaks down. The orchestration layer cannot simply throw a generic error. It must manage state, execute rollbacks if necessary, determine if alternative routing exists, or gracefully escalate to human-in-the-loop intervention.

True enterprise orchestration is state management, transactional consistency, observability, policy enforcement, and fail-safe autonomy. The goal of this underlying complexity is simplicity: to deliver a single, frictionless interaction where complex multi-system jobs simply get done.

Druid AI has now powered more than one billion conversations across thousands of deployed agents. At that scale, what have you learned about enterprise AI that would have been impossible to learn from pilots or controlled demonstrations?

Production teaches you humility quickly.

A pilot is normally a relatively controlled environment. The use case is defined, the data is reasonably clean, the users are known and there is usually a project team watching very closely.

Production behaves nothing like that. People ask the same question in twenty different ways. They change their mind halfway through a conversation. They provide incomplete information. They switch languages or topics. They interact at unexpected times. Policies change. APIs fail. Back-end systems slow down. New edge cases appear that nobody thought to include in the original design. One thing is for sure: the users’ expectation is to get a job done effectively, seamlessly and in a natural way. Be it on text, but especially on voice, the conversation should flow naturally, with no latency; it should sound to some extent empathetic, and should perform the task while suggesting the best options and next steps if the case, or treat exceptions and loops human when needed.

Some of the highest-value automation comes from doing relatively ordinary things exceptionally well and doing them hundreds of thousands of times: answering an employee question, checking an account, rescheduling an appointment, resolving an IT request, or retrieving the right information from an enterprise system. That changed the way we think about AI value.

The second lesson is that go-live is just the beginning of a learning cycle. You need to see what users are asking for, which intents are growing, where conversations fail, where people escalate, and sometimes where the underlying business process itself needs to change.

And perhaps the most important lesson is that trust is operational, as enterprises trust AI because, over time, it behaves predictably, exceptions are handled correctly, decisions are visible and the organisation remains in control.

Druid’s production data suggests that a relatively small number of workflows can account for much of actual enterprise AI usage. Does this indicate that companies should initially focus AI investment on a handful of high-volume workflows rather than attempt broad enterprise-wide transformation?

One of the clearest patterns in our production data is that demand tends to concentrate. In financial services, for example, three workflow categories account for around 90% of production usage. In higher education, the concentration is even higher. That tells us something important about how companies should think about AI transformation. We have analysed these insights and come up with benchmark reports for higher education, healthcare and banking, which enable our partners and customers to identify the processes that would drive efficiency and help project how humans will interact with agents.

There is a temptation, particularly at board level, to begin with a very broad ask: “You NEED to use AI or we are left behind.” The operational team then needs to struggle in identifying the right jobs agents could perform while also fearing not losing their jobs. So, what would be the right balance and how would they be able to hire the right AI agent to do the job TOGETHER with them while maximising the KPI the board is expecting?

Start where there is potential to grow revenue and/or reduce cost, things that usually people perform repeatedly. If thousands of customers, employees, students, or patients are repeatedly trying to achieve the same outcome, you have a measurable baseline and a strong opportunity to prove value.

But there is an important distinction: start narrow, architect broad.

The first use cases can be concentrated. The platform underneath them should be capable of expansion across the enterprise. You prove the economics, governance model, integrations and human escalation mechanisms on a handful of meaningful workflows. Then you expand into adjacent processes using what you have learned.

Volume should not be the only criterion. A low-frequency workflow can still be extremely valuable if each successful resolution carries significant financial or operational impact.

As enterprises increasingly focus on successful resolution rather than simply maximizing the percentage of interactions handled without humans, how should organizations determine which decisions an AI agent can make autonomously and where human escalation should remain mandatory?

Druid AI has built an evaluation framework that covers 26 criteria and ensures an objective evaluation of the agentic orchestration on how it was built up to how it gets the job done.

If an action is reversible, relatively low-risk, governed by clear rules and supported by reliable information, then there is a strong case for autonomy. Rescheduling an appointment with predefined parameters is very different from making a clinical decision and may seem simple. But it should have a lot of elements to consider if it is to be done effectively: e.g. if doctor B has an empty slot, but he wanted to block it, the AI agent should not reschedule a patient’s appointment in that slot only because the task is to maximise the doctor’s calendar coverage.

There are several dimensions I would look at: the financial or human consequence of an error, whether the action is reversible, the completeness and quality of the information available, regulatory requirements, and whether genuine human judgement or empathy is required. Then you design escalation intentionally.

This is where I think some early thinking around AI automation was too simplistic. The goal became “contain as many interactions as possible without involving a human.” But in many processes, escalation is precisely the right outcome.

That is why I prefer to think in terms of governed resolution rather than pure containment.

The objective is for AI to autonomously resolve the work it should resolve, recognise the situations where it should not act, and bring a person into the process with the relevant context already assembled.

Once AI agents can retrieve sensitive information, update enterprise systems and initiate real-world actions, observability and governance become much more consequential. What should companies be able to audit about an agent’s reasoning, data access and actions before they trust it with mission-critical workflows?

Following Gartner guidelines, DRUID has a built-in evaluation framework that analyses agents from 5 angles: error tolerance, risk, compliance, observability and deviation. Under these categories, we have a total of 26 components. Each has a definition, an artefact you can open, and a measurement.

When evaluating an agent, the platform should be able to reconstruct the complete chain from the original user request to the final system of action. That means knowing which agent handled the request, which model was used, what context the model received, what enterprise information was retrieved, which business rules or policies were applied, why a particular route or action was selected and exactly what changed in the underlying systems. Tenths of auditable interactions are tracked, analysed, and measured.

Identity is equally important. An AI agent should never become a shortcut around enterprise access control. You need to know who initiated the request, what that person was authorised to see or do, and whether the agent remained inside exactly those boundaries.

With multi-agent architectures, traceability becomes even more important. Which agent delegated to another agent? What information crossed that boundary? Where did the decision originate? Which component actually executed the action? And then there is operational evidence: timestamps, confidence signals, execution results, exceptions, escalation events and the ability to understand or replay what happened.

This is one of the biggest changes as we move from conversational to agentic AI.

When AI only answers a question, observability is useful. When AI can change a customer record, trigger a payment, update multiple systems of record, or initiate a business process, observability becomes part of the control architecture.

You have held an unusually broad range of roles at Druid AI, spanning development, operations, revenue and customer success. How has working directly with customers shaped your view of why some enterprise AI deployments generate measurable value while others remain stuck in pilot mode?

I started my career as a developer, and like many engineers, I initially had a strong instinct that if the technology was good enough, its value should be evident. Customers teach you very quickly that this is not how enterprise technology works.

A technically sophisticated deployment can still create very little value if the business problem is not important enough, if the process owner is absent, if integration is treated as an afterthought or if nobody has agreed what success means. Customers are extremely good at stripping away the technology narrative. They do not care how elegant something is architecturally if the process they are responsible for has not improved.

When we talk about implementations on that scale, there is a business owner with a real problem to solve. There is a measurable volume, cost/revenue or friction. The AI is connected to the systems where the work actually happens. And there is a plan for adoption and continuous improvement after go-live. Pilots often remain pilots because they prove that the technology works without proving that the operating model works. That is why, whenever solutioning an AI project, we train our staff and partners to first understand the job, not the clicks users do in the systems. The “job” means the entire process, how they treat exceptions, what the outcome is, how frequently exceptions appear, what prevents them from increasing productivity, how long it takes and what effort is required to get a productivity increase if the job would not be automated.

My own career has moved through technology, operations, sales, customer success and company-building, and I now see that breadth as one of my biggest advantages. Technology teaches you how something works. Sales teaches you why somebody will pay for it. Customer success teaches you whether it works in the real world. Operations teaches you whether the organisation can deliver it repeatedly and at scale.

In many ways, Druid AI’s evolution has followed the same path: from proving that conversational AI could work, to proving that it could create value, to building the infrastructure required to make intelligent agents dependable at enterprise scale.

You’ve also been involved with Women in Tech Romania while building Druid into an international AI company. Where do you still see the biggest barriers to women founding and leading AI companies, and what would meaningfully increase their representation at the executive and founder level? 

Recent data highlights a striking gap in European tech: only 5% of AI startups are founded or co-founded by women, and just half of those founders hold a PhD. While the statistics are stark, addressing this disparity requires looking beyond traditional narratives about gender discrimination.

At its core, entrepreneurship is an individual pursuit shaped by personality, risk tolerance, personal priorities, and career choices. Rather than viewing this solely as a social barrier, we must examine the practical pipeline through which founders are forged.

While girls are statistically less drawn to technical disciplines early on, a far more significant and less discussed barrier emerges later in corporate careers: exposure to full business ownership.

Women frequently excel as world-class technical specialists and functional leaders. However, fewer transition into roles with direct revenue responsibility, P&L management, commercial decision-making, and overarching corporate strategy. These are the exact operational muscles required to found and scale an enterprise technology company.

My own trajectory from software development to CEO was not a linear line, but a series of transitions across leadership, operations, commercial execution, and ultimately company-building. In environments like the Romanian education system, where practical financial education and entrepreneurial training were missing for everyone regardless of gender, learning to navigate business risk was a step-by-step process of exposure.

Overcoming this gap also requires dismantling a common myth: the idea that technology leadership demands absolute mastery before stepping forward. In the era of fast-moving AI, no one holds every answer. The defining leadership traits today are curiosity, continuous learning, and the confidence to tackle complex problems before the outcome is guaranteed.

To see more women running technology companies, we must broaden access to commercial networks, champion visible role models, and actively encourage experienced talent to step out of functional silos, take P&L responsibility, and embrace the risks of business ownership.

Looking ahead, what do you think will separate the enterprise AI platforms that become deeply embedded in business operations from the many AI products that ultimately struggle to move beyond experimentation?

The dividing line will be whether they can move from intelligence to dependable execution.

Generating an impressive response is already becoming relatively easy. Operating reliably inside a large enterprise is a different story.

The platforms that become embedded in business operations will have to connect securely to existing systems rather than asking companies to replace everything they already use. They will need to work across different models and technologies.

They will need orchestration capable of coordinating agents, workflows and human decisions. And they will need identity, governance, observability and control designed into the architecture rather than added later.

But there is another requirement that I think will increasingly separate experiments from infrastructure: reliability under imperfect conditions. A demonstration shows you what an AI system can do when everything works, but an enterprise wants to know what happens when something doesn’t.

What happens when the data is incomplete? When an API fails? When two policies conflict? When confidence is low? When a user asks for something they are not authorised to do?

If an agent performs brilliantly 90% of the time but behaves unpredictably in the remaining 10%, you cannot give it responsibility for a mission-critical process.

For the last several years, the dominant question has been: “What can this model do?”

The enterprise question is becoming: “How can I get this work done effectively?”

The AI platforms that become deeply embedded in organisations will be the ones that can answer the second one convincingly: technically, operationally and economically. That is ultimately the opportunity we saw when we started Druid AI: to make intelligence part of how work itself gets done.

Thank you for the great interview, readers who wish to learn more should visit Druid AI.