A multi-project review hub is how I stopped acting as the port switcher for my own AI-assisted projects. Each project can have its own pipeline and small local office for reviewing drafts, but opening every office separately turns a simple approval task into navigation work. This post is a deep dive into Layer 5 of my Cursor workflow: one front door for those offices.
I call my setup PortalHub, or the portal hub. It does not replace the projects behind it. It gives me one place to arrive before I decide what needs my attention.
The problem: N offices, no front door
Several projects create several review surfaces, and that is where the friction starts. An agent may produce and gate a draft inside its own project, while I still need to remember where that project is running and open the correct local URL. The human work is small, but it is interrupted before I even reach the decision.
This is easy to miss when each project is considered alone. A single office with a local URL is simple. The problem appears when video, books, blog, and curation work all have their own offices on the same machine.
Without a shared entry, I keep translating project names into ports. I open one office, return to another project, then search my memory for the next address. That context switching spends approval attention on locating the work instead of reviewing it.
The bottleneck is not always producing another draft. Agents can produce and gate drafts within their pipelines. My limited resource is the time and attention needed to approve what is ready.
I wanted the local setup to reflect that division of labor. Projects should keep doing their own work, while I should have a predictable route to review it. A hub is a small change in shape, but it changes where my attention goes.
The multi-project review hub shape
The multi-project review hub puts one human review point in front of independent project offices. The pattern is simple enough to keep in my head:
- N pipelines produce and gate work.
- N review offices expose that work locally.
- 1 hub gathers the routes.
- 1 human acts as the approver.
PortalHub is the public nickname for this layer. The conceptual name matters because it describes the job: it is a hub for review across projects, not another agent framework. Agents produce and gate; humans approve at the hub.
This layer sits after the work inside each project. My previous cluster post on the AI writing pipeline describes Layer 4, where the pipeline produces and gates content. Layer 5 does not change that pipeline; it lets many projects share one human review front door.
The separation keeps the system smaller. An office remains a small local web UI for drafts and review. The portal hub only needs to know where that office lives and how to send me there.
Slug, port, and a landing page of cards
The landing page makes each registered project visible as a card with a name and short description. I can open the hub, scan what is available, and choose the project I need. I do not have to start by recalling a port number.
Each project has a slug that maps to a local upstream address. For example, the GlobalBlog office runs on port 8406 and is available through the global slug at /global/. The hub forwards that path to the office rather than requiring me to open the upstream address directly.
The registry is deliberately small. Adding a project means adding one entry with:
slugnamedescriptionupstreamenabled
That is enough information for the hub to list the project and route requests to it. I do not need a separate dashboard design for every kind of project. The office owns its review UI, and the hub owns the route into it.
The registry can reload without restarting the hub. That matters because the list of local projects changes over time, while the front door should remain stable. I can register or disable an office without treating the hub as a project-wide restart point.
This is the practical value of a multi-project review hub for my daily use. A project name becomes a visible card and a stable path, not a note about which local port I should remember. The structure stays useful even when the individual project pipelines differ.
Why the proxy prefix matters
The reverse proxy only works cleanly when each office understands that it sits below its slug. PortalHub sends /global/… to the GlobalBlog upstream, so the office must generate its CSS, JavaScript, and links under that prefix. If it assumes it owns /, its assets and navigation can break.
The header that carries this context is X-Forwarded-Prefix. An app that honors it can build paths relative to /global/ while the upstream still binds locally. An app that ignores it may appear to load at first and then fail as soon as an asset or link points at the wrong root path.
I treat this as part of the office contract. The hub does not need to understand each office’s pages. Each office only needs to respect the prefix assigned by its slug.
This constraint also keeps the topology clear. Offices bind to localhost, and the hub is the single entry. The proxy handles routing, while the project keeps responsibility for its own review experience.
Optional shared access control can sit at the hub through a shared access token or session secret. That keeps the approval surface consistent without turning every local office into a different access setup. I still keep the offices local rather than exposing each one separately.
One public entry, offices stay local
Remote access should extend the hub, not turn every office into a public service. When I am outside my desk, I can put Tailscale Funnel in front of the hub to expose a local HTTP service through Tailscale. The offices remain bound to localhost behind it.
This preserves the same path structure I use locally. I enter through the portal hub, choose a project card, and reach the office through its slug. I do not need a separate public route for every project or a different way to remember where each office is.
A public URL still needs a shared access token. The hub is a review entry point, not an invitation to remove access checks. Keeping the access control at that one entry matches the rest of the shape.
The single-entry approach also reduces the number of places I need to inspect when something changes. The projects keep their local upstreams. The hub remains the route I use to reach them.
This does not make remote access the main purpose of the design. The local review problem exists first: several offices should not force me to juggle several addresses. Remote access simply follows the same front-door model.
Wrap-up
Layer 5 gives my projects one review front door while leaving their pipelines and offices independent. The AI writing pipeline handles the production and gate side for content; the portal hub gathers the human approval side across projects.
For me, a multi-project review hub is not a new framework to maintain. It is a small routing layer that gives several local offices one predictable place to start. I can keep my attention on approval instead of remembering ports.