My role in the team
In our team of four I had two roles: organising the project and building the prototype.
At the start, I suggested that each of us bring two ideas to the first meeting, so we could choose from eight options instead of going with the first idea someone mentioned. That is how we arrived at HomeMatch AI: an AI agent that helps home seekers find a home by understanding their wishes in natural language and ranking and explaining matches.
Once the idea was approved, I made an overview of everything the deck required and turned it into a task division. I shared the list, asked whether everyone agreed, and let each person choose their tasks, so the workload felt fair and everyone owned their part. I also made a planning with deadlines per task, because the order mattered: the evaluation depended on the prototype, and the recommendation depended on the evaluation. At the end we reviewed everything together, and I did the final check of the deck.
My main content contribution was the prototype, with its slides and appendix. As a business student, I had never built an AI agent. I started by watching YouTube videos on how to create an agent in Claude, then built it without code. For the evaluation, I ran the HomeMatch side of the tests together with a teammate, who did the manual search and made the evaluation slides.
Key decisions and iterations
My first real decision was about where to put my time. My instinct was to make the prototype look as complete as possible. Rereading the rubric changed that: technical sophistication earns no marks, evidence does. So I asked myself which parts had to be real to test our key assumption, that HomeMatch finds more relevant homes faster than manual search, and which parts I could simulate. I made search, ranking and explanations real, and simulated agency registration and notifications. That kept the prototype focused.
I also had to decide how much the agent was allowed to do on its own. Letting it register seekers or apply for them would have looked impressive in a demo. I chose the opposite: the agent asks permission before using personal data and never applies or bids. I realised that trust, not autonomy, was what set our product apart, and I wanted the prototype to show that.
My way of working changed too. At first I fixed problems as they came up. After a few versions I lost track of what I had changed and why, so I designed personas specifically to break the agent. That turned random fixing into real iteration: each failure led to one rule, tested before moving on. I also learned that one change could break something that already worked. Fixing one problem sometimes broke something that worked before. So, after every change I retested all personas, not just the one that had failed, until I froze version 1.19.
What surprised me and what failed
My biggest mistake was how I handled the live search. The search ran, but it kept returning listings that were no longer available. I assumed the problem was in my prototype, so I spent a lot of time rewriting instructions and trying new approaches to make it work. None of it helped. Eventually I understood why: the agent relies on web search, which returns pages indexed earlier, and the platforms do not give outside tools access to their live data. The problem was not my prototype but access to data. Looking back, I should have stepped back sooner and asked whether the problem was mine to solve. That insight did become useful: I used it in our recommendation, where I argued that licensing agreements with agencies are necessary before launch.
The second failure was the public link. Live search only worked inside my own Claude account; the published link did not run it. This caused me a lot of stress, because I believed the link in the deck had to work for us to pass. When it could not be fixed, I included a public link that shows what the prototype looks like, and explained on the slides why the live version only runs inside Claude. In hindsight, I think being open about it was better than a workaround.
How feedback changed the work
The most difficult moment came from within the team. A teammate copied only my agent prompt into Lovable and reported that live search worked there. By then I had already built the whole app in Claude. Instead of dismissing the suggestion, I tested it myself. I downloaded the HTML file of my Claude app and uploaded it to Lovable, so I would have the exact same app there. My tokens were used up immediately: I had a paid Claude account, but not a paid Lovable account. It turned out that live search worked on a free Lovable account with only the prompt, but the full app exceeded the free token limit. Since the app was built in Claude and worked fully there, except for live search through the public link, we decided to keep it in Claude. This taught me to test a claim before reacting to it, and to explain a decision with evidence rather than defend my own work.
What I learned
From the collaboration, I learned that structure creates fairness. Asking everyone to bring two ideas meant each person had a voice from the start. The sequential planning also showed me how dependent we were on each other: each task built on the previous one, so clear deadlines and handover moments mattered more than I expected. Working closely with a teammate during testing taught me that dividing roles within one task, one running the prototype and one doing the manual search, works well as long as you do it side by side.
How my understanding of AI and strategy changed
Before this project I saw AI as the product. My own experience changed that. I had never built an agent, yet with a few videos and no code I had a working one within days. If I can do that, so can any competitor. That made Teece’s (1986) argument concrete for me: when technology is easy to copy, value goes to whoever controls the complementary assets around it.
The Lovable episode taught me the same thing from another angle. The same prompt worked in two different tools. The model was replaceable; what mattered was everything I had built and tested around it.
The live search failure made the ecosystem theory real. Reading that whoever controls the bottleneck captures the value (Jacobides et al., 2018) is one thing; spending days trying to fix a problem that only the platforms could solve is another. I now see access to data, not intelligence, as the real constraint for agents that act for consumers.
I think the biggest lesson is that building an AI prototype is now accessible to anyone, even without coding skills. The strategic work is deciding what to test, what the agent may do on its own, and who controls what it depends on.
References
Jacobides, M. G., Cennamo, C., & Gawer, A. (2018). Towards a theory of ecosystems. Strategic Management Journal, 39(8), 2255-2276.
Teece, D. J. (1986). Profiting from technological innovation: Implications for integration, collaboration, licensing and public policy. Research Policy, 15(6), 285-305.
