Mobile AI Chat: A Two Shell Panel Architecture

Mobile AI chat architecture is the layout and logic that runs a chat app on a phone. Most apps just squish their desktop design onto a smaller screen.

That approach functions, but the feel is off. You get a hidden menu for your chats, every screen takes over the whole display, and switching views means a full reload that loses your place. It technically checks all the boxes, but the experience is poor. We built ChatFuse for mobile a different way.

Below 767 pixels wide, the site switches to a panel stack. Here's how we built that system and what it costs to run.

What is the ChatFuse mobile panel stack?

The ChatFuse mobile panel stack works the way your phone's apps do. It's a series of full screen panels, each one sliding in from the right. It sits on top of where you just were, and you swipe back to return. It feels like a deck of cards, not a bunch of separate pages.

Chats, Library, Projects, Personas and Tools all live as their own panels. Tap on a list item and it pushes a fresh panel onto the stack. A swipe removes it. You already know how this works from other apps, so there's nothing new to figure out.

Does the URL still change?

Yes. The address bar updates with history state, not a page load, so your links still work and React doesn't lose its place. Getting that right is the hard part of building a panel stack, because the URL and the open panels have to match up every single time.

You don't get a full page refresh during a session. Moving around keeps your scroll spot, any open sheet, and that message you were still writing.

What is the two shell part of ChatFuse mobile?

Below 767 pixels, ChatFuse mobile loads one of 2 completely separate React trees, and the URL is what picks which one you see. One tree is for the dashboard, and the other one handles the chat view. They're not just different versions of the same thing.

The dashboard shell runs the panel stack, holds the top bar, and puts the floating action button and bottom sheets on screen. The chat portal is built around its sidebar for all the navigation.

We decided to split them up on purpose, and that comes with a price: anything they both use has to work right in each place. But we get something for that. Now neither side has to check which app you're in before it does something, and the chat part gets to feel like a chat, not a menu. The canvas route, which is where you'll find our live AI document editor, is part of the dashboard.

What breaks when you add a new ChatFuse route?

Adding a new route will break deep links and page refreshes unless you also add a matching case to the function that builds the panel stack from a URL. It isn't enough to just put it in the dashboard list. Without that case, the route works fine when you click into it, but it fails completely if someone opens it directly.

The problem shows up when someone loads the page from scratch, because that process tries to rebuild the navigation stack from the URL and gets it wrong. That specific path almost never gets tested manually while you're building something. This bit us a few times, so we made it a written rule instead of just something we all knew.

Why 767px and not a device size?

We picked 767px because device screens come and go, but a layout breakpoint is our call. Mobile kicks in at that max width. That one number feeds through a single hook, so nothing checks the window on its own or sets its own media condition.

It's just practical. If 2 parts of the interface disagree on what 'mobile' means, you end up with a layout that's broken in half at one exact width. That's awful to fix.

We do the same thing for z-index, touch target sizes, animation speeds, and panel widths. They all live in one constants file. Putting a raw pixel value inside a component is a bug.

How do ChatFuse modals work on a small screen?

On a phone, ChatFuse modals show up as bottom sheets. On a desktop, they're centered dialogs. The component picks the right one by itself. This matters if a modal has a set width or attaches itself to the root document, since both of those can break on a small screen.

A fixed width box just doesn't fit on a narrow display. And if a component portals out, it can end up drawing over things it shouldn't or getting hidden behind them.

Is this just a mobile web wrapper?

No. It's built into the browser and the native shells together, so you get the same feel in a tab or the installed app. Swipes, how panels move, and how sheets work all come from one place. We didn't build them twice.

What does this cost to maintain?

Maintaining this setup runs a lot higher than a basic responsive layout. The real cost sits in the panel checks. Every component needs to be tested twice: once on its own and again inside every type of panel shell, because something can look fine alone and still break completely when it actually renders in place.

An L2 detail panel adds its own scroll container and a header. That's where the problems usually happen. The real question for review isn't just if the component works. It's about which shell pulls it in and what level of the stack it lands on.

Does the desktop layout change too?

No, the desktop layout doesn't change. The panel system only activates below the 767px breakpoint. Above that, it stays completely off. This way, the mobile and desktop versions can each get updated on their own. One doesn't risk breaking the other.

What does a shared component have to survive?

A shared component needs to work in 3 different spots. It could be the main list, a detail view that slides over that list, or a panel that floats above everything else. Every one of these positions has its own scrolling behavior and header rules. The component itself has to handle all of them correctly.

An L1 list takes the whole screen and scrolls itself. An L2 detail view goes over it, has its own scroll and a back button. A sheet pops up on top of everything and you can drag it off. Now, some components think they're the only thing that can scroll. That works fine for the L1 list. But put that same component inside an L2 or a sheet and it breaks, because it tries to put a new scroll area inside an existing one. It's a nightmare to explain in a bug report, but you see it instantly when you use the phone.

So for every piece that fits into these shells, you have to ask where it's going to show up. Saying it works in just one spot is exactly why the other 2 end up with problems. This idea of checking every single route, not just the one you took, is the same thinking behind multi agent QA testing.

Is a panel stack better than tabs?

Yes, we went with a panel stack for ChatFuse instead of tabs because our content has a deep structure. Tabs are fine when you've got 4 or 5 spots that are all on the same level. A catalog that goes from categories to items to details is a hierarchy, and a stack just honestly shows that shape on a mobile screen.

How do I see ChatFuse mobile AI chat?

Open ChatFuse on your phone or shrink your desktop browser to under 767px wide, and the view shifts to the mobile layout. It's the same full product, your chats, tools, and projects, now laid out as a swipeable panel stack. ChatFuse gives access to more than 100 AI models from OpenAI, Anthropic, Google, Meta and others.

Create a free account to try it. You can learn how we route requests between models in AI model orchestration, or get a full look at the system inside the ChatFuse AI orchestration platform.