Navigation, workspaces, and search
How to move around Disco Parrot. Three areas, permission-aware navigation that hides what you cannot see, project switching that does not reload the page, and an activity hub a click away from anywhere.
A product that does as many things as Disco Parrot has to be navigable without becoming overwhelming. The answer the platform settles on is a small, opinionated shell: three areas, a collapsible side rail of sections inside each one, a project switcher in the header for cross-project work, and a workspace switcher for the people who belong to more than one workspace. Everything else (the activity hub, the notifications inbox, the chat panel) layers in from the right when you need it, and disappears when you do not.
Three areas, on purpose
Disco Parrot splits the product into three areas that match the three kinds of work people do in it.
SDLC is where the work itself lives. Initiatives, plans, bugs, sprints, projects, portfolios, goals, the grid, the board, the roadmap, the Ask conversations, the Sessions index. This is the area you are in most of the time. The route is /planning for historical reasons; the side rail's tab is what users see and what the rest of the docs call this area.
Platform is where the infrastructure lives. Sandboxes, sandbox profiles and hosts, environments, repositories and repo providers, integrations, MCP configurations and the catalog, AI models and SDK configs, skills, agent instructions, workflows, Flows, and the audit log. This is the admin area, and most users land here only when they need a setting an admin has not configured yet.
Settings is where your personal preferences and your workspace administration live. Your profile, your notification preferences, your secrets. The members and teams and roles for the workspace, the workspace's plan and usage, the activity feed of recent admin events.
The three are reached from the side rail. The shape of the rail (an app picker plus the sections of the currently active app) keeps the chrome small while giving you a way to switch areas without losing context in the one you came from.
The nav hides what you cannot see
The side rail is not a static menu; it is permission-aware. Every section in it carries the scope you need to read what is inside, and the rail filters out anything you cannot reach. A reviewer who can read plans but not sandbox profiles sees Plans in the rail and does not see Sandboxes. An engineer on the smaller plan tier does not see the autonomous-flow area because the entitlement that unlocks it is not on their account.
This is not just a UX nicety. It is the same model that gates the API: if you cannot reach a route through the rail, you cannot reach it through a copied URL either, because the server checks the same scope. The rail is the visual surface of an access-control model that runs end to end.
The rail also collapses. Drag it to 56 pixels wide and it shows icons only; expand it back and the labels return. The collapsed state holds across sessions so a user who prefers a tight chrome gets it without having to set it every time.
Workspaces and projects, two different switchers
Disco Parrot uses workspace to mean the org-level boundary that contains your team, your billing, and all your work. A person who belongs to two workspaces (a contractor working with two clients, an engineer on personal and employer accounts) switches between them from the user menu in the top bar.
The project picker is a different control. Projects are the cross-cutting context inside a workspace; a workspace usually has several projects, each holding its own set of initiatives, plans, and bugs. The project picker lives in the side rail header and lets you switch the active project without leaving the page you are on. The grid, the board, the roadmap, and the chat panel all update to reflect the new project's records. There is no page reload; your scroll position holds, your chat panel stays open if you had one, and the next page you navigate to opens against the project you just picked.
The cost of getting these two concepts mixed up is small, but worth knowing. You change the workspace when you are working on a different organization's work. You change the project when you are still in the same workspace but want to look at a different part of it.
The active project is sent on every API call as a header, not as part of the URL path. That means a link to an initiative resolves the same regardless of which project you have active locally; the platform reads the link's initiative id and the request's workspace from your session, finds the project the initiative belongs to, and renders it. Switching the project picker after opening a link does not change the record you are looking at.
Three surfaces share the right side
The right side of the page is shared by three panels that you can open over whatever you are reading. Knowing which one is which saves you a click.
The chat panel
This is the one you spend the most time in. It opens when you start a chat against an initiative, a plan, or a bug, and it stays open until you close it. The conversation history is on the right; the record you were reading stays on the left. You can keep scrolling the record while the agent works on it in the panel.
The Command Center
The activity hub you reach from the top-bar button. It slides in over whatever was on the right, including a chat panel if you had one open. Close the Command Center and the chat panel returns. Use it to switch between several pieces of work in flight without losing the chat you were just in.
Quick View
The third right-side surface, the peek-a-record modal that opens when you click a row, a card, or a roadmap bar. It overlays the list you were reading and closes back to it on Esc or click-out. The list, the chat panel, and any Command Center state behind it all stay where they were.
How they stack
The three never fight for space. Opening one closes the others, and the platform remembers where you were so closing the new one returns you to the old one without losing context.
The top bar, briefly
The top bar above the side rail is intentionally thin. A logo on the left that takes you back to the SDLC home, a spacer, and on the right four controls in a row: the activity button, the notifications bell, the Settings shortcut, and your user menu.
The activity button
This carries a badge with the count of work currently in flight. Click it and the Command Center slides in from the right with every chat, Flow run, and background task that is in motion. The button is visible on SDLC and Platform pages; Settings does not show it because Settings is where you go to configure, not to work.
The notifications bell
A separate system from the activity hub. Notifications tell you that something happened (a comment, an assignment, a status change, a Flow that finished while you were away) regardless of whether you set the work in motion. The bell carries an unread count; clicking it opens an inbox where you can read each notification, mark it read, archive it, or jump to the record it is about. The categories it covers, the channels it can reach you on, and the preferences behind it are all in Notifications.
The Settings shortcut
The fastest way into your personal preferences, notification rules, and the workspace admin area. It is the same place you reach by clicking the Settings entry in the side rail; the top-bar button is there because most paths to Settings are short.
The user menu
Your account control. Sign out, switch to a different workspace (if you belong to more than one), open your profile, see your active session list. The menu is also the place a person with two workspaces lives: an engineer on personal and employer accounts switches between them here, the page reloads against the new workspace, and the rest of the app is now reading the new workspace's data.
Searching across the product
Search in Disco Parrot is per-list today. Every grid carries a search field at the column-filter row that does a substring match across the entity's searchable fields (title and summary on initiatives, title on plans, title and description on bugs). The Ask page carries its own search across saved answers and recent conversations. The Sessions index is searchable by initiative, plan, kind, and owner.
The point of per-list search is that you do not have to remember which entity a record is, you just have to remember which list to be on. The grid you want is usually one click in the side rail; once you are there, the search field takes you the rest of the way.
Saved answers and recents
The Ask page in SDLC is the home for the agent-answered questions you have asked across the workspace. Pinning an answer (the kebab menu on an assistant message) saves it to your Saved tab so you can find it again without scrolling through history. Saved answers are per-user, not per-workspace; what you save is yours to organize.
The Command Center is your recent-activity surface; the Sessions index is your searchable history. Between the three (Saved, Command Center, Sessions) you can find anything you have asked the agent to do, anything that is in flight, and anything that finished recently, without having to remember where it ran.
Every record has an address
Almost every surface in Disco Parrot lives at a stable URL. An initiative has a URL. A plan, a bug, a sprint, a Flow run, a Sessions filter, a sandbox profile, a workflow editor: all of them. A filtered list of bugs assigned to one engineer and sorted by severity is a URL too, because the filter and the sort encode into the address bar (the Built for query page covers this in full).
The practical effect is that the work is bookmarkable. Pin the link to a project doc and the doc still resolves next quarter. Send it in your team chat and the recipient opens the same view you were looking at. Tab through five initiatives by cmd-clicking each one. The URL is the saved view; you do not have to invent names for queries you want to keep.
Refreshes work too. A long URL with a filter and a sort and a record open in Quick View on top of it reloads to the same state. Tabs open in new browser windows reload independently. The product behaves the way the web behaves, on purpose.
Keyboard shortcuts, briefly
A workspace-wide command palette (the press-a-key-from-anywhere kind, the ⌘K shortcut other tools have wired up) is not shipped today. For now, the right move is to navigate to the area you want and use that area's surfaces. The structure of the product (three areas, sections inside each, stable URLs everywhere) keeps the path short enough that the trip is rarely more than one or two clicks.
Browser-native interactions work the way you expect. Cmd-click anything to open it in a new tab. Right-click for the browser context menu, including "Copy link." The address bar is searchable from any URL you have visited before. The page does not steal these from you.