The Olares Project Ep. 1: Designing an F1-Style AI Agent Race (Blueprint and Setup)

To learn more about the hardware used in this video, click the follow link: https://www.olares.com/ In Episode 1 of The @OlaresOS Project, I finally turn the launch idea into a concrete experiment: an F1-style race where one model is the car and three different AI agents are the “drivers” running on my Olares One appliance. I walk you through the competition system map, the model-serving layer (our “race car”), and the three agents that will be competing, all running on standardized hardware so we can focus on behavior and outcomes rather than raw specs. I show how I used @perplexity-ai to pull a messy idea out of my head and turn it into a detailed blueprint that I’ll eventually publish as a public @GitHub repo once the experiment is complete. We talk through the planned run sequence for each agent—multiple timed runs with “cool-down” periods in between—so the contest is at least balanced, if not perfectly fair, and so we can produce a weighted scorecard once the performance runs are done. From there, I introduce the agent test repository the agents will actually work against. It’s a partially built “engineering factory” agent repo that I’ve been developing over time, which gives us a standardized, realistic codebase instead of toy exercises. I explain what a repo is for anyone newer to software (source control, traceability, safer deployments) and why using an existing, non-trivial project matters for this kind of comparison. I then open up code-server (an open source Codium-style IDE running on the Olares One) and demo loading the repo so you can see the real project structure and the README the agents will be working from. You get to watch some of the very human friction—clicking the wrong “open” option, figuring out folder paths, and stumbling a bit—because this series is about showing the actual wiring, not just the highlight reel. Throughout the episode, I talk about the deeper intent: this isn’t “YOLO coding” or vibe-based automation; it’s about humans supervising agents, reviewing what they do, and even asking them to diagram or explain their own logic so they can catch and fix mistakes earlier. I frame it as part of a broader shift where “business-side” folks like me and “build-side” engineers meet in the middle—using agents as force multipliers while staying accountable for the systems we ship. We wrap by previewing what’s next: wiring the repo into GitLab on the Olares One so all agent-generated changes are tracked, running the actual head-to-head races between the three agents, and then rolling back changes after we review and critique their work. I’m transparent that this is likely my most ambitious, wiring-heavy series yet, and I genuinely don’t know how smoothly it will go—but that’s the point of bringing you along for Episode 1: to share the blueprint, the tradeoffs, and the learning in real time.