# AMP's AI Agents Revolutionize Renewable Energy Monitoring

**Podcast:** Engineering with AI
**Published:** 2026-11-02

## Transcript

Svet Bajlakov is the co-founder at AMP.
They are a really cool renewables monitoring company.
When I was working with Odyssey Energy and doing solar in Africa, we were always really impressed with their hardware and software combination.
We saw them as literally sort of a benchmark that we were always trying to hit in terms of quality.
And yeah, so I always felt sort of a kinship with them from afar.
And recently, Svet and I got introduced through a colleague that we have in common, and we've got an opportunity to talk.
And Svet Bajlakov is our guest today.
on the Engineering with AI podcast.
Svet, thank you so much for taking some time out to join us.
I appreciate you.
Thanks, Seth.
Thanks, Khaled.
Thanks for having me on.
Yeah.
So talking to our mutual colleague, he's mentioned that you guys are doing some really cool stuff in terms of like having Asians hang out and Slack with you and using it for all sorts of different things.
We normally interview people talking about like what's going on with software development, which you guys do.
Fair chunk of that too, obviously.
Really, really interested to hear what else is going on at AMP, whether it's hardware, software, support, anything else that you might be doing with it.
Yeah.
So let's get to know you a little bit better first.
What led you into AMP?
And let's hear a little bit about how you got into solar and distributed renewables in the first place.
Sure.
Yeah.
Just a little bit of my backstory, I guess.
I started off in physics.
I loved it.
physics and science.
I loved it enough to do a PhD.
Decided academia is not where I want to spend my life.
Sort of went fully, foretold the other way and did management consulting for a few years.
And a combination of things that was happening at that time, this is back in sort of 2013, 2014, led me into renewables and into emerging markets.
In particular, I saw the development.
and the spread of renewables and the opportunity to really rethink the way that electrification and energy supply happens.
Well, I believe, but also in particular in emerging markets, the creativity that was happening there, super attractive.
Ended up diving headfirst into that space, joining first a mini-grid company in Kenya and then subsequently working for...
grid unit that Eon, the testable German utility, had set up of Rafiki Power.
So we're there.
We're developing mini-grids in Tanzania and Sierra Leone, a few other places.
And then in 2018, maybe a bit about my role.
So I joined initially as a sort of technical...
technical contributor, ended up being CTO of that outfit, which led me to oversee both the software that we were developing for running all of those mini-grids, managing things like smart metering, mobile money transactions, and so forth.
But then also the physical infrastructure, so the solar battery sites that we were setting up.
So anyway, in 2018, there was an opportunity to...
take the software side of what we built and spin that off into our own company.
So that's how AMP was born, myself and a couple of my co-workers from that time setting that up.
We initially had quite a strong focus on rural electrification mini grids.
Over the first year or two of our existence as a company, we ended up shifting much more broadly towards commercial and industrial renewables.
Which continues to be our main focus area today.
When I think of CNI, the North American example is like Home Depot with a million solar panels on the roof of a large industrial building.
As opposed to like, this is a utility grid or this is my house.
You know, it's that sort of middle ground.
What does that look like for you guys?
Is that mostly CNI in Sub-Saharan Africa or developing world?
Or are you sort of going CNI and globally?
What sorts of customers are we looking at when we say commercial and industrial for you guys?
Yeah.
So I'll talk a little bit about our customer base as it stands today and the directions where we're seeing the biggest expansion.
As it stands today, it is mostly Sub-Saharan Africa based.
It is actually mostly the Home Depot style systems that exist there.
So it's ranging from sort of bigger office buildings through to industrial, smaller industrial sites.
I guess the sweet spot is somewhere between a few hundred kilowatt hours of PV and several megawatts, maybe up to 10 or 20 megawatts.
We are seeing an expansion to utility scale sites now.
Mostly as a...
as part of the direction that many of our customers are taking, they're developing more of those sites.
I think as a sort of market where if you can get bigger sites, you do that.
We're sort of following them into that.
The technology doesn't change very much in terms of the digital, sort of the monitoring side of things.
The requirements do shift a little bit, but that's the direction that we're taking.
And especially with the AI angle that we now have, sort of, both internally and externally, which I'll obviously dive into in a minute.
We do see an opportunity to work with companies much more broadly.
We feel that there's a sort of missing piece of the renewables, AI operations puzzle that we have quite an interesting solution that we're about to launch to the world.
And we'll open up some interesting markets, for example, in the US and also LATAM and maybe Europe.
for us.
Cool.
Okay.
Nice.
Nice.
What tools do you use when you're, well, whether it's software or hardware design or almost anything you're doing, you know, in your role, there's probably lots of different hats that you're putting on and taking off.
Yeah.
So I'd say I'm a pretty agnostic user of the usual cloud code and codecs.
And I've switched back and forth between them.
I haven't.
Until recently, I hadn't really experimented very much with other harnesses like Pyre, OpenCode, although I keep hearing good things about them.
Maybe a little bit about our team setup to just sort of frame this and also where I sit.
We're still a pretty small team.
As a company in totality, we're about 13 or 14 people.
About half of that's on the engineering side.
And the rest is honestly sort of customer success.
And other people who are sort of like engineering.
adjacent at this point.
I mean, obviously, AI has liberalized, democratized rather, the way that people can interact with infrastructure and code and logs and things.
So it's been a matter of people, pretty much everybody on the team, contributing to the technical side of the equation in various ways.
And up until, I'd say like a month or two ago, it was still...
A lot of, you know, everybody sits with whatever their tools of choice are.
We did end up rolling out Cloud to everybody.
So everybody has a Cloud subscription if they want to use that.
And we sort of standardized on that.
For coding, it's generally been quite good.
I'm not going to rehash the whole like, Opus 4.6 was amazing, then it was downhill and go back to 5.5 and it's actually amazing again.
Right, right, right.
Have had a similar roller coaster.
But we've sort of...
all followed that somewhat independently as an engineering team.
And then one of the big unlocks for us was actually setting up collaborative agents in our Slack space.
Yeah.
What actually first inspired me, I want to give some credit there, what first inspired me to do that was reading a set of blog posts by, I believe it was a CTO at this company called Texture, which does that.
distributed energy in the US and about how they'd set up their Slack agents with OpenClaw.
And I thought, actually, that seems kind of nifty.
We should see if we can do something like that as well.
Ended up experimenting with a few different harnesses.
OpenClaw just seemed a little bit too chaotic.
Some others were a little bit limited in terms of what you can do and need a lot of hand-holding.
Ended up actually selling on Hermes agent for now.
Pretty happy with it.
It's not a complete slum done, but it allowed us to pretty easily set up agents that have their own workspaces, their own compute.
This is all sort of hosted by us, obviously.
Their own compute, their own connectors to various bits of code, repositories, infrastructure that we have in sort of our databases.
Their own identities.
So they have, you know, they have the main ones, at least, they work on this.
They have a linear personality.
They have a GitHub account.
And they exist in our Slack space.
So what I can do is anybody on the team can interact with them and can look at other people's interactions.
So, for example, we have a channel where we're going to stream of various errors or alerts that are coming.
from our software stack.
And if I see something that catches my eye, I can say, hey, we have an agent called Sparky, which is sort of the triage, like figure out what's happening here, agent.
It's like, hey, Sparky, can you look into this, figure out what's happening?
Sparky will go in, use her sort of AWS CLI to...
stream some logs, look at the relevant places, look at the code if need be, or any of the other resources that are available, and sort of figure out what the issue is.
And sort of park it, ask to carry a linear ticket, or I can bring in another agent.
So we have an agent called Coda, which is not very creative.
It's our coding agent.
I can say, hey, Coda, can you fix this?
So Coda will come in, look at the triage that Sparky's done.
So like, literally look at...
you know, the Slack thread context.
Right, right.
So I'm thinking of, like, you're in there in, like, a Slack room with multiple agents, and you're all sort of talking to each other.
Yeah, okay.
Yeah.
And, like, hey, Coda, like, can you look into this?
Like, can you do a PR?
You know, Spark has done the investigation.
She's figured out what the bug is, potentially.
Coda will go away.
Again, like, use...
his GitHub access, pull in the repos in his own workspace, do whatever needs to be done, spin up additional agents to do, like sub-agents to do PR, like to do code review.
And when he's happy with it, he'll go and create a PR and assign it to me, for example.
The nice thing is that, one of the many nice things is that in that PR, Coda will link to the Slack thread.
generated this.
He'll assign me to it.
I think we even set it so that I'll come up with the co-author of the changes alongside.
And so the attribution becomes a lot easier than what we're doing before where everybody's doing their cloud code locally and then cloud will inevitably push under your identity unless you very consciously change that.
Nobody really knows who wrote the code, what the context was, what was the prompt, what was the sequence that went into doing this.
So this is, I mean, it's allowed us just a much greater level of transparency as to who is doing what and what's being built and how it's being built.
Right, right.
So I'm imagining that the Jira ticket or linear, in this case, can literally link back to the Slack thread.
And you can be like, okay, what happened here?
And then you can go read, like, what did Sparky say?
What did Kota say?
Oh, that's why we did this.
Yeah.
Cool.
So the auditability is really high and the context is really high that way.
We can explore different angles of this, including sort of pros and cons versus other workflows, which of course there are.
It's not a slam dunk in all respects, but it has allowed internally a much greater level of collaboration and visibility among people.
Yeah.
Which is very cool.
compared to what we're doing previously, which was a lot of people living in their own little silos and sort of exposing the agent's work as PRs, but then not having very clear sort of auditability or very clear context for the rest of the team of exactly how something came to be.
Right, right.
I brought Claude something and it made all this code and it put it in there under my name.
I don't really know what it's doing.
Right.
Versus like we sort of co-created this.
Here's the Slack channel where we made it in the first place.
So the context is a little bit clearer.
Yeah.
Nice.
OK.
So when you say they get their own compute, they get their own, you know, systems that you host.
Should I think of that as like each one gets a Mac mini somewhere in an office or is this like easy two instances or like I mean, and I'm not sure it really matters, but just, you know, helping it get more concrete.
And then those are using, you know, Claude or Anthropic API tokens, I imagine, or Agent SDK or something like that.
Like how, yeah, let's think through that part and sort of help us understand concretely.
And then what?
You have them join the channel?
Like what?
There's got to be software in there somewhere that helps them figure out like, oh, I need to join the channel.
Actually, maybe that's a Hermes thing.
I think listeners will be aware of Hermes and know it.
The way I think of it is like, oh, I have a friend who's always talking about this Hermione space thing that he's doing.
So I'm kind of aware of it.
But what all does it have in the box?
Is that part of the configuration?
Like, yeah, I mean, maybe that's just what it does.
Maybe it knows how to connect to Slack.
So let's kind of get a little deeper concretely and like how that part works.
Yeah, let's unpack it a little bit.
So first of all, there's many, many possible ways for you to package all of this and to deploy.
I literally deployed the first iteration on a very old MacBook I have in a cupboard.
It's actually an 11-year-old MacBook, which has just been sitting around gathering dust.
So I thought this could be interesting.
I didn't want it to be something that's too sort of in our existing workspaces, especially because it was very experimental.
And after a couple of weeks, we're actually migrating it onto, migrating the agents onto an EC2 instance that runs.
in our AWS, but it's essentially firewalled off the rest of the VPC.
Got it.
So there's...
And by the way, we're now setting up external agents for our customers to do work with AMP, to do work on their energy systems, because we feel that's very powerful.
And we can go...
about that a little bit more later.
I do kind of want to circle back to Sparky.
I can imagine that being really useful.
That's deployed separately, so it's not on the sort of EC2 instance that hosts our internal agents.
The way that they're hosted there, we have one God agent, let's say, that has access to the host, and then every...
And we use that God agent to spin up other agents and set up their personalities, set up their...
their tools, all of the relevant things.
Each of those agents has a Docker-based sandbox where it can do code execution, and it has a workspace that's mostly within that sandbox, but there's mount points that go outside of that sandbox for artifacts that need to be exchanged either between agents or, for example, if it wants to send me a file in Slack.
which it can put that on a mount point that's available outside the sandbox, and the Hermes Gateway can pick up that file and send it to me.
The neat thing is that we've then also been able to fit out these sandboxes with the tools that every agent needs.
So, for example, an agent that's going to be doing graphical design or is going to be working with our accounting software has a different set of tools than an agent that's used for coding.
And indeed, the way we've set up, and this was a little bit finicky, but so Coda, for example, can, Coda, the agent that writes code, can itself spin up more Docker containers on its own Docker socket so it can, you know, when it wants to integration testing on a code base.
Even though it's technically sort of running its own code in its Docker sandbox.
So that took a little bit of thinking, a little bit of setting up, but it wasn't anything already on ours.
We sort of have the god agent that we don't use for any day-to-day work, but which you should just use for setting up everything else to save us because it has the knowledge of how Hermes works and some of the internals there.
And it can already do a lot of the profile setup without...
Oh, wow.
Right.
So it's not like you're writing a Hermes email.
You're talking to a Hermes agent that knows how to go make other Hermes agents.
It's nice.
Yeah, it's pretty neat.
We are getting to the point where...
So that was very useful in the initial stages of really getting things set up and getting it figured out and just working across the different sets of functionality that's available.
We are now moving, so for externally facing agents, to more infrastructures called deployments into specific ECS tasks that are...
I guess much more deterministic rather than us sort of chatting to an agent and chatting to one agent and getting it to sort of other agents.
Like at some point you sort of figure out what the code base should be, figure out what the configuration should be, figure out what the various MCP services need to look like.
So that's where we're going with that.
To maybe answer some of the questions that you had around, like how does that...
how did some of the other internals sort of work?
Yeah.
We use a codex subscription to run the actual models, and we use open AI models.
Hermes makes it very easy to do different things.
Got it.
APIs.
We had an experiment with DeepSeek.
I think 4.1 Flash came out recently.
It's also very good.
So if it's something you want to try.
like we want to move off of that codex subscription format to something else.
We can do that or we can do API.
They very famously changed their pricing recently and or not their pricing only what they give you for the price.
I'm expecting it to get worse still but honestly for now we're running at the moment GPT-6.1 Sol on medium or high reason for most of the agents and it's very solid.
I have no usage in terms of what it uses.
We have like a $100 a month subscription that all these agents run on.
Oh, really?
Yeah.
That's not bad.
Okay.
It's not bad at all, yeah.
For all of this, wow.
At some point, we need more.
We need to do the $500.
Or as I said, we can do API pricing.
But for now, it's actually the amount of work that we get out of them for the API.
Yeah.
It's phenomenal.
That's pretty amazing.
Nice.
Okay.
Yeah.
And then you mentioned the Slack connection.
So there is something that Hermes and pretty much all the other harnesses that they're so like, let's call it the open claw type of thing that have that built in.
It requires a little bit of setup.
You basically go into your Slack space and say you want to set up a bot.
I think now it used to be called bots originally.
Now they sort of have it.
It's sort of gradually renamed the two agents because people recognize that a little more.
But you set up a bot.
You get two tokens, and then you need to put those tokens on your Hermes host, and it will use them to set the Slack.
So that way you know it's yours.
It's not just some random one that's connected.
Okay.
Makes sense.
So Slack makes this very easy.
It basically uses socket mode, so you don't even need to expose any ports on your server.
Once you have the tokens...
the Slack part of Hermes, the Slack connector, let's say, will connect to the Slack API with those tokens, and that establishes the identity.
You can then see the agent in your Slack space, and you can add them to whatever channels you need to add them to.
Nice.
There's a bunch of knobs you can tweak about how exactly the agent behaves in Slack, which is quite a bit.
Does it monitor channels that it's in to reactively respond to people?
that's on that to be quite noisy in general not what you want to just like have every single message gets an agent response which right right i can help you with that no exactly no like yep um or there was also like one setting which i which surprised me was that once they're in a thread this is getting into the weeds but you can so there is a setting where you can say even once you're in a thread you will only respond once you're like at mentioned in a message, you will not respond otherwise.
That gets quite annoying because if you're having a one-on-one conversation with the agent in that thread, you don't have to want to like at message them in every single message.
Oh, right, right, right.
But on the flip side, it can get quite annoying if you bring them into a thread that you're having with your coworkers about something and then the agent will just respond to everything in that thread, even if you don't want the opinion.
So there's...
A little bit of prompting and a little bit of setting that we did to basically say, look, unless you're actually being asked for something, you don't have to respond.
And the agent can just emit a silence token, which does not show up in Slack.
And that's been a revelation to literally get the agents to be quiet unless they're being asked for something.
And that's actually where it's for you.
Wow.
Just generate the silence to complete.
I love it.
They can't not do something.
I think it literally is like all caps, no message or like no response or something like that.
And then that gets processed by Hermes into like, I'm not going to respond.
That's amazing.
Okay, no.
They have good Slack.
I'm glad you went into this week.
This is, this is a, this is, yeah.
Unless you're actually doing this, this is the kind of thing that people won't necessarily know what's happening, but that only makes sense, right?
Like I, if you did try and call it into a chat room, it's going to try to respond to everything.
So how do you, yeah, cool.
Okay.
Neat.
So I, so I've been thinking about Sparky though, ever since you mentioned it and you talked about streams of errors, streams of alerts.
And I mean, as a software developer, I can assume that that would be like, oh, this is my web server and it's saying what's going on in production.
That could also be an inverter out in the field, right?
Or a production environment of some sort, an operational environment, I should call it.
So, and maybe you're doing both, I guess.
But where does Sparky start?
Is it starting with like code and servers and those kinds of things?
And have you gotten into the operational monitoring as well as the software production monitoring?
Yeah, I'm really curious about that part.
And in many ways, that's the sort of almost like the more exciting part, just because that's an area of application.
And now we're really talking, you know, the podcast, obviously, engineering with AI.
We've taken the meaning of engineering to be a little bit broader.
We talk about physical infrastructure, energy systems, and all the engineering and operational.
sort of maintenance that goes into all of those.
Maybe it's worth, before I dive into that, maybe it's worth reflecting a little bit on how my perspective has shifted on the application of AI.
So obviously AI has been on sort of everyone's minds in one way or another for the past few years.
And we've looked at how to apply it to the AMP context beyond sort of building our product over that time.
And there have been sort of fringe use cases that we've gotten into.
For example, you know, somebody can upload their PDFs of their energy production forecasts and you can put those through an AI OCR sort of thing that will convert them into sort of like actual clean projections that are in our Postgres database.
And that's nice.
And we did at some point also build an agent that helps you sort of get data exports that were the exact data you wanted.
But it's still recordable.
a little bit more hand-holding than I wanted it to.
Yeah.
What was also challenging, or seemed challenging, was the fact that we're really using...
So if you think of the energy systems that work with, they generate a lot of quantitative data.
It's mostly just time series that come out of them.
And all of their language models, so they're not naturally very well suited to working with quantitative data.
And for a while, I think many people, including us, were trying to get them to work collaboratively.
It's a non-starter.
One of the real phase transitions there was this point, which coincided with the point where they can write code, but the point where they can write code to the data analysis.
Yeah, right.
When they have the right libraries, whether it's like Polars or DuckDB or just pure Python, if that's your agents.
Right.
Take a CSV file, for example, or some API results, keep it out of their context window, do some targeted inspection to figure out what's the schema, like what am I roughly looking at, and then write some code that will basically crunch that file and get your insights from the time series data.
So that's what we can now do.
And the fact that these agents have a workspace and have all those libraries, as I said, has been quite a game changer there.
And we have, this is a very roundabout way to get back to where we're talking about.
So we do have an externally facing agent, which we deploy for our customers.
We started the pilots, results so far are pretty amazing.
And we're actually launching that tomorrow.
Tomorrow, we respect when we're recording this.
I think by the time this comes out, it will have launched.
Called Ray.
That essentially looks at, all of your system data and has access to that, has access to the telemetry, has access to the various alert logs and can do a lot of very powerful stuff with that.
So I can talk about a few of the different use cases that we've already done with our customers.
The very simple one is taking the stream of alerts that are coming from every site and triaging that, basically saying, which alert is important and which alert.
So you can come in in the morning and say, hey, I'll give a little example.
Hey, Ray, can you tell me what's been happening across our portfolio of solar and sort of battery sites for the last 24 hours since I last checked in, for example.
So we'll go and...
It will usually start with triaging based on alerts, see if there's any high priority alerts that are coming from any of them.
And then it can do things like checking performance ratios or like other sort of telltale signs that something's good or bad.
It can check, you know, battery SOC levels or other, you know, anything else going out of anomaly, sort of out of usual ranges and into anomalous territory.
Right.
It can do that because it has access to On one hand, the data.
On the other hand, a processing environment where it can do all sorts of number crunching on this.
Right.
Right.
So to your point, I mean, if you've got like a stream of data coming off of one of these systems, it's like, you know, I can see the sun come up.
I can see the sun go down.
Like, OK, right.
I generated electricity and then I generated less electricity.
And if you just ask an LLM to read all of that and comment, it's going to comment.
But is it what it's going to say be very interesting?
Maybe not.
But to your point, if you can give it something like DuckTB, if you can give it something like Polars and suggest analysis or have it primed to do some analysis, then it could actually come up with something insightful.
Am I getting that right?
Yeah, exactly.
And basically what we've done is built skills into these agents.
Right.
Let's call it the forward deployed sort of ray agent.
So when it does a portfolio analysis, portfolio performance analysis, it knows what to look for.
It has sort of the basic recipes that it's going to pull up and the analytics it's going to do.
And it knows what things to look at, which are, again, sort of tied to what we have, the kind of telemetry that we collect in our database and the kinds of endpoints that we expose.
There's an MCP server that feeds all of that, but that's...
Ah, okay.
Makes sense.
So it can hook up into all of that, get the data dumps that it needs, and do the analysis that it needs to produce the results.
Maybe throw it in there.
So, I mean, I give the example of where you go in the morning and you ask it what's happened.
You can also...
It's quite powerful sort of scheduling.
options that are built into Hermes.
So you can ask the agent to, you know, to add every, you know, every morning at 7am, run this analysis and have the results ready for you.
Right.
I mean, you can really go, go down deeper rabbit holes with this.
Like you can tell it to already tag any other people, like maybe some of your field team.
that are responsible for particular assets and bring them into the conversation to flag that, you know, the assets that they're responsible for need some attention.
Right.
Nice.
Or draft a ticket into whatever.
Right.
Issue management and yeah.
Yeah.
Like all of these things can become just much more automated than they would have been in the past.
And it's...
Yeah, it's literally like having a coworker.
It's somebody who has that intelligence, is able to crunch numbers, and has access to the data that they can use to get insights and has their computer environment.
It's pretty amazing.
That's awesome.
What would an anecdote be, right?
Like in terms of like what's going on, you know, how is it looking?
How did things go yesterday?
And you get a response back.
what sorts of situations is it able to help with and sort of dispatch neatly versus like what's something that like it doesn't spot or does spot but, you know, can't handle.
Like help us understand like concretely what sorts of situations Ray is looking at and how does it deal with them and, you know, what's and yeah, help us out imagining that part.
Yeah.
Yeah.
So, The kinds of things that become quite easy to spot are things like, so if you have a clear alert pattern coming from a site, which is usually something like a string disconnecting or something tripping, like the inverter is tripping.
Right.
This goes a little bit into how the...
AMP platform sort of collects and aggregates and processes data.
But we do have alerts from the vendors themselves.
So if you have a Huawei inverter that's had some alert come in, then that will show up in the alert log.
Or if you have, even if the Huawei inverter did not trigger an alert, there's some built-in AMP alerts that will trigger under specific conditions.
So if you have like...
no string output on a particular string while all the other strings are producing, that's pretty clearly a bad thing.
Even if the inverter itself doesn't say, this string has tripped, clearly something's not right, there's some sort of disconnect somewhere.
So if we see these kinds of alerts, that's usually very quickly something that Ray would pick up and say, this needs investigation.
The interesting thing is that it will...
So especially in cases like that, we'll go and look at actual production on the site and tell you, you know, what is the impact or production on performance ratio?
Like what is the impact?
Has that dropped?
Like we're just getting alert noise without anything actually being affected.
Right.
Oh, right.
Okay.
So when we say string for our audience, which is you and I are energy nerds and you're a more recent energy nerd than me.
But string installers, when you've got like a set of panels and they've got a string inverter underneath them.
So this is like a set of panels and a small inverter out on the field that is sort of one, you know, one small unit.
But these all connect back into, you know, sort of the, as soon as to your point, when a string is down or we're not reporting, that could mean that like you've got a cable cut or you've got like.
Maybe shading, but it sounds like, no, that might have impacted multiple.
Okay, so it's like, okay, something's happened.
Like, something got disconnected or something.
I need somebody to go out there and look at it.
And to your point about, like, performance, like, if our signals tell us that it's disconnected, but we're still generating as much power as we did yesterday at this time, then maybe not.
But, yeah, help us fill in the details there.
Yeah.
So that's where...
It's actual prioritization.
The agent's prioritization capability is really sort of coming to their own.
Because many of our customers have like hundreds of sites, if not thousands.
Right.
To look at every single string disconnect or, you know, something tripping somewhere will usually be adds like so much noise that it becomes impossible to know what, like what to prioritize.
The nice thing is that you can...
So the agent can start by detecting the faults and then it can essentially build a priority list for you that says, so we'll look at actual output impact or like whatever the KPIs are that you care about, but most of those KPIs are going to be either just raw output or performance ratio, which is again a term from the energy of the solar space.
In particular, performance ratio is just the percentage of how much is this generating with respect to what I expect it to be generating.
Usually you're going for something close to 100%.
And you can have some thresholds if it's less than 90 or less than 80%.
Then, you know, something's not right.
So once it's sort of aggregated the status for every site and sort of flagged the issues that do exist, it can go and quantify the impact that's being observed on a side-by-side basis and say, hey, you know, these are the top three or top five things that need to be looked at in this priority.
Wow.
because that's the impact that we're observing from there.
Wow, that's amazing.
Are you finding that it's able to do that fairly effectively?
I mean, I can imagine an agent confidently telling me this is the most important thing and not being right.
Or what are you seeing in terms of its ability?
How much do you trust its prioritization so far?
I think it does that very well, actually.
You can help it actually quantify.
So we have one of the modules that we have is...
you know, it calculates monetary savings and monetary impact based on, you know, whatever the tariff is or whatever the cost per kilowatt hour, the price per kilowatt hour that you're selling.
Oh, wow, right.
So you can take the kilowatt hour shortfall and convert that to like an actual financial impact.
So, you know, we've been very impressed with the quality of the analytics and the calculations that go into it.
I would say the main caveat is that you do need high quality underlying data.
And that's something where a lot of these things can fail.
And a lot of times the...
Sorry, I just want to make sure that we're still connected.
Should be.
Oh, okay.
You froze.
No, you're back.
Okay.
So just to reiterate, the quality of their underlying data is a really strong driver in terms of the quality of the outputs.
It sounds obvious.
But I think there's often an expectation that sort of AI will sort of magically work when you sell these things.
Pixie dust.
Just add AI.
It's going to be fine.
Yeah, just sprinkle it on top and it will magically make everything work.
So we do actually spend a lot of time, and we have over the past years of building up the platform, making sure that we have high quality data feeds.
from a lot of different types of technologies, a lot of different vendors that we work with.
Maybe one useful piece of context there is that we do have, we mostly get systems, sort of the physical data comes from APIs.
There's no real standardization.
I know you've had experiences with this as well.
No, totally.
Completely unstandard.
Yes.
Yeah.
Well, and not only that, but I mean, the sometimes sites go offline for like a couple of months, right?
Especially when you're dealing with the developing world.
That's that.
Yeah.
Like there's a big storm and that takes out something and maybe generation is still working, but communications is not.
And so, yeah, you can you can run into big gaps or maybe you you switched.
The meaning, this power meter was installed in this circuit, and now we move to that circuit.
And I can remember once at Odyssey, we were just tearing our hair out over what was going on.
And we realized that someone had wired the grid connection into a meter that didn't used to measure that.
It used to only measure how much we were producing.
But all of a sudden, when they added the grid connection, they just added it to the same circuit.
And so when they were like buying from the grid, it made it look like we were producing less, but we weren't.
The production was actually still the same.
It's just that the meter was now summing different things and it hadn't been something before.
So, yeah, like I'm with you on the data matters.
Like it matters a whole lot.
Yeah.
Keeping it stable and IP address is changing and all of a sudden you were.
getting this measurement and now you're getting that measurement.
Like, yeah, there's definitely ways that things can go wrong.
Yeah, a lot of that, I assume, is...
Well, do you think...
Can Ray help us with some of that or technology like it?
Could it notice, like, oh, you know, something's been acting funny on this circuit now for a week and a half?
And just sort of bring that...
to somebody's attention?
Or am I like, maybe that's a step too far.
No, completely.
Again, we found the frontier models do have, and even though I'm going to say frontier models, I think anything that's released in the past six months at this point is plenty for these kinds of use cases.
They're not that complex.
You're not trying to do cybersecurity analysis.
So the right, like a capable model plus good instructions and good analytical tools that it can use can go a really, really long way.
They do, so one thing I'll say first, they tend to be very good at understanding data gaps and knowing how to handle them.
And even without like very heavy prompting about this, they will basically, if you ask them, as many, some of our pilot customers will do.
if you ask them to do a production report for the past month, it will say very clearly what the data quality was that went into that or flag any sites where data quality may be impairing the output in the required.
And it does that even without, as I said, even without you heavily prompting it to take those things into account.
It does do things like, hey, you know, I'm seeing these kinds of, I'm seeing like, two and a half megawatt output from this site, but like it's rated at like one and a half megawatts, like maybe the metadata is not right.
That's such a typical issue.
I mean, maybe not at that scale, but such a typical issue that we have with metadata that we have from the sites because it's something that somebody entered manually via spreadsheet.
Yeah, yeah, yeah, yeah.
So the agent can go and pick up those things and be like, that doesn't really make sense.
You should get that checked out.
Awesome.
Wow.
Tying that back into, many people in the audience will have probably more experience writing code where the agent will look at your code and maybe look at something somebody else wrote at some point in the code base, maybe another agent, and be like, you know, this kind of thing that they wrote here doesn't make that much sense.
It doesn't do what it should be doing.
Right.
You can translate that to the case of energy data analytics, like actually pretty cleanly.
They're very good at it.
It's spotting things that just don't make that much sense.
Wow.
I like that.
I like that.
What sorts of differences do you see between sort of, I don't know, if you're on DeepSea Core One Flash versus, you know, whatever Sol you were talking about, six something, I think.
Like, what goes differently?
Like, do you see, I imagine it's stuff like what you're talking about.
Like, maybe, you know, these models are better at remembering to, you know, to check, you know, for...
for data gaps, and those models don't, but I'm just making wrong guesses there.
What are the differences like?
We are in the process of setting up sort of proper eval, so it's more than vibes-based, but I can offer sort of a vibes-based opinion based on what we've seen, because the differences are notable, and also the differences, I would say, between the OpenAI models that we've been using.
Actually, when we started this off a couple months ago...
We were using Luna quite a lot.
Luna was very solid.
It would do, you know, the usual thing for well-scoped tasks where something clear needs to happen, you don't actually need a lot of raw intelligence.
The model just needs to figure out how to sort of like do some analytics.
If you ask it for a production report, it will go and do it.
Luna was very good at doing that.
We used DeepSeek for a while.
For similar tasks, for like log investigation, for example, or alert investigation, I was very impressed.
I found it less easy for a human to parse the output.
Let's just say it was quite verbose and quite detail-oriented.
There's something in the name DeepSeek.
It was seeking very deeply in things and really sort of, it was very super detail-oriented.
Good for some use cases.
And I think there's appropriate places for that.
We felt ultimately it was a little bit too technical, too technical, let's say, for that.
Interesting.
So again, maybe that, but like prompted differently could get you some good results where you're very interested that you want a response that's concise and that's not sort of like not super deep detecting or like explain like I'm five sort of thing.
Maybe that was the right direction, but I find it very impressive.
As I said, all 6.1, Sol 6 was, Luna 6 was not good.
Sol 6 also not great.
So I'm not surprised they rolled out of patch so quickly a few weeks ago.
But Sol 6.1 has been very solid.
It has what feels like a very good level of sort of intelligence, especially when it comes to kinds of things that I talked about where you're looking at some data and you're like, well, I don't know, that doesn't make total sense.
And you're then thinking around, well, how do I approach this problem?
Do I try and find a workaround?
Do I raise this with my human operator or something else?
And yeah, I'm quite happy with it.
To give a brief answer, yes, there are differences.
It's quite difficult to sort of quantify them.
What we do want to do is run evals where we basically give an agent a task and see what...
I'd love to do some more backtesting where we have like an existing problem that was resolved.
Oh, yeah.
we're in a different model through that same problem and see what comes out.
And whether the resolution's still the same, if we're happy about that, whether it still gets the right resolution.
It does get funny if you think about it, because many of these things are back and forth conversations between at least the agent and the human and sometimes multiple humans.
So what I'm trying to figure out is how you, and I'm sure someone else figured this out.
I just haven't looked into it properly.
How do you replay that conversation, but in a way that's going to make sense to a different model?
Because Obviously, if the model comes back with something that's entirely possible, I will then respond.
Right, right, right.
Of course.
Because it isn't all just one prompt.
It's a conversation.
Yeah, exactly.
Anyway, those are the sort of things that are on our mind now when it comes to model selection.
But as I said, happy with where we are now.
And one thing that's maybe my main takeaway is that the model just does not matter that much anymore.
Some base level of intelligence and capability is very good, but that's available across many models.
No, you don't need to be at the bleeding edge to get very, very solid results.
Okay, so I can imagine the next question I'm thinking about, are you looking at stuff like these discriminated models, right?
Classification models, regression models, JAPF, right?
Of course, which is the internet has been all the buzz about for like a week and a half, I guess.
Which in this day and age seems like a lot.
It's like if it survives that long, maybe it means something.
Yeah.
And we had Shingy from Asoba on, and he was talking a lot about JEPA world models as well.
And he was having some good luck using a combination of like RAG with inverter manuals and also the sort of world models in terms of reducing false positives and things like that.
But it sounds like you guys have found sort of a winning model.
So maybe you're not looking outside of it much.
But yeah, I'll ask.
We actually are.
I mean, something like Jev or that kind of model.
Actually, for me personally, I found it one of the most exciting developments to come to the...
It's not even the animal space because it's not really a lot.
But to this AI space in a while.
And it goes back to the issues that I described previously, which is that we...
mostly deal with numerical, with quantitative data.
Using those language models on that is not always the best.
So you sort of end up with these pretty weird, in some sense, workarounds where you get the LLM to write code that then looks at the data and does all of these things.
With a classification model, which is essentially a much more lightweight way to...
To do some simple tasks like the smart FL statement, there's quite a significant range of problems that we want to apply that to.
I think one of the first ones is what I described earlier in the conversation, which is alert triage.
So you have this stream of alerts.
And before you put all of that into the LLM, you can use something like Java classification model.
So like, hey, which of these are actually important in the context of the role existing?
can you synthesize that into, not the summary because it's not what it does, but into the top five alerts that are actually important and feed those.
Yeah.
I think that's the...
Well, and so much of triage is categorization, right?
Like triage is a decision based on categorization, right?
You know, is this life-threatening?
You know, yes, no.
You know, is that one, you know...
eventually life-threatening or more orgynately so.
I'm not good at medical terms, so I'll stop.
But yeah, so much of what a triage rule set is based on is being able to classify and categorize different things that you're looking at.
So it only seems to make sense.
It also is coming up for me when you were talking about the no-response response.
I wonder if you'll be able to ask these things to categorize stuff and not have them want to.
inject, you know, some flavor into every conversation when they're not being asked.
We'll see them in Slack, too.
I mean, and it goes, sort of goes, of course, Jet has been sort of exciting for a number of reasons, and people have applied it to many different things, and one of the applications that, to me, feels the most compelling, and we haven't done this yet, but we might want to look into it more, is when you do context compaction, do it.
classification on the context to figure out what's important, what's not.
Do you want to do some tool call results?
Do you want to do some models?
Because at that point, maybe not all of them are going to be that relevant.
So instead of feeding all of that stuff into an LLM context, do you want to know what we classify over at first?
Again, not related to necessarily the space that we're in specifically, but a very neat application that I think will make.
Totally.
Tool calls.
What should I be doing?
You know, what tools should I reach for right now?
Yeah.
So to your point, I think arming LLMs with these things, it's going to make LLMs stronger as well.
Yeah, for sure.
Oh, my gosh.
Well, okay.
So you've been really generous with your time today.
Thank you.
This has been great.
I love talking to people about AI and solar, and you've given me both of those in one conversation.
So this is awesome.
There are a couple of questions I like to ask everybody as we wind down.
So let's start with, if you can think about something that you once were pretty sure was true and then realized it wasn't, right?
Like, what's something that you've seen evidence and changed your mind on?
And this can be personal life.
This can be, you know, in work.
This can be about LLMs and models and all these kinds of things.
But yeah, what's something you've changed your mind on?
Yeah.
Well, I'm just afraid I'm going to give you an answer, maybe a cliche on this podcast, but it is a genuine answer.
If you'd asked me a year, maybe a bit more than a year ago, like, are we going to be getting to a point where we just don't really look at the code anymore?
Yeah.
I would have been very skeptical.
You know, as somebody who's been coding for a fair while and likes to be pretty hands-on with these things, I was, let's say, heavily using autocomplete and so forth.
And at that point, I was thinking, yeah, this is great.
This is really supercharging my work.
I can get so much more code out.
But I want to know what functions I'm writing.
I want to know the interface with each other, et cetera.
And to now live in a world where I just throw problems over the wall to an AI agent and get it to sort of implement something.
and then usually just have a couple of other agents review that.
That's my workflow.
I will look at the PR to make sure nothing streams what is happening here to me.
I would literally just ask one or two or three agents to review each other's code and maybe some team workers, although what my team workers will do is just call their agents at it.
I did not expect that to happen so quickly.
100%.
Again, I can relate to that.
You hear from others as well, but that's, yeah.
I used to have a rule against having that be the answer, but I've given up.
Oh, really?
Yes.
Oh, no.
Everybody.
Yeah, it's not.
It's literally the first thing that came to mind when...
No, I know.
Well, I mean, it's been a big change in our lives.
Well, and then to the point that you were saying, too, about...
A guest once said, the question is no longer should I review all the code, it's what code should I review, right?
And I find it instructive and interesting sometimes when do I reach for the editor to go, okay, wait, wait, wait, I want to go look at this.
But it isn't always, you know, like there are certain things where I really do and there's most things where I don't.
So yeah, that becomes the more interesting question is where to apply that, not whether to apply that.
I had an almost eye-opening moment yesterday when I went into my editor to make some very, very simple changes.
Literally something like changing some hard-coded strings into a variable definition, like a constant definition.
And I did them and I just couldn't like import something.
I literally just went back to Cloud Code and was like, hey, you know, I did the search and replace.
Can you go and like basically fix up all the code so it actually works after the search and replace it?
I did.
It felt very silly.
Yeah, no, I know what you mean.
What is, and this is definitely can be something outside of work or in it.
What is something that's giving you joy right now?
I'm going to give another.
Probably a cliche answer, but I do have two kids.
They're three and a half and eight months.
And seeing them get to know each other is a very, very deep well of joy for me.
Oh, wow.
I love that.
I love that.
That is an allowed cliche.
That one is not discouraged at all.
Yes.
Fantastic.
I could tell you about what's giving me joy seeing how we're using AI and how the team's coming together.
Sure, sure, sure.
And how everybody sort of brings their A game and their humble selves to work every day.
And that does bring me a lot of joy as well.
But it's on a different level to seeing two brothers get to know each other and grow up together.
That's fantastic.
Svet, thank you so much for taking the time out to speak to us today on the Engineering with AI podcast.
Appreciate you.
Thanks, Cal.
It's been great.