- Built for
- My own practice
- Role
- Product creation, AI systems design, security, and full-stack build
- System
- TypeScript, Hono + WebSockets, React 19
- Where it stands
- Private, and in use on my own repositories.
I did this to myself first.
The work I want to do for clients starts by watching how a team already operates and finding the parts that are expensive in ways nobody has counted. Then I build the specific thing that removes them. AI Workspace Hub is that process pointed at my own desk, which is the only reason I can show you every part of it.
It started with me copying a prompt out of one app and into another for the fourth time in a morning.
The work was scattered across the tools that did it.
My projects had come to depend on several AI tools at once. Each one was good at its own job and completely unaware of the others, which left me as the integration layer between them, doing it by hand.
Whatever crossed between them, I carried.
One history, and one set of rules about what may touch a repository.
- Context
I re-explained the project every time.
Handing a task from one model to another meant describing the codebase again from scratch.
- Continuity
Three projects meant three terminals.
Finding what an agent did last Tuesday meant remembering which window it happened in.
- Visibility
I could only watch a job from the desk that started it.
Long runs were the ones I most wanted to check on from somewhere else.
- Diagnosis
When a workflow broke, I could not tell which stage broke it.
Several agents cooperating on one piece of work is useful right up until something fails, and nothing could answer which one.
What I built, decision by decision.
Each of these six decisions answers something that had been annoying me at my own desk.
I wrapped each agent's command line instead of rebuilding its app.
ProvidersA provider contract normalizes every agent's streaming output into the same events. When DeepSeek arrived, supporting it was one adapter file.
I made the project the unit of work.
ContextA thread stays attached to its repository. When the provider changes mid-thread, the Hub replays the conversation so far into the new session.
I gave the agents names and job histories.
IdentityOperators persist, each with a role and a record of what it has run. I dispatch Foreman to the storefront instead of picking a model and describing the job again.
I made the feed survive a dropped connection.
StreamingJob events persist with monotonic sequence numbers, and the socket protocol is subscribe, replay, then live. Lock the tablet mid-job and the feed backfills instead of showing a hole.
I kept the last decision for myself.
ReviewWritable agents work in disposable Git worktrees. What comes back is a patch bound to a reviewed hash, and applying it is something I do on purpose.
I put the whole thing behind loopback and an authenticated tunnel.
BoundaryThe origin never binds to a public interface. Coding agents also inherit a minimal environment, so an agent can build all day without ever seeing the credentials the platform itself uses.
The product has three parts.
- Multi-model projects
One project runs on more than one model.
Models are good at different things, and a thread survives the switch between them. When one model hands work to the next, the Hub writes this line to the log:
↔ handoff from claude: replayed 4812 chars of context into a fresh codex session
- Visible agents
I can see what the agents are doing.
Every operator has a name and a status I can read from across the desk. I built a separate Content Studio tab for the social agents once, and it worked fine while splitting the product into two places I had to remember to check. I deleted it and moved those three agents into the room with everyone else.
- Workflow orchestration
Coding, research, and content start in the same place.
A saved webhook operator posts to any HTTP endpoint, which is how an n8n or Zapier workflow joins in. I wanted one surface that could send work out and account for what came back.
The Agent Room shows every operator in one view.
An agent working in the background is a log file at best, and I could never tell at a glance who was busy or who had stopped. This is a real linked workflow, one stage at a time, including the part where one of them fails.
The sequence, in order:
- Dispatch. Foreman takes the storefront job. One operator, on a job small enough to review in one sitting.
- Handoff. Lattice picks up where Foreman stopped. A different provider, carrying the same conversation.
- Fault. The linked job on helios-api fails. The room shows which stage broke.
- Review. Two patches are waiting for me. Nothing has touched the real repository yet.
I follow one piece of work from thought to merge.
Seven steps, and I never leave the window to do any of them.
- 01
Select the project
Work starts from a registered repository, so everything after this inherits its context and its rules.
Projects - 02
Work with more than one model
Claude, Codex, and DeepSeek take turns inside the same thread.
Thread - 03
Carry the context forward
A provider change replays the conversation into the new session and logs how much it carried.
Thread - 04
Dispatch an operator
A persistent agent takes the job, or several take linked stages of it.
Agent Room - 05
Track the job
Events stream with sequence numbers, so the feed backfills after a dropped connection.
Live feed - 06
Read what came back
The diff, the summary, and the reasoning arrive together.
Git review - 07
Decide
Apply, revise, dispatch again, or throw it away. This step is mine, and the system has no path around it.
Git review
Four layers sit inside one security boundary.
I drew that line myself, and everything the product does happens inside it.
- Operator interfaceWhat I touchProjectsMulti-model threadsAgent RoomJob reviewResearch and workflow results
- CoordinationWhat the Hub ownsProvider routingPersistent contextJob queueReal-time eventsAgent identitiesReview state
- ExecutionWhat does the workClaudeCodexDeepSeekResearch agentsContent agentsHTTP workflows
- Protected workWhat must not be damagedRegistered repositoriesIsolated worktreesAgent workspacesState storeArtifactsVerified backups
- Access
- Private origin, exact single-operator authorization, failing closed
- Network
- Loopback binding, an authenticated tunnel, constrained outbound requests
- Process
- Minimal child environments, so an agent never inherits the platform's credentials
- Consequence
- Protected paths, and human approval before anything is applied
I kept apply as a human step.
I had to decide what happens to generated code before a human has looked at it, and I settled on one mechanism for it.
I build the system around your work.
The Hub is specific because it was built around one person's actual habits. Yours would be specific to different habits, and finding out which ones is the first half of the job.
That is the order this project happened in: the friction first, then the build. It is the order I would want to work in with you.
The record behind it: 131 tests across 25 files, a store benchmarked against 10,000 simulated jobs and 100,000 events, and a migration path that rehearses on a copy, comparing row counts and foreign keys before the live database is touched.