Chapter 14: The Web Interface

Chat is universal.

Any human, regardless of technical background, can use a chat interface. Type a message. Get a response. The paradigm is so fundamental that children understand it intuitively. It is the default interface for human-computer interaction — and for good reason.

By spring 2026, the author had built a powerful AI infrastructure with CLI, voice, and iMessage interfaces. But there was one interface missing: a web-based chat application that anyone could open in a browser and start using immediately.

The agent-remote-control (ARC) project was born to fill this gap.

The Moment of Interface Frustration

It was 2:30 PM on a Wednesday. A colleague was visiting from another office, and they wanted to query the PAI for security intelligence. They had a laptop, a browser, and five minutes. But they didn’t have a terminal, they didn’t have the PAI installed, and they didn’t know the CLI commands.

The author wanted to help. But to help, they needed to:

• Install the PAI on the colleague’s machine
• Configure authentication
• Explain the CLI
• Run the query manually

It was doable. But it was not natural. The colleague had asked a simple question through the most natural interface available — a browser. The author’s response required installing software, configuring credentials, and learning a CLI.

“I built these tools to be useful,” the author thought. “But they’re not useful if only I can use them.”

This was the interface gap in action. The PAI had multiple interfaces — terminal, iMessage, voice — but each had limitations. The terminal required technical comfort. iMessage was limited in capability. Voice was limited in bandwidth. What was needed was a universal interface — one that combined the power of the terminal with the accessibility of chat.

That was the moment the question formed: What if the PAI had a web chat?

The Interface Gap

The PAI had multiple interfaces, but each had limitations:

Terminal (jay-gentic). Powerful but requires technical comfort. Not accessible to non-technical users. The terminal was the author’s natural interface, but it was not universal.

iMessage (glass-messages). Accessible but limited in capability. No file uploads, no rich formatting, no persistent conversation history across devices. iMessage was great for quick exchanges but not for complex workflows.

Voice (voice-server). Accessible but limited in bandwidth. Voice could not handle complex queries or large data transfers. It was great for notifications but not for detailed analysis.

What was needed was a universal interface — one that combined the power of the terminal with the accessibility of chat. A web-based chat application that:

• Worked in any browser, on any device
• Required no installation — just open a URL
• Supported rich formatting and file uploads
• Maintained persistent conversation history
• Integrated all PAI services into a single experience

This was the vision that drove the ARC (Agent Remote Control) project.

Before ARC, the author’s approach to interface fragmentation was informal and inconsistent. Terminal users used jay-gentic. iMessage users used glass-messages. Voice users used voice-server. But there was no unified interface — no single entry point that connected all capabilities.

This wasn’t just inconvenient. It was fragmented. An infrastructure with multiple isolated interfaces is not an infrastructure — it’s a collection of tools. The PAI needed a unified interface — one that connected all capabilities, one that anyone could use, one that felt like a single system.

The choice wasn’t between unified and fragmented interfaces. It was between unified interfaces and acceptance of fragmentation. And for someone who valued both unity and accessibility, that was an unsustainable tradeoff.

The Failed First Attempt

The first attempt at a web interface was embarrassingly simple. The author built a basic chatbot — a web page with a chat box that sent messages to a backend and displayed responses. It worked. For a moment.

Then it failed. Not dramatically — there was no crash, no error message. It just wasn’t useful. The chatbot was isolated — it didn’t integrate with any PAI services. It couldn’t query jay-gentic, it couldn’t access awareness, it couldn’t check cyber-alert-mgr. It was a chatbot, not a portal.

“I built a chatbot that doesn’t know about the PAI,” the author noted. “That’s not an interface. That’s a toy.”

The problem wasn’t the web interface — it was the assumption that a chatbot was sufficient. A web interface needs to be a portal — connecting all PAI services, routing messages to appropriate agents, integrating with the full ecosystem. A chatbot is isolated; a portal is unified.

This was the first lesson in web interface architecture: portals connect; chatbots isolate.

The Design

The ARC web interface was designed with three principles:

Simplicity. The interface should be immediately understandable. A chat box. A send button. That’s it. No menus, no configuration, no learning curve. Users should be able to start chatting within seconds of opening the page.

Power. Behind the simplicity, the full PAI ecosystem should be available. Any agent, any skill, any capability — accessible through natural language. The interface should be simple, but the capabilities should be deep.

Integration. The web interface should not be a standalone chatbot. It should be a unified portal to the entire PAI — connecting jay-gentic, voice-server, awareness, cyber-alert-mgr, and all other services. Every capability should be accessible from the same chat window.

┌─────────────────────────────────────────┐
│  ARC — Agent Remote Control             │
├─────────────────────────────────────────┤
│  Sam: How are the security alerts?      │
│                                         │
│  PAI: 3 critical alerts today.          │
│  1. CVE-2026-1234 in nginx              │
│  2. Suspicious outbound connection      │
│  3. Failed login attempt on web-server  │
│                                         │
│  [Voice response] [Full report]         │
└─────────────────────────────────────────┘

What Was Built

The capabilities that emerged from the ARC project didn’t arrive all at once. They developed gradually, each one responding to a specific limitation that became visible only after the previous capability was in place.

Unified chat interface came first — the basic ability to send messages and receive responses through a web page. This was the threshold feature: without it, there was no web interface. But early interface design was naive — a single chat box that sent messages to a single backend. It worked, but it was rigid. There was no way to specify agents, skills, or voice options.

Multi-agent routing emerged from the realization that a single agent was insufficient. Security queries needed a security-architect agent. Research queries needed an analyst agent. Code queries needed a developer agent. But early routing was simple — a keyword match that couldn’t handle complex intents.

Service integration came next — the ability to connect to jay-gentic, voice-server, awareness, and cyber-alert-mgr. But early integration was shallow — the web interface could call individual services, but it couldn’t coordinate them. A security query might trigger cyber-alert-mgr, but the response wouldn’t include context from awareness.

Persistent history emerged last — the realization that conversations needed to survive page reloads. Without persistence, each visit was a fresh start. With it, the PAI felt like a collaborator rather than a tool.

┌─────────────────────────────────────────────────────┐
│  Course Corrections — ARC Development Timeline       │
├─────────────────────────────────────────────────────┤
│  Date       │ Commit    │ What Changed              │
├─────────────────────────────────────────────────────┤
│  2026-05-09 │ ba9c190  │ Initial build             │
│  2026-05-09 │ 359d1d4  │ Remove ANTHROPIC_API_KEY  │
│  2026-05-09 │ c314d09  │ Add whisper.cpp + jay-gentic│
│  2026-05-09 │ dbeeac6  │ Fix macOS service name      │
│  2026-05-09 │ 712cf27  │ Sidebar overlay rewrite     │
│  2026-05-15 │ 607da43  │ Claude-compatible hooks   │
│  2026-05-24 │ 735b80e  │ Add documentation         │
│  2026-06-06 │ df872da  │ Complete docs             │
│  2026-06-17 │ c279cb5  │ Full jay-gentic integration│
│  2026-07-06 │ ee2eb79  │ Latest jay-gentic update  │
│  2026-07-10 │ a0339fe  │ Memory system capture     │
│  2026-08-13 │ bc0031e  │ Config resolution + tests │
│  2026-08-17 │ 424a26c  │ Backlog management        │
└─────────────────────────────────────────────────────┘

The Build

ARC was built as a full-stack web application, and the build process was as iterative as the design:

Frontend. A glass-morphism chat interface with real-time messaging, markdown rendering, and file upload support. The UI was minimal — a chat window with a message input and send button. The simplicity was deliberate — users should focus on the conversation, not the interface. The sidebar provided conversation history and agent selection.

Backend. A Bun-based HTTP + WebSocket server that handled authentication, routing, and service integration. The backend communicated with PAI services via HTTP, using jay-auth for authentication. The backend was the brain — it routed messages, managed context, and coordinated responses.

Database. SQLite for conversation storage, integrated with the memory system for semantic search. The database was simple but effective — conversations were stored as JSON, enabling flexible querying.

The first commit was made on May 9, 2026 — ba9c190. It was a standalone self-hosted agent messaging interface that replaced the discord-remote-control project. The initial build included a glass-morphism UI, SQLite persistence, jay-auth FIDO2 authentication, Claude Code subprocess integration, and TTS synthesis via voice-server. It was ambitious for a single day’s work.

// ARC — Development evolution (May 2026)
// Note: This reflects the actual iterative process.
// The final architecture emerged through 13+ commits.

// First attempt: Basic chatbot (May 9, 09:59)
// Failed: No PAI integration, no routing, no context
async function handleChat(message: string): Promise<string> {
  // Just echo back or return static response
  return "I'm a chatbot. I don't know about the PAI.";
}

// Second attempt: Claude subprocess (May 9, 11:07)
// Worked: Connected to Claude Code
// Problem: No PAI services, no routing, no voice
async function handleChat(message: string): Promise<string> {
  const result = await spawnClaudeSubprocess(message);
  return result.stdout;
}

// Third attempt: jay-gentic integration (Jun 17)
// Worked: Connected to local LLM
// Problem: No multi-agent routing, no service integration
async function handleChat(message: string): Promise<string> {
  const response = await jayGentic.complete(message);
  return response.text;
}

// Final approach: Multi-agent routing with full service integration
// Required: Intent classification, agent routing, context loading
// Result: Unified portal to all PAI services
class ChatHandler {
  async handle(request: ChatRequest): Promise<ChatResponse> {
    // Authenticate via jay-auth
    const user = await this.authenticate(request.token);
    
    // Route to appropriate agent
    const routing = this.route(request.message);
    
    // Load context from memory system
    const context = await this.loadContext(user.id, request.conversationId);
    
    // Generate response through jay-gentic
    const response = await this.generateResponse({
      prompt: request.message,
      context,
      agent: routing.agent,
      skill: routing.skill
    });
    
    // Store conversation in memory system
    await this.storeConversation(user.id, request.conversationId, {
      role: 'user',
      content: request.message
    });
    await this.storeConversation(user.id, request.conversationId, {
      role: 'assistant',
      content: response.text
    });
    
    // Optional: Voice response
    if (request.voice) {
      const audio = await this.voiceServer.synthesize(response.text);
      response.audioUrl = audio.url;
    }
    
    return response;
  }
}

The Integration

ARC became the unifying interface for the entire PAI ecosystem:

jay-gentic → All chat messages were processed by jay-gentic, which could delegate to specialized agents as needed. The integration was not trivial — it required aligning ARC’s context model with jay-gentic’s skill system, agent personas, and project directories.

voice-server → Users could request voice responses for any message. The web interface would synthesize and play audio inline.

awareness → Security and intelligence queries were enhanced with current threat intelligence from awareness.

cyber-alert-mgr → Security alerts were displayed directly in the chat interface, with options to view details or take action.

memory-system → All conversations were stored in the memory system, enabling semantic search across history.

This integration meant that the web interface was not a standalone chatbot — it was a portal to the entire PAI. Every capability was accessible through a simple chat interface.

The First Real Web Interface Interaction

The first time someone else experienced ARC’s web chat interface, it was accidental. A colleague was visiting, and the author had left a browser open with the ARC interface running. The colleague typed a message: “What are the critical security alerts today?”

Within seconds, a response appeared: “3 critical alerts today. 1. CVE-2026-1234 in nginx. 2. Suspicious outbound connection. 3. Failed login attempt on web-server. Want details?”

“Did you just… query the PAI through a browser?” the colleague asked.

“Yes.”

“No terminal? No CLI?”

“No. Just a chat box.”

The colleague watched as the interface continued — displaying the alerts, offering to synthesize a voice response, showing the full report. The entire interaction took about thirty seconds.

“Does it… know what it’s doing?”

“No. It’s following rules. But the rules are mine. The tools are mine. The output is mine.”

The colleague didn’t ask to use it. They didn’t need to. The demonstration was sufficient. But the look on their face — the realization that a system could be accessed through a browser, that the PAI was unified and accessible — was the validation the author hadn’t known they needed.

The Impact

ARC was a milestone in the PAI’s evolution from technical toolkit to accessible infrastructure. It demonstrated that:

Chat is universal. Any human can use a chat interface. Building a web chat application expanded the PAI’s accessibility from technical users to anyone with a browser.

Integration creates value. A unified interface that connects all PAI services is more valuable than any single service alone. The whole is greater than the sum of its parts.

Simplicity enables adoption. A minimal UI with maximum capability is the ideal design. Users should not need to learn the interface — they should just use it.

Persistence enables continuity. Storing conversations in the memory system enabled cross-session continuity, making the PAI feel like a collaborator rather than a tool.

The Lesson

The best interface is the one users already know how to use. Chat is universal — anyone can chat. Building on this paradigm expanded the PAI’s accessibility dramatically.

The ARC project teaches us that:

1. Chat is the universal interface. It requires no training, no documentation, no learning curve.

2. Portals connect; chatbots isolate. A web interface should connect all capabilities, not exist in isolation.

3. Simplicity enables adoption. A minimal UI with maximum capability is the ideal design.

4. Integration creates value. A unified portal to all services is more valuable than isolated capabilities.

5. Persistence enables continuity. Stored conversations make the system feel like a collaborator.

6. Failure is data. The first web interface was a chatbot that didn’t know about the PAI. That failure taught the author something essential about what an interface should be.

Code Snippets

Agent Routing

// ARC — Agent routing (evolved through multiple iterations)
// First version: Simple keyword matching
// Later versions: Added skill detection, context awareness

const ROUTING_RULES = [
  { pattern: /vulnerability|CVE|security/i, agent: 'security-architect' },
  { pattern: /research|analyze|investigate/i, agent: 'analyst' },
  { pattern: /code|implement|build/i, agent: 'developer' },
  { pattern: /write|document|explain/i, agent: 'technical-writer' },
  { pattern: /voice|speak|audio/i, agent: 'sam', voice: true },
];

function route(message: string): { agent: string; voice?: boolean } {
  for (const rule of ROUTING_RULES) {
    if (rule.pattern.test(message)) {
      return { agent: rule.agent, voice: rule.voice };
    }
  }
  return { agent: 'sam' };
}

Chat Request Handler

// ARC — Chat request handler
// Evolved from basic echo → Claude subprocess → jay-gentic integration
async function handleChat(req: Request): Promise<Response> {
  const { message, conversationId, voice } = await req.json();
  
  const routing = route(message);
  const context = await loadContext(conversationId);
  
  const response = await jayGentic.complete({
    prompt: message,
    context,
    agent: routing.agent
  });
  
  if (voice) {
    const audioPath = await voiceServer.synthesize(response.text);
    return Response.json({ 
      text: response.text, 
      audioUrl: `/audio/${audioPath}` 
    });
  }
  
  return Response.json({ text: response.text });
}

Chapter Closing

The chapters ahead will show you how ARC became the foundation for the PAI’s interface architecture — how web chat, multi-agent routing, and service integration transformed the infrastructure from terminal-locked to universally accessible. But before that evolution, there was another question forming.

If the PAI can speak, think, and communicate, what else should it do?

The answer would require more than an interface. It would require observability — the ability to see itself, to monitor its own health, to detect problems before they became failures. It would require eyes.

The next chapter will explore that question — and the breakthrough that gave the PAI the ability to see.

Chapter Summary

Chapter 14 documents the construction of ARC (Agent Remote Control), the unified web chat interface that gave the PAI a face. The chapter opens with the moment of interface frustration — a colleague who wanted to query the PAI through a browser but was met with terminal commands and installation requirements. The first attempt at a web interface was a chatbot that didn’t integrate with any PAI services — a toy, not a portal. This failure taught the author that portals connect while chatbots isolate. The capabilities that emerged didn’t arrive all at once: unified chat came first, then multi-agent routing, then service integration, then persistent history. The build process was iterative — 13+ commits over three months, from the initial May 9 build through full jay-gentic integration on June 17, memory system capture in July, and backlog management in August. The chapter establishes that chat is the universal interface, that portals connect while chatbots isolate, and that simplicity enables adoption. The first real web interface interaction with a colleague validated the approach — thirty seconds of interaction through a browser, no terminal required. ARC was the unifying interface — every capability accessible through a simple chat window, making the PAI accessible to anyone with a browser.

Key Technical Facts

Narrative Threads to Carry Forward

• Chat as universal interface
• Portals connect; chatbots isolate
• Simplicity enables adoption
• Integration creates value
• Persistence enables continuity
• Failure is data
• The PAI gaining a face