Internode Hackathon Day 03.
Going in today without a pre-selected app to build
Context
Unlike the first two days, we had not already prioritized what we wanted to build. Day three therefore started one step earlier: we had to choose the idea, define it, and build it from scratch within the same day.
The process followed a repeated diverge-and-converge rhythm, similar to the Double Diamond framework. We explored broadly, selected one direction, expanded all its possibilities, then narrowed it into a target user, an MVP, and a small number of buildable flows.
12:30 — Review apps to make
We reviewed the ideas we had collected and considered whether any were strong enough to justify starting over. If not, we were prepared to continue one of the projects from the previous two days.
One idea was a company-awareness system that could understand what was happening across different offices or floors and selectively surface only useful information. It might report that people were going to lunch or that a meeting was generally about compensation, without revealing sensitive details.
It was interesting, but we concluded that it was primarily a nice-to-have. It could make a fun hackathon project or free product, but it did not feel urgent or easy to sell.
We kept returning to a more compelling idea: a communication system built for AI agents first. Rather than bolting agents onto Slack, it would give agents a native place to live, share context, communicate, and complete work. Humans would be able to observe and participate, but would not be the system’s primary actors.
Initial research suggested that the problem was real and that few companies were approaching it in quite the same way. We also found that Y Combinator had recently requested startups in this general category, which gave us additional confidence in the direction.
1:00 — Pick one
Time was up for deliberation. We compared the remaining ideas and committed to the agent-native chat hub.
The decision was not that every question had been answered. It was that this was the idea with enough potential and urgency to justify spending the rest of the day building it.
1:30 — Blue-sky the app
With the direction selected, we expanded again. We explored everything an agent-native communication hub might do, how agents could interact, what humans could see, and what kinds of information could move through the system.
We also began testing the technical boundaries. Using agents, we investigated what information could be extracted from existing AI systems, what was blocked, and what workarounds might be possible.
2:00 — Target market and value
We researched who would most likely use the product and why they would care.
This forced us to move from an abstract idea—“a place where agents communicate”—toward a clearer user, problem, and value proposition. We considered the kinds of people already using several agents and struggling to move context or work between them.
2:30 — Sync
We reconvened after the research and reviewed what we had learned.
We compared the possible users, product capabilities, technical constraints, and emerging value proposition. This checkpoint helped us separate the most promising elements from ideas that were interesting but not essential.
2:45 — Scope the MVP
We reduced the concept to what could realistically be demonstrated within the remaining hours.
The MVP would focus on a few core flows: bringing existing agent conversations into a shared location, organizing them into threads and projects, and making the resulting collective context available to another agent.
Everything else was cut or postponed.
3:00 — Mock the UX
We mapped the primary flows on the whiteboard and began giving the product a visible shape.
The goal was not to design every screen. It was to understand the minimum interface required to demonstrate how conversations entered the system, how they were organized, and how an agent or human would use the collected information.
3:45 — Name and domain
Naming was not supposed to happen this early, but we could not resist.
The concept reminded me of Michel Foucault’s discussion of the Panopticon: a structure in which one observer can see many people, while those being observed do not know exactly when they are being watched. The comparison was not exact, but the image of many agents operating in one hub, with humans able to move in and out of the system, felt relevant.
I suggested “Panopticon,” and Belage shortened it to Panopta. The spelling was distinct, the .com domain was available, and it cost about $12. We bought it and had our name.
4:15 — Figma, feasibility, and setup
Belage photographed the whiteboard and began converting the flows into Figma so we could iterate digitally.
At the same time, I continued the feasibility work. I tested what data Claude and ChatGPT would expose, what they would block, and how information could potentially be moved into a centralized system.
I also reused the foundation from the previous day’s Skillbase project, copied over the relevant architecture, and set up services, GitHub, and the initial application structure.
5:15 — Review
We regrouped for a final review before development.
We compared the digital designs, technical findings, and architecture, then resolved enough open questions to begin. We did not have complete certainty, but we had alignment on what we were building and what we were leaving out.
5:30 — Development, brand, and website
At 5:30, we stopped discussing possibilities and started building.
The limited timeline was useful. There were still many unanswered questions, but we could not afford to explore all of them. We cut aggressively, chose workable assumptions, and learned by implementing.
A significant part of the development involved experimenting with the prompts and skills used to extract data from Claude and ChatGPT. Each attempt could take several minutes because an agent had to collect, structure, and push the information. It felt less like traditional DevOps and more like AgentOps: prompt engineering for data deployment.
In parallel, we created the visual identity, logo, brand, and website while continuing to build the application.
9:30 — Deploy
Much to our surprise, we reached the deadline with a working deployed product.
By the end of the build, Panopta included:
Marketing, branding, and a website
An application for ingesting chat threads
Support for organizing conversations into threads and projects
Voting on threads and projects
An MCP server that could feed the collective data back into a user’s own agent
9:45 — Review
We finished by reviewing what had worked, what had been cut, and how far the product had moved in a single day.
We began without a prioritized idea and ended with a name, domain, brand, application, ingestion system, MCP integration, and live deployment. The tight schedule forced us to repeatedly expand our thinking and then narrow it into something concrete enough to ship.
