Not Another Agent GUI: Harnesses, Overlays, and Why SybreCore Is the Product
The comparison that keeps coming up
People now talk about “coding agents” as if the app around the agent is the product. Claude Code, Codex, Grok Build, Cursor, OpenCode — those are harnesses. They own the tool loop, the context window, and most of the first-pass code quality.
T3 Code, from Theo and the Ping team, is honest about what it is: an open-source control plane for those harnesses. It wraps the CLIs you already pay for, puts them in a fast UI, and adds threads, git worktrees, checkpoints, and one-click pull requests. The founder’s line is the product contract: T3 is not a harness. It does not maintain context. Coding quality comes from whatever agent you plugged in.
SybreSpace looks similar from a distance. Multiple models. Multiple harnesses. Sessions. Review. Multi-agent. That is why the comparison happens.
It is the wrong comparison if you stop there.
Two different jobs
T3’s job is to run agents well. Sybre’s job is to run a company.
SybreCore is the company system: pages, components, MySQL, Celery, ads, listings, accounting, shipping, whatever jumble of business software you actually operate. SybreSpace exists so any capable model can help build that system without relearning the company every time you switch writers.
If SybreSpace disappeared tomorrow, SybreCore would still be the product. Any harness that can edit a repo could keep working on it. The reverse is not true. T3 without a harness is an empty window. SybreSpace without Core is a factory with nothing to manufacture.
That is the huge difference. Everything else is how we chose to support it.
What T3 actually orchestrates
T3’s architecture matches the slogan. Clients never call Claude or Codex directly. They send typed commands. A server turns those into events. Provider adapters spawn the real CLIs. Complexity stays at the adapter boundary. The UI stays a control surface.
The features that make T3 good are real:
- Parallel threads in one project
- A git worktree per agent so writers do not collide
- Per-turn checkpoints and diffs
- Commit, push, and pull request from the thread
- Remote control from desktop, web, and phone
Those improve operator quality. You can inspect, isolate, revert, and ship faster. They do not try to change what Codex would have written in the terminal.
T3’s MCP surface, at least on the current main branch we inspected, is a preview/browser toolkit. Skills and plugins stay provider-native. There is no shared registry that makes a Sybre skill appear in Claude, Codex, and Grok at once. Collaboration is GitHub. Org memory is whatever each machine and each harness happens to remember.
That is a coherent product. It is also a different category.
What SybreSpace adds on purpose
SybreSpace is also harness-agnostic. Claude, Codex, Grok Build, and the rest remain the writers. The overlay is not supposed to be a second, worse coder.
It is supposed to be the company loop around the writer:
Completion is a platform fact. A session is not done because the model sounded finished. A boundary has to succeed. If auto-review is on, a separate reviewer session approves or sends work back.
Multi-agent is a protocol, not a sidebar of extra chats. Phases, rounds, acceptance, send-back. Later agents cannot silently skip earlier work.
Signpost is memory outside the harness. Prior architecture, session docs, and decisions live in a searchable layer. T3’s position is “we don’t maintain context, the harness does.” Sybre does maintain context, because the harness will compact it away and the next model never saw last month’s contract.
MCP and the skill registry are company tools, not a GUI accessory. Domain tools, directed source lookup, lifecycle boundaries, and skills are defined once and projected onto every supported harness. Switching Grok to Claude should not delete the restart rule, the component standard, or the ads diagnostic.
That overlay can improve first-pass task completion, not only second-pass review. An agent that can find the current contract and call the right company tool produces better Core work than the same model guessing from a cold repo.
The caveat that matters more as harnesses get better
If the overlay is sloppy, it becomes baggage.
Native harnesses are getting very good at file search, shell, subagents, skills, and compaction. Crowding them with a 200-tool catalog, blocking native tools, injecting stale prompts, or making “done” a ceremony will make Claude or Codex worse inside SybreSpace than in their own apps.
The design rule is: supplement, don’t substitute.
Keep overlay for things the harness cannot know:
- Sybre contracts and prior decisions
- Company data tools
- Cross-harness skills
- Lifecycle: complete, send-back, hold, restart
- Independent review when it actually rejects
- Workstreams and model switching
Do not replace the coding loop the labs now win: repo read/edit/shell, native subagents, native compaction.
As harnesses advance, SybreSpace should get thinner at coding and sharper at Core literacy. The winning version is not “a better Claude.” It is Claude, Codex, or Grok left unhindered, plus the Sybre parts those products will never grow.
Shared live tree versus worktrees
T3 isolates agents in the filesystem. Each thread can have a worktree and a branch. Collision is deferred to merge.
Sybre isolates agents in time and process. One shared live main working tree per developer machine. Backend Python runs from that tree. A restart activates code, not a commit. git reset is banned because other agents’ dirty files are on the same disk. SmartSync is the merge agent: commit, pull, push, walk conflicts. You publish when the instance is stable.
That is not because worktrees are unfashionable. It is because verification is live. The files on disk are the FastAPI, frontend, Celery, MCP, and SybreSpace you just asked the agent to change. A throwaway worktree would isolate the writer from the only environment that counts.
T3 optimizes parallel attempts. Sybre optimizes one living system you continuously run and publish.
Org-wide state is MySQL plus SMW, not a tunnel to your laptop
T3’s fleet is personal remote control: drive your Mac Mini from your phone. Theo has said multiplayer does not fit a local-first product unless they add a cloud sandbox. Two developers on T3 are two people with GitHub.
Sybre’s fleet is copies of the same company:
- SMW operates this machine (services, git, credentials, restarts)
- SmartSync publishes
mainfrom a stable host - Fleet apply lets another machine pull and activate without becoming a second writer
- MySQL holds org memory: skills, Signpost, bug ledger, identity, LAN delivery, Share Session snapshots
Share Session is not “join my thread over a tunnel.” It is: package the work on A, deliver it to B, continue on B’s live instance. The org object is the context. Execution stays local.
That only makes sense if every developer PC is a living copy of Sybre, not a worktree of a side project.
SybreCore is the product. SybreSpace is the factory floor.
Component-based business software is the thing being sold. MySQL, Celery, schedules, domain APIs, v1.1 components, and — later — a marketplace of pieces you can install and have agents customize.
SybreSpace is uniquely designed so any model can create those components and understand the system. The overlay, the registry, the live tree, and the fleet exist because Core is a company OS, not because we wanted a prettier Codex.
If the overlay fails, Core can still be built in Claude Code, Codex, T3, or anything else that can edit the monorepo. That is a feature. It tells you which layer is optional.
T3 helps you run agents. SybreCore is the business you are building. SybreSpace is optional infrastructure whose only job is to make every model a Core developer.
Related: One Live Tree — why those agents share live main instead of worktrees or cloud clones.