Key takeaways
- An agent, as LangChain defines it, is simply an LLM in a loop calling tools. A multi-agent system is the same idea with an orchestrator that hands sub-tasks to specialised sub-agents.
- A year ago, most teams were shipping demos. Today, most are shipping agents to production, including complex multi-agent systems. The new challenge is maintaining and improving them.
- The short-term opportunity in climate tech is internal: scale your domain experts and their knowledge without scaling headcount.
- Enjins’ internal multi-agent asset is what makes going from design to production in under 12 weeks realistic.
- Reliability is engineering, not magic: an agent harness with retries and fallbacks, row-level access control, human-in-the-loop approval, and full tracing for audit and evaluation.
- Ship early to production. That’s where real users surface the edge cases you can’t design for upfront.
Available on Youtube whenever you prefer to listen, and if it’s useful, share it with someone building in this space.
The state of agents in production
Jacob opened with the view from LangChain, which helps teams build and ship agentic applications reliably. That work rests on two pillars. The first is a set of open-source frameworks: LangChain, LangGraph, and more recently deep agents. The second is LangSmith, the commercial platform for the observability, evaluation, and deployment loop that production needs. According to Jacob, the open source has passed a billion cumulative downloads and runs around 100 million a month, and LangSmith is used by 300+ enterprise customers.
That vantage point gives a clear read on how the field has moved. A year ago, most teams were building impressive demos: single agents or deterministic workflows wired to a few tools. Very few had agents running in production. Today that has flipped. Most teams have shipped agents live, and a growing number are running complex, long-running multi-agent systems. The interest is real and measurable: Jacob noted that downloads of the deep agents library jumped from a couple of dozen a day last December to the order of hundreds of thousands today.
Why multi-agent, and why it’s hard
For genuinely complex tasks, one large agent trying to do everything doesn’t hold up. Breaking the work into focused sub-tasks, handled by specialised sub-agents under a single orchestrator, keeps context clean, allows tasks to run in parallel, and stays scalable as you add capabilities over time.
The catch is that LLMs are non-deterministic. Unlike traditional software, you can’t trace the logic and know exactly what will happen. That’s what makes the jump from prototype to production so steep, and the story doesn’t end at go-live. Once real users arrive, the edge cases start, and maintaining the system becomes as demanding as building it. Traditional testing doesn’t map cleanly onto agent behaviour.
Jacob’s read on how successful teams handle this came down to three habits: ship early and often so real usage guides you, treat agent engineering as a genuinely cross-functional effort (product, engineering, data science, and non-technical domain experts all shaping it), and put observability, evaluation, and human annotation at the centre of the process rather than bolting them on later.
Where multi-agent systems create value in climate tech
Bouwe took it from the abstract to the concrete. The short-term opportunity, in our experience, is almost always internal: using a multi-agent system to scale a team of experts and their domain knowledge, so operations can grow without linearly growing headcount.
Picture an energy company whose customers reach out across WhatsApp, email, and LinkedIn asking things like “how much did my solar asset generate last quarter?” The answers live scattered across Databricks, SharePoint, a CRM, and Excel, and today an expert digs them out by hand. Connect those sources to an orchestrator with specialised agents underneath, and the same experts can serve far more questions at the same quality. The longer-term opportunity follows from getting that internal system right: once it’s been hardened through enough expert-in-the-loop iterations, it can become client-facing, letting customers query the sources directly in natural language.
Bouwe pointed to two production examples across our verticals:
- Freight forwarding (Mobility & Transport). A logistics platform’s expert team was handling more than a thousand incoming emails, reading PDFs, structuring the data, and drafting customs follow-ups by hand. An orchestrator with two specialised agents, one to classify and label each email and one to draft the follow-up, significantly reduced the team’s manual work and made the scale-up far more scalable.
- Building decarbonisation (Buildings & Industry). A scale-up whose building experts spent around 60 hours of manual analysis per building, per quarter. An orchestrator with a raw-data agent and a contextual-data agent per building let them scale with the same team without lowering output quality, and it went from design to production in under 12 weeks.
Inside a live build
Joanne closed with the part the session was named for: an actual build, no slides. Her framing echoed Jacob’s, which was to get it live fast, start accumulating feedback, and get past the pilot phase. What makes “under 12 weeks” realistic isn’t heroics; it’s that Enjins has crystallised the recurring design and software decisions into an internal multi-agent asset. Agents may feel like magic, but underneath they’re still software, and most of the engineering is the same every time.
The three layers
The asset is structured in three layers. The user layer is what people interact with. The agentic layer holds the orchestrator that interprets intent and routes to specialised sub-agents, all developed inside a reliable agent harness: the traditional engineering (retries, fallbacks, guardrails) that keeps a non-deterministic system dependable. The data layer connects both structured sources (Postgres, Databricks) and unstructured ones (documents, emails, notes, SharePoint). A recurring principle is thin agents, thick tools: push the domain knowledge into the tools rather than the agent, and you get more control and can run smaller, cheaper models. Underneath it all sits the LLMOps foundation: tracing, evaluation, and the integrations that let you see exactly what an agent did and why.
Demo 1: a customer-facing journey (Prets)
The first demo was Prets, a Utrecht company that helps people finance sustainable home upgrades like heat pumps and batteries, guiding them through the financing process end to end. It looks like an ordinary platform, but a multi-agent system runs underneath. Around five agents plus an orchestrator route each request to the right place, adapt to the user’s technical comfort level, and make sure there are no dead ends. Because it’s live, it also reveals what’s missing: every interaction is traced and stored, with checks and evaluations running so the team can see which agent to build next.
Demo 2: scaling an asset manager (Greenfield Energy)
The second demo used Greenfield Energy, an anonymised example built on the same asset. Meet Sarah, an asset manager responsible for a portfolio of solar parks and batteries. Her job is to keep every asset performing and compliant with its power purchase agreements. That work means cross-referencing live generation data, contracts buried in SharePoint, and specific clauses that only apply under certain conditions.
In the demo, Sarah simply asked questions. When she asked how the Northwest Europe wind assets performed in Q2, the orchestrator interpreted the intent, routed it to a data agent whose only job was to pick the right endpoint and parameters, and returned the answer. A few details that matter in production stood out:
- Access control by default. Single sign-on carries the user’s own permissions through to the data. When Sarah asked about a portfolio she wasn’t authorised for, the system respected that.
- Real analysis, not just lookup. Asked which assets underperformed their PPA and why, the system flagged the one to watch and showed where each figure came from.
- Trust and traceability. An agent activity tracker lets the user see what happened step by step, backed by detailed traces in the LLMOps layer for audit and explainability.
- Human in the loop. Raising a work order created a Jira ticket, via MCP for common tools and custom integrations for legacy systems, but nothing executed until Sarah approved it.
Joanne also showed where the interaction model is heading: generative views, where the agent takes you to the right widget with the right filter already applied rather than regenerating a whole interface. Her honest take was that we won’t all be talking to a voice that generates everything on the fly. People still want familiar, recognisable places to work. It’s an area that’s very much in motion.
The honest part: what it takes to run these reliably
The Q&A is where the trade-offs came out, and we’d rather be straight about them. Multi-agent systems give you more capability, but you trade away some control. They’re more autonomous, which makes them harder to keep reliable. That, as Jacob put it, is the art of building these applications today. Prototyping is easy; making the thing behave properly is the work.
A few practical guardrails came up. Aim to get an agent to a high level of correctness through evaluation loops and experiments, but don’t put a multi-agent system somewhere a single wrong action is business-critical. That’s a sign the use case isn’t the right fit yet. On sensitive data, everything can run inside your own VPC, with a small model self-hosted and the whole system kept within Europe for compliance, and access controlled through the credentials passed into each tool. And above all: ship early, because production is the only place the real edge cases appear.
Thinking about where agents fit in your operation?
This is the work we do side-by-side with client engineering teams, from a first design sprint to a production-ready multi-agent system your team owns. If you’re exploring where agents could scale your experts, let’s talk.
