Project Learning Blog-Team22

0. Where Idea came from
The idea came from my teammate Stella, who struggled to find a suitable energy supplier because there was so much information. It was difficult to choose a supplier depending on contract length, contract type and whether you have solar panels on your roof. Also, net metering (saldering) ends on 1 January 2027( Rijksoverheid, n.d.).
Although comparison websites exist, it might be hard for people to keep checking their usage and update it regularly. This made us want to create an AI agent that recommends when to switch energy contracts based on each household’s needs or even switch for them within the thresholds they set.

1. My role and own contribution
My contribution to AI Strategy Lab( Enerwise project) was building the AI agent prototype and recording the demo video. In addition, I ran a simulation with 25 households, using real scraped tariffs to see if our algorithm works well. After finishing the simulation, I wrote our key assumptions and the final recommendation on what to implement, change, scale, stop and test next.
I was in charge of building phases 1 and 2, while Khushi worked on phase 3 (web scraping). For phase 1, I used Lovable to mock up 6 energy suppliers and validate the logic. In phase 2, I connected an LLM (Claude Haiku 4.5 through Lovable AI Gateway) to our agent, replacing the static explanation text. At this stage, all the calculations and recommendations were generated by code, while the LLM only writes the explanation of why. I also built an Autopilot mode, but since it is a prototype, it only simulates the switch instead of executing it.

2. Important decisions and iterations
While building our prototype, our team asked ‘What makes ours different from existing services?’ We tried to answer that question by adding a solar panel option and an Autopilot mode. With net metering ending on 1 January 2027, solar households will soon reconsider their contracts. Therefore, Enerwise could be their solution whereas other comparison websites may not reflect this information yet.
However, I had to rebuild parts of prototype because we decided to add solar panel option after building the draft of prototype. I had to put the solar panel feed-in formula into deterministic code and let Claude know Enerwise should also consider solar panels. Also, Khushi had to add a solar feed-in data scraper aligning with what I did in phases 1 and 2.
I learned that our team should discuss how new features might affect our code and data structure before building separate parts.

3. What surprised or failed
At first, I came up with 5 main energy suppliers, but only 4 of them could be scraped. We ran the scraper on a weekly basis through GitHub Actions, but some websites hid their prices behind sign-up forms. For example, to reach Vattenfall’s contract page, we had to enter personal information in advance, so it was impossible to scrape it each time. Also, Greenchoice’s tariff sheet was outdated, so we had to hold it back.
What surprised me was what I ended up creating in the prototype. Not only did I build the main features, but I also implemented admin features for our own convenience like logs of guest data and exporting all data as CSV. When we first made the blueprint of the website, we didn’t think those features would be necessary. However, as we immersed ourselves into the website and imagined ourselves as users or administrators, we naturally came up with them.
Moreover, when I ran the simulation with 25 households, I found that the one-year Oxxio offer was the cheapest option for all 25 of them. This showed me that what we should focus more on is not which supplier, but when to switch with Autopilot mode.

4. How feedback and evidence changed the work
Even though I wrote in the prompt that code should handle calculations and the LLM should only provide explanations, I found that the LLM still intervened in the calculation and gave wrong numbers. In one case, it deducted the exit fee twice, so it showed €268 instead of the actual €529 saving. What I learned was that I cannot control an LLM only by writing a prompt. So, I added a number check mechanism. If the numbers in the LLM’s explanation differ from what the code calculated, the LLM regenerates the explanation, and if it’s wrong again, the system replaces it with a standard explanation.
At first, this checking mechanism was so strict that 8 of 25 explanations fell back to the standard text. I found out that 7 out of 8 fell back because there was no information about the saving before the exit fee and extra cost. After putting more information into the prompt, the fallbacks dropped to 0 of 25. However, when I manually reviewed them, 10 of 25 explanations still had errors that the automated check did not catch. That’s why I added human review to the governance part.

5. What I learned from collaboration
Khushi and I worked on different parts in prototyping, but we constantly needed to communicate what had to be done and what was already done. One example comes from file saving location. She stored it in a table called ‘tariff_snapshots’, while my Lovable app was reading the data from a different table called ‘tariffs’. Therefore, data existed but was not reflected in our website.
Another problem was that the same contract was labelled ‘fixed’ on one side and ‘fixed_1y’ on the other. These tiny differences in formats and names made our parts misaligned. What I learned is that even if we split up the work in an AI project, we still need to agree on the data structure from the start to prevent misalignment.


6. How the project changed my understanding of AI and business strategy
Before I built an AI agent, I thought that implementing AI itself would give us a competitive advantage over competitors in the market. However, as I learned in the course, using public AI tools is only Level 1(Cook et al.,2024), which does not create a sustainable advantage. In our project, by adding solar panel option and autopilot mode, we tried to build complementary innovations.
I also believed that if our service was feasible and helped people live better, people would definitely pay for it. As we built the business model, I realized that being useful is not the same as being paid for. Many people just check the cheapest offer and might go directly to other websites. This is platform leakage, and it means a service can create value without capturing it. For Enerwise, we designed tokens that are refunded when users switch through our platform, hoping this would give them a reason to stay rather than move to other sites. Now I understand that a business model is not only about creating value, but also about where and how you capture it.

References
Cook, J., Hagiu, A., & Wright, J. (2024). Turn generative AI from an existential threat into a competitive advantage. Harvard Business Review, 102(1).
Rijksoverheid. (n.d.). Salderingsregeling. October 12, 2026, https://www.rijksoverheid.nl/onderwerpen/energie-thuis/salderingsregeling