Infragility Web Site: Building a Real-Time Agent Interface Before the Agents Were Real
Dashboards often look finished long before the systems behind them are finished. That gap interested me. I wanted to explore what an interface for AI operators could feel like before a complete agent runtime even existed, and that pushed this project into a strange middle ground between prototype, product mock, and systems experiment.
The idea centered on interaction, not pages. Chat, project tracking, optimization requests, live status. The harder problem was making those pieces feel coherent when much of the backend was still simulated.
Designing Around a Bridge
The most interesting decision was not in the Next.js frontend. It was using a bridge server connected to a Discord bot as the communication layer. It sounds unusual because it was. But it let me test asynchronous agent workflows without building a full agent backend first.
I paired HTTP requests with WebSocket updates, then added a FIFO request queue to match responses coming back from the bot. That was the part I cared about most. Not the chat UI. The behavior under latency.
The frontend was mostly TypeScript, Tailwind, and shadcn style components, but a lot of effort went into handling edge cases. Duplicate responses. WebSocket fallback. Connection state. Small things that make interfaces feel less brittle.
Building a Dashboard That Admitted It Was a Prototype
A lot of the project is intentionally honest. The analytics data was mocked. Project tracking was hardcoded. Some routes were placeholders. I did not want to fake maturity where there was none.
What mattered was testing a few ideas:
- Real-time agent interaction should degrade gracefully when live channels fail
- A services dashboard can feel operational before every backend system exists
- Interface trust often comes from handling failure well, not from adding features
That shaped things like status indicators, loading states, and the optimization request flow more than the visual design did.
What Broke Or Felt Incomplete
Some choices were clever but expensive. Discord as middleware was useful for experimentation, but I would not keep it as the long-term architecture. It adds operational complexity and too much dependency around something that should probably be a dedicated runtime.
Some implementation details were rough too. The charting was basic. Form validation could be deeper. The projects endpoint returning empty data always bothered me because it exposed where the illusion ended.
I would also handle secrets very differently now. Some environment handling was not where I would want it in a production-grade system.
What I Learned
I learned that building around uncertainty changes how you architect software. You stop optimizing for ideal flows and start optimizing for incomplete systems. That was the real lesson here.
The project looks like a frontend showcase on the surface. For me it was really about message routing, fallbacks, and what happens when software needs to feel reliable before it fully is.
Sometimes the prototype teaches the architecture before the product exists.