Vendor clients are designed for the average user. They ship with default system prompts, fixed navigation, pre-selected models, and connection rules you can't change. That's fine if you're the average user. If you're a developer who works across multiple projects, uses multiple models, and needs AI to fit your workflow rather than the other way around — you've already felt the friction.
A command center is not a fancier chat interface. It's a shell — an architecture that gives you control over every layer: which model handles which task, how projects are organized, how sessions are captured and retrieved, which skills get invoked and when. The vendor client is a finished product. The command center is infrastructure you own.
This module is about the shell itself — the navigation layer that makes everything else work. Before you wire up models or build skills, you need a structure: a topbar that orients you, a project switcher that separates concerns, a session list that keeps history accessible. Getting this architecture right at the start means every module you add fits cleanly. Getting it wrong means rebuilding it later.
A developer is working on three active projects: a client API integration, an internal documentation tool, and a personal research pipeline. All three use AI. All three are running in different vendor clients — one in Claude.ai, one in ChatGPT, one in a Cursor workspace.
The problem isn't that the tools are bad. The problem is that there's no connection between them. The context for the API integration lives in a Claude.ai project that's accumulating sessions with no structure. The documentation work is scattered across a dozen ChatGPT conversations with names like "untitled" and "help me write." The research pipeline is better — Cursor keeps file context — but switching between it and the others means losing everything each time.
When the developer needs to reference a decision made two weeks ago, they open three different browser tabs and search. When they want to use a different model for a specific task, they copy-paste across interfaces. When a new team member joins and needs to get up to speed, there's nothing to hand them — just a browser history and a vague set of bookmarks.
The developer has thought about building a custom interface before but assumed it meant months of work. The actual first step is much smaller: design the shell. Not the models, not the skills, not the integrations — just the navigation architecture. Where do projects live? What does a session look like in the list? What goes in the topbar?
Getting this right first means everything built afterward has a place to live. Getting it wrong means rebuilding the navigation every time a new requirement appears — which is what vendor clients do when they ship a "redesign."
The shell of a command center is not a UI decision — it's an architectural one. Where you put things determines what relationships are possible between them. A navigation design that groups sessions by recency makes time the organizing principle. One that groups by project makes context the organizing principle. You can't have both as the primary lens at once, and which you choose shapes every interaction that happens inside it.
The topbar is the fixed layer that's always visible. It should answer three questions at a glance: where am I (project and session context), what model am I using, and what are my global controls (settings, new session, model switcher). Vendor clients use this space for branding. Your command center uses it for state — the current project, the active model, the session name.
Projects are the primary organizational unit. A project contains sessions, system prompts, connected tools, and access rules. Switching projects should feel like switching workspaces — context changes cleanly, the model configuration for that project loads, the session list filters to that project's history. If your project switcher is just a label that changes the chat title, it's not a project switcher — it's a folder.
Sessions are where work actually happens. The session list is how you navigate back to past work without starting from scratch. It needs at minimum: session name (meaningful, not "untitled"), session date, and the project it belongs to. Better is adding: the model used, a one-line summary, and a tag for the session's status (in progress, archived, referenced). The session list is where most command centers fail — they display recency but not relevance.
Systems evaluation means defining measurable criteria for whether a system is working before you build it. For a command center shell, that means: what does "navigation is working" look like? If a developer can find any session from the last 90 days in under 10 seconds — that's a measurable criterion. If the topbar answers all three state questions without clicking — that's measurable. Build the navigation spec with success criteria attached to each component, not just descriptions of what each component contains.
The MAP function asks: what are the failure modes of this system design? For a command center shell, MAP means identifying the navigation failure modes before they occur in production: sessions accumulating with no naming convention, projects proliferating with no cleanup policy, the topbar becoming cluttered as features are added. MAP the shell's failure modes in the spec — not as warnings, but as design constraints that the navigation architecture must address.
Most navigation designs fail not because of bad aesthetics but because of unresolved organizational decisions. Before specifying any component, answer these three questions. All three apply directly in the lab.
A project is not a topic or a folder. It's a boundary around a set of sessions that share context, configuration, and access. Define what makes something its own project rather than a new session within an existing project. The wrong answer isn't "I don't know" — it's "I'll figure it out as I go." If you can't answer this before building, the project switcher will become a list of loosely related items with no coherent structure. Good candidates for project boundaries: a client engagement, a codebase, a research area, a product. Good candidates for sessions within a project: discrete work tasks within that context.
The topbar is always visible, which means every element you put there is rendered on every screen, every session, every state. Be conservative. The minimum viable topbar shows: current project name (clickable to switch), current session name (editable inline), and active model indicator. Everything else — settings, new session, help, notifications — can live behind a menu or in a sidebar. Add topbar elements only when the information they display is needed at a glance on every screen, not just on most screens.
A session that isn't named when it's created will never be named. The command center shell must enforce or strongly encourage naming at session creation — not after the fact. The session list should surface the information that makes retrieval fast: project, date, name, and a one-line summary if available. Design the session list around the search query you'll actually run in six weeks: "that session where I worked through the database schema for the client integration." If the list can answer that query without a full-text search, the design is working.
In the lab, you'll specify the navigation architecture for your command center — answering all three questions and translating the answers into a documented shell design. Apply O*NET Systems Evaluation: attach success criteria to each component before finalizing the spec.