ProjectHubs: one record of the work, for everyone who touches it
Agencies and delivery teams run projects for clients, and increasingly with AI agents doing part of the work. ProjectHubs is the control plane in the middle: one team-scoped record of every work item, milestone, request and decision. Staff plan from it, clients see the slice that was deliberately shared with them, and agents get executable work orders without ever holding the authority to approve, merge, deploy or close.
The problem
When a team delivers for a client, the truth about the project lives in three places: the tracker the developers use, the deck or spreadsheet the client is shown, and the chat where decisions actually get made. The counts disagree, an approval is a message someone has to find later, and the moment an AI agent starts closing tickets nobody can say who authorised what. ProjectHubs exists because we run engagements this way ourselves and wanted a tool that would refuse to let those three drift apart.
What it does
Every project starts from a template that matches how we sell — Blueprint, Build, Care & Growth — with a named accountable owner. Epics, stories, tasks, bugs, service requests, change requests and subtasks are one record type; backlog, board, saved views and the portfolio are views of it, so a number on the portfolio is the same number on the project screen and links back to the list it came from.
Client governance is a first-class part of the record rather than an export. Client requests are immutable at intake and triaged with an SLA clock; decisions have a log with outcomes and supersession; an approval is bound to the exact revision being approved and requires two-factor and a verified email. The client workspace shows overview, plan, updates, requests and decisions, and nothing marked internal. Comments and attachments are internal by default and shared on purpose.
Agents are delegated identities with per-project capability grants that expire. They can read and draft, and a CLI and SDK let them work a Git-backed ticket on the customer’s own machine or CI. Git stays the source of truth for code; approval stays with a person.
Built with restraint
Every surface — staff panel, client workspace, agent API — goes through the same application actions and policies, so a permission is enforced once. State machines and the authority matrix are held as contracts, not scattered conditionals. Project progress is computed and shown with its calculation basis and freshness, and the client workspace is server-rendered plain HTML on purpose while the domain settles: the styling is the cheap part to change later, the authority model is not.
Where it is today
Pre-release. The foundation, marketing site, work item model and client governance are built and under test; planning, agent identity and the commercial layer are in progress; no release gate has been passed and no pilot client has been chosen yet. It is the tool we intend to run our own engagements in, and it will be offered to clients only after it has done that job for us.
Screens on this page are ProjectHubs running on a seeded demonstration dataset: every team, project, person and work item is fictional. No adoption figures are shown because the product has not been released.
Four screens, one record
Each screen reads from the same project record. Change a work item on the board and the backlog rank, the portfolio count and the client’s shared view all agree without a sync step.
