Inspiration
Everyone knows the myth: Ariadne hands Theseus a thread so he can find his way back out of the labyrinth. Websites felt like the same problem to me. When you're lost on a site and you ask for help, support tells you what to do "open settings, go to the billing tab" and then you're on your own to actually find it. That's usually the moment people quit. It's worse if you're not comfortable with computers, or you're older, or the interface is just new to you
So the idea was simple: give people a thread. Not another wall of documentation, but something that points at the actual button on the actual page while you're standing in front of it.
What it does
Ariane sits on a website and helps visitors get things done without abandoning them to a FAQ or a ticket queue. You add it with one <script> tag
It chats with visitors in whatever language they write in, and it answers based on the page they're actually looking at. When someone needs to do something, it walks them through it step by step scrolling to each button or field and highlighting it, one at a time. Every step can also be read out loud, and the voice stays lined up with the highlight. The second you finish an action, it stops talking and moves on.
And when someone is genuinely stuck, a real support agent can step in and take over the page, but only after the visitor agrees, and only with a short list of safe actions. Nobody gets silent remote control of your browser.
How we built it
I didn't write the code. I directed an agent that wrote it. The whole thing follows OpenAI's harness engineering idea: the human makes the calls, the agent does the work.
Instead of keeping context in chat, I wrote every decision and constraint into markdown files in the repo, and Codex reread them before each task. If it wasn't written down, it didn't exist as far as the agent was concerned. I broke the project into seven pieces and finished each one before starting the next:
Chat → Widget → Page Mapping → Highlights → Guidance → Voice → Co-browsing
Each piece followed the same loop. Codex read the existing code, built only that piece, showed me the diff, and ran a manual test. Type-checks and builds had to pass before anything moved forward.
I also split the work across two models on purpose. Sol did the building and debugging, because that's the hard reasoning you only pay for once. Luna runs Ariane day to day, where you care more about cost and speed.
Tech stack: TypeScript, React + Vite, Node.js + Fastify, HTTP/NDJSON streaming and WebSocket, OpenAI GPT-5.6 Luna, ElevenLabs for voice, rrweb for the co-browsing prototype, Docker.
Challenges we ran into
The trickiest part was keeping the text, the highlight, and the voice all pointing at the same step. They all read from one sequence, so changing the flow in one place could quietly break the other two. Codex actually spotted that dependency before I made a change that would have desynced everything.
There was also a nasty bug where function calling stopped working. It turned out the tool name was being read from the wrong spot in the OpenAI response stream and Codex traced that itself rather than just patching around it.
Safety took some thought too. The model never touches the page directly. It can only hand back IDs that already exist in a validated map of the page, and the widget checks those against its own copy before highlighting anything. So it can't make up selectors or do anything permanent. On top of that, the OpenAI and ElevenLabs keys stay on the backend and never reach the browser.
Accomplishments that we're proud of
Honestly, the biggest one is that it works, end to end, in about three days chat, page mapping, voice guidance, and a working co-browsing prototype. Adding it to a site really is one <script> tag, with none of the API keys exposed. And the experience actually feels accessible, because it isn't only text: you can read it, see it, or hear it.
Mostly I'm proud that one person steering an agent got this far, on something that would normally need a small team and a lot longer.
What we learned
Writing decisions down as a real contract, instead of leaving them buried in a chat log, made a huge difference in how consistent the agent was. That was the biggest lesson.
The other one surprised me: the agent's best moments weren't writing code, they were catching problems. Spotting the sync issue and chasing that bug through the response stream were both reasoning, not autocomplete.
And splitting work across two models turned out to be the right call rather than a shortcut. Strong model to build, cheaper and faster model to run. Small, testable pieces also kept the whole thing from falling over.
What's next for Ariane
Right now the support agent has to start the handoff. I'd like Ariane to notice when someone's stuck on its own and offer to bring in a human. I also want it to listen, not just talk voice input is the obvious next step
Beyond that: real storage instead of the in-memory setup I used for the hackathon, proper authentication so the co-browsing side is production-ready, and testing with the people who actually need this most
Built With
- codex
- docker
- react
- rrweb
- typescript
- vite
- websocket
Log in or sign up for Devpost to join the conversation.