Scaling Agents in Europe & The Middle East: Lessons from Schneider Electric, Vodafone, and monday.com

Agent programs in the region are taking a different path from the consumer-facing applications that get a lot of attention. Fewer teams are starting with a single flashy chatbot. More are starting with a platform, often because they already have a dozen agent proofs of concept scattered across business units, and no consistent way to bring them into production.

This is a pattern we’re seeing appear across industries with very different levels of regulatory pressure. From energy and telecom to insurance, banking, and retail, the underlying challenge is consistent. Companies are finding agents easy to prototype and much harder to operate. Operating well requires an infrastructure layer that many teams did not anticipate when they built their first agent.

This piece looks at how three companies built that infrastructure layer:

• Schneider Electric runs an internal AI Hub of 350 people supporting more than 60 agents across critical infrastructure, with an LLMOps discipline built around observability, evaluation, and deployment
• monday.com rebuilt its AI assistant, Sidekick, from a single general-purpose agent into a layered system of subagents, bounded tools, and sandboxes after discovering in production that adding more tools was making the agent worse, not better
• Vodafone built two production assistants, Insight Engine and Enigma, on LangGraph and uses LangSmith to monitor and improve them

Alongside these three, we’ll draw on patterns emerging across a broader set of agent programs we’re seeing in the region, spanning industries from insurance and security operations to consumer retail.

The emerging patterns in agent programs

Central agent platforms are consolidating fragmented agents across the enterprise. The most common pattern in the region right now is that teams are investing in a platform, rather than building single agents. 35% of organizations we speak to describe a company-wide agent platform or control plane as the primary use case, with business-unit agents eventually running on top of it.

Companies with a dozen or more agent efforts underway tend to reach the same conclusion: individual teams are rebuilding the same foundations, and someone needs to own the shared layer. That can mean vetted, reusable templates or frameworks that keep teams from reinventing the basics, or consolidating decentralized development into a central AI hub that supports the full lifecycle. At this stage, it is not unusual for a company to have hundreds of proofs of concept but no clear path to production for most of them. A central agent platform can solve this problem.

Many organizations are finding ROI from building agents for regulated document and back-office work. 18% of organizations we speak to are focusing on claims, underwriting, invoices, tenders, procurement, payroll, or other workflows with both an existing paper trail and a known cost per case. Agents for policy-wording review, claims-document classification, loss-run extraction, and invoice validation are all in production. In many cases, work that once took hours can now be completed in minutes.

Risk, compliance, and security operations use cases are rising in the region. 12% of organizations we speak to are building agents for reducing analyst workload in functions that carry audit obligations. Examples include triaging low- and medium-severity security alerts, running second-line assurance and anti-financial-crime testing, and automating flagged-transaction verification with an attached confidence score.

Federated building begins once engineering starts to become a bottleneck. 16% of organizations are trying to help non-engineers build agents with central guardrails. The common pattern is enabling low-code and non-technical users to configure agents, while engineers industrialize the ones that work. To accomplish this, teams are building global platforms (leveraging products such as LangSmith Fleet, offered headless for enterprises) where teams can configure, evaluate, and publish agents without writing code, while central teams enforce the standards required for production.

Observability, evals, and cost control are the foundation for scale. This is the most common theme across our conversations. Observability is increasingly tied to governance and spend, alongside debugging. Teams want tracing, evals, prompt management, and annotation queues across dozens of use cases at once. Increasingly, teams are also putting an LLM gateway at the center of the roadmap to create unified visibility across users, models, tokens, spend, and policy before agents are given broader autonomy.

The three teams below show what it takes to operate agents once a company has moved beyond its first pilot.

Three leading teams building agents in production

Schneider Electric: LLMOps as a shared discipline across 60+ agents

Schneider Electric is a global energy technology leader, driving sustainability by electrifying, automating, and digitalizing industries, businesses, and homes. With 160,000 employees and roughly 40 billion euros in annual revenue, the company runs an ambitious AI program: an internal AI Hub of 350 experts who have deployed 60+ agents to optimize energy consumption, extend asset lifecycles, and accelerate developer productivity.

Schneider's broad AI program spans three categories: 

1. Embedding intelligence directly into products to cut energy consumption (such as thermal learning in room controllers)
2. Using AI to forecast demand and production so customers can shift electricity usage toward cheaper, greener times of day
3. Deploying agentic copilots that reduce operational friction, like managing a more complex grid, customer success, or querying a carbon emissions software system

Agents are embedded across these objectives, operating in critical infrastructure with strict data residency requirements and cybersecurity controls. Schneider needed a common agent platform that could help teams build quickly while preserving control over data, deployment, and quality.

“The challenge of accuracy, the challenge of quality of answers, the challenge of guardrailing, are very real. When you deploy a solution at scale, you need tooling like LangSmith. Everything linked with trustability and understanding what happens is extremely valuable for us.” — Philippe Rambach, CAIO at Schneider Electric

Schneider’s AI Platform team sits within their AI Hub and provides the shared infrastructure that enables AI squads to reliably deliver across their vast technology landscape (multi-cloud, from cloud to the edge, and all types of AI).

They’ve built LLMOps capabilities around LangSmith and the broader LangChain ecosystem to:

• Deploy and continuously improve the accuracy and quality of an AI Assistant serving 140,000 employees in 100+ countries
• Co-build an LLMOps maturity framework to deploy their Customer Success Manager Copilot
• Accelerate their quotation workflow with LangSmith Deployment's task-queue model

Observability

Schneider self-hosts LangSmith on AWS EKS behind its own security perimeter. One of its most important structural decisions was to create one workspace per AI product spanning every environment, from development through production, rather than creating separate workspaces for each environment.

Structuring this way facilitates the improvement loop. Production traces can flow back into development datasets for offline evaluation, while subject-matter experts can annotate a production trace and push it directly into a dataset.

One Jo, Schneider’s internal AI assistant, serves 160,000 employees across 107 countries. Every conversation is traced, and production traces are systematically reused to build regression datasets and detect drift.

Evaluation

Schneider has invested in evaluation on three fronts. First, it built offline evaluation templates, standardizing dataset conventions and evaluator interfaces across squads.

Second, it created an LLMOps maturity framework that scores each of its 60+ products on instrumentation, offline evals, online evals, and feedback loops, then uses those scores to gate progression from exploration to industrialization.

‍

Third, Schneider has brought subject-matter experts directly into the evaluation process. About 20% of its AI products now have at least one active annotation queue where SMEs review real production examples. Its Customer Success Manager Copilot, used by more than 250 CSMs, was built with SMEs involved from the beginning, which the team credits with helping it reach high quality and adoption at launch.

Deployment

Rather than running every agent on one centralized runtime, Schneider standardizes on the LangSmith Deployment reference architecture: Agent Server with Postgres and Redis, under a “you build it, you run it” model. Each AI product runs on its own dedicated stack. This removes single points of failure where a faulty deployment could impact every agent in the company.

In its Digital Energy division, a document-processing agent that analyzes quote requests and specifications now completes work in just over 15 minutes that previously took hours or days. This type of long-running background workload benefits from a task-queue-based deployment model.

The tradeoff is more infrastructure to manage and more upgrades to coordinate, which Schneider has identified as an area for continued investment.

Key Lessons

Schneider's early investment in LLMOps paid off. Without trace-level observability and a solid offline evaluation process, none of the company's agentic products would have reached production readiness. Teams that skipped early instrumentation were the ones who later struggled to debug non-deterministic regressions without good data to work from.

‍

Schneider also learned to rely on out-of-the-box features before building custom ones. Building elaborate internal frameworks, especially for evaluation, was tempting. In hindsight, it worked better to extend existing tools instead of building new ones, like a thin CLI on top of the LangSmith SDK, a custom role mapped to an existing permission model, and scheduled reports built off the public API.

Finally, Schneider found that the LangChain ecosystem strikes a good balance between integration and flexibility. The tools work well together (open-source libraries, LangSmith for observability and evaluation, and LangSmith Deployment with LangSmith Studio), but they aren't locked to each other. The OSS libraries can be used on their own, and LangSmith works cleanly with third-party frameworks too. This has given Schneider room to mix and match tools without putting themselves into a corner.

Learn more: Schneider User Story (Blog)

Vodafone: from working pipelines to monitored production systems

Vodafone serves more than 340 million customers across mobile, fixed, IoT, and enterprise services, and operates a network of data centers across Europe. Its data and AI teams built two internal assistants using LangChain and LangGraph to support engineers working across that infrastructure. These assistants help Vodafone’s engineering teams operate its infrastructure more efficiently.

Performance metrics monitoring (Insight Engine): This assistant analyzes performance metrics by converting natural language queries into SQL to retrieve key data from data centers monitoring systems. This supports engineers and operations staff with dynamic, data-driven insights that were previously accessible only through custom dashboards.

If the query is related to inventory data, then the agent will direct the request to a NL2SQL chain that will convert the NL query to a SQL query and send the response back to the agent. The agent will then forward the request to another query processing chain that will query the inventory DB, receive the result, and then pass the information to a LLM to create graphs and charts based on the query response.

Information retrieval from MS-Sharepoint (Enigma): This assistant enables efficient access to thousands of technical documents and resources. Engineers can ask questions to verify specific designs, retrieve inventory details, or identify contacts within the organization, reducing time spent sifting through documentation.

If the query is related to document summarization, the agent will direct the request to the appropriate chain. In turn, this will fetch the relevant context from the multi-vector DB and present the grounded summary response to the user.

Both systems use a LangGraph agent to classify user intent before routing the request to the appropriate chain.

“We’ve been using LangChain’s components for over a year now. It’s been a critical enabler for our transition from open-source experimentation to production-grade AI systems.” — Antonino Artale, senior manager of Cloud Solutions, Orchestration and Intelligence, Vodafone

Vodafone now applies production-grade observability across these systems. Every Insight Engine and Enigma conversation is traced end to end, giving the team visibility into where issues arise across the pipeline.

In these multi-step systems, a poor answer can originate several hops before the final response, whether from misclassified intent, malformed SQL, or the wrong document version being retrieved from SharePoint. End-to-end tracing makes it easier to pinpoint the source of the problem rather than debug only the final output.

As Vodafone’s GenAI footprint grows, the same monitoring discipline can extend across more data sources, increasingly sophisticated multi-agent workflows, and a broader range of AI applications.

Learn more: Vodafone User Story (Blog), Fastweb + Vodafone User Story (Blog)

monday.com: why capable agents need more than just tools

Sidekick is monday.com’s AI assistant. Its first version was a single general-purpose agent with a growing list of tools: summarize a project, draft an update, analyze a file, update a board. That was useful at the beginning because it allowed the team to move quickly and learn what users actually wanted.

Then Sidekick moved into real production workflows, and new problems emerged.

Tool selection became less reliable as similar tools with overlapping descriptions competed for the model’s attention. Tool schemas consumed context that could otherwise have been used for the user’s actual request. A single prompt had to carry comprehensive instructions for research, writing, data analysis, and board operations.

Failures also became harder to diagnose. It was difficult to tell whether a bad outcome came from planning, tool selection, tool execution, retrieved context, or the final response. Testing became combinatorial as introducing one new tool could break workflows that had nothing to do with it.

monday.com rebuilt Sidekick around bounded responsibilities instead of a single large reasoning loop, using LangGraph and Deep Agents to give the system clearer layers:

• A context and permission layer determines what is relevant and what the user is allowed to access before anything reaches the model.
• A main orchestration agent interprets the goal and decides how to handle the work. It may answer directly, call a tool, delegate to another agent, or use a sandbox.
• Subagents handle narrower objectives with smaller toolsets. A content-generation agent, for example, does not need access to every board-management tool. This gives the monday.com team clearer ownership and makes evaluation more targeted.
• Tools provide controlled access to monday.com and external systems. They have permission-aware context and work well for bounded operations such as reading a board, searching for documents, updating an item, or triggering a known action. They have a 3-tier classification system with tiled tool discovery. The agent has to explicitly activate them to unlock their full schema. The team sees this akin to handing an LLM a menu instead of throwing the whole kitchen at it.
• Sandboxes handle work that does not reduce cleanly to a bounded API call. Reconciling several uploaded CSVs against board data, for example, may require inspecting files, writing and executing code, recovering from parsing errors, and generating a chart without forcing every intermediate dataframe through the model’s context window.
• Observability and evaluation trace the entire path, including model calls, delegation, sandbox activity, latency, and token usage. A successful tool call, after all, does not necessarily mean the user’s goal was achieved.

Sandboxes provide the agent with a place to work

monday.com found that tools and sandboxes serve different purposes. Tools are a good fit for bounded, auditable actions, while sandboxes are better for work that requires iteration.

If a user uploads several CSVs and asks Sidekick to reconcile them with project data, the agent can place the files in a sandbox, inspect them, write and run code, recover from errors, and generate an artifact without pushing every intermediate step through the model’s context window. The main agent only requires the result, and a summary of what happened.

For Sidekick, tools provide controlled access, subagents provide specialized reasoning, and sandboxes provide an execution environment.

How the LangChain ecosystem fits together

monday.com uses different parts of the LangChain ecosystem for different layers of Sidekick:

• LangGraph and Deep Agents for stateful execution, planning, delegation, and multi-step workflows
• LangSmith Observability & Evaluation for tracing, debugging, evaluations, dataset management, and comparing agent implementations
• LangSmith Sandboxes for isolated execution involving files, code, artifacts, and longer-lived intermediate state
• Standardized model and tool abstractions so individual components can evolve without rebuilding the entire runtime

When the main agent delegates to a subagent or uses a sandbox, the activity stays visible in the LangSmith traces. This lets the team see whether a failure came from context retrieval, planning, delegation, tool execution, sandbox execution, or the final response.

For monday.com, LangChain’s frameworks provide reusable primitives, while leaving the team in control of its own models, retrieval layer, permission system, tools, and user experience. This lets engineers spend more time on what is specific to monday.com, rather than rebuilding generic agent infrastructure.

Key lessons

monday.com learned that adding more tools does not necessarily make an agent more capable. As Sidekick’s toolset grew, similar tools began competing for the model’s attention, tool schemas consumed more context, and testing became harder. The team found that giving the agent clearer capability boundaries worked better than continuing to expand a single general-purpose system.

monday.com also found that different kinds of work need different execution environments. Tools work well for bounded, auditable actions, while sandboxes are better suited to tasks that require iteration across files, code, and intermediate state. Separating those responsibilities, along with delegating specialized reasoning to subagents, made Sidekick easier to manage and evaluate.

The team also learned to build observability and evaluation into the architecture itself. A successful tool call does not necessarily mean the user’s goal was achieved, so monday.com needed visibility across the full execution path, from context retrieval and planning through delegation, tool use, sandbox execution, and the final response.

Finally, monday.com found that a more sophisticated architecture does not have to create a more complicated user experience. Looking back, the team would have split into specialized subagents earlier, before the original general-purpose agent accumulated so many responsibilities. But Sidekick can still feel like a single assistant even when specialized agents, tools, and sandboxes are working behind the scenes. 

Learn more: monday.com User Story by Omri Bruchim (Blog)

What’s top of mind for agent builders in the region

Looking beyond these three examples, similar themes are emerging across the region in where agent builders are focusing their efforts.

Data residency and control often dictate the architecture, before the use case does. Companies across banking, insurance, and telecom are taking a similar approach to Schneider.  They want to first prove that the platform can meet internal security and policy requirements, then focus on expanding what the agents can do.

Organizational alignment is one of the hardest parts of scaling an agent platform. Schneider found that adoption depends on getting teams aligned around common practices, standards, and ways of working. The technology itself can often be integrated relatively quickly. We dive into this more in our guidebook on the Agentic Operating Model for aligning people, process, and technology.

Tracing turns vague failures into problems teams can actually fix. Schneider can detect drift in One Jo. Vodafone can identify which stage of Insight Engine produced a bad answer. monday.com can distinguish a planning failure from a sandbox failure. Observability becomes most valuable when teams move from asking “did this work?” to asking “where, specifically, did it go wrong?”

Regulated, high-volume back-office workflows often make the ROI case easiest to prove. Claims, underwriting, invoices, and compliance testing already have measurable costs, structured processes, and established audit trails. That makes them natural places to demonstrate value. Much of the highest-conviction agent work in the region is starting in operational workflows, like Vodafone, rather than in customer-facing chat experiences.

Closing

The agent programs furthest along in the region are building the platform, guardrails, and measurement layer alongside the agents themselves.

This pattern shows up in different ways across these three teams. Schneider invested early in LLMOps to create a shared discipline for dozens of agents. Vodafone added the observability needed to understand and improve complex production workflows. monday.com rethought Sidekick’s architecture around clearer boundaries between agents, tools, and sandboxes.

Across all three examples, these production systems rely on the structure around the agent: the infrastructure, controls, and feedback loops that make behavior visible, measurable, governable, and continuously improvable. That is increasingly where the work of scaling agents in the region is focused.

‍