The workspace is the context window - why agents work better unified

The engineering thesis behind Rezee's agent bet - an agent in a unified workspace gets context, permissions, identity, and a safety gate as properties of one system, each measured in a sibling post, where a stitched stack rebuilds all four per integration.

Jul 3, 2026 · 7 min read · Kash Gohil

Rezee is one workspace for the whole product development lifecycle - code, planning, CI/CD, chat, and docs - built for teams and their agents. Across a cluster of engineering posts we've built the pieces of that agent story separately: identity, the tool surface, scoped permissions, the approval gate, unified search. This post is the argument that ties them together, and it's a specific, falsifiable one: an agent is only as good as its context and its guardrails, and both are properties of the workspace, not the model. A better model helps; a unified workspace is what lets you safely hand that model real work. Everything below is backed by a number from a sibling post, because a thesis about engineering should be measured, not asserted.

The claim, precisely

An agent doing real work needs four things that have nothing to do with how smart the model is:

Context - the issue, the spec, the discussion, the code, the CI failure - to know what it's doing.
A tool surface - the actions it can take - to do anything at all.
Permissions - the bound on what it may touch - so delegation is safe.
Identity and a gate - attribution and a human checkpoint - so you can trust the result.

The claim is that in a unified workspace, each of these is one system serving both humans and agents, and on a stitched-together stack (a code host + a separate tracker + a separate chat + a separate doc tool), each is N systems an agent has to be separately integrated with, permissioned in, and identified to. The unified version isn't just tidier - it's measurably cheaper and safer, and the measurements are already done.

Context: one query, not five integrations

An agent triaging an issue needs everything related to it - the linked PR, the chat thread, the doc, the failing CI log. On a unified workspace that's one search index across all five surfaces, and we measured its cost: a workspace-scoped query stays under 1 millisecond at p99 even with a million rows in the index, because scoping to the workspace bounds the corpus regardless of how large the whole system grows. One index, one query, one auth check, sub-millisecond.

On a stitched stack, "the context for this issue" is a fan-out: call the tracker's API, then the code host's, then the chat's, then the docs', each a separate integration with its own auth, its own rate limit, its own latency, and its own partial view. The agent either makes N network round-trips to assemble context or, more often, works with the fragment one tool can see. The unified workspace doesn't make retrieval a little faster; it makes cross-surface context a single query instead of an integration project - which is why the agent gets the whole picture cheaply instead of a fragment expensively.

Tool surface: generated once, not maintained N times

An agent acts through tools, and on a unified workspace those tools are generated from the same API the UI uses - we measured 65 agent tools derived mechanically from makima's real OpenAPI spec, spanning issues, PRs, code, pipelines, chat, and docs. One schema, one tool surface, and it can't drift from the product because it is the product's API.

A stitched stack has no single tool surface to generate - it has five vendors' APIs, five auth models, five rate-limit regimes, and five release cadences that break your integration on their schedule. The agent's ability to act is a maintenance burden that grows with every tool the team adds. Unified, adding a surface to the product adds it to the agent's reach for free; stitched, adding a tool means building and maintaining another integration.

Permissions: one model, not five to configure

Delegation is only safe if you can bound what an agent may do, and on a unified workspace that bound is one scoped-token model enforced at one authorize chokepoint. We fuzz-tested the enforcement to zero privilege escalations across 200,000 random checks, and the scopes are the same capability strings the tools are generated with - so "this agent may comment on issues but not merge PRs" is one coherent statement, checked in one place.

On a stitched stack, least privilege for an agent means configuring four separate permission systems - the code host's, the tracker's, the chat's, the docs' - each with a different model, and hoping their union is what you meant. There's no single place that answers "what can this agent do," because the answer is scattered across four vendors' consoles. The unified workspace makes least-privilege a setting; the stitched stack makes it a project you get subtly wrong.

Identity and the gate: real teammate, real checkpoint

Trust needs attribution and a checkpoint, and both are structural in a unified workspace. Attribution, because an agent is a user - one enum on the users table gave agents every author, assignee, and reviewer relationship the schema already had, so everything an agent does is attributed the same way a person's work is, across all five surfaces at once. The checkpoint, because the approval gate is one state machine that sits in front of every irreversible action - merge, publish, deploy - on any surface, using the same guarded update we tested to 700,000 contended attempts.

A stitched stack can't give an agent one identity - it gets a service account per tool, so "what did the agent do this week" is four audit logs to reconcile, and "require human approval before it does something irreversible" is a per-tool feature that may or may not exist in each. The unified workspace makes attribution and the human-in-the-loop gate properties of the platform; the stitched stack makes them four separate integrations that mostly don't compose.

The honest counterargument

This thesis has a real limit, and pretending otherwise would fail our own bar. A unified workspace is measurably better for agents that work across surfaces - triage that reads chat and code, a fix that watches CI and opens a PR, a doc update driven by a code change. For an agent that lives entirely in one surface - a pure code-review bot, a standalone chat assistant - a great single-purpose tool with a good API is entirely sufficient, and the unified workspace's advantage shrinks to "one fewer integration." The bet pays off precisely to the degree that the work is cross-surface, which is exactly the work that's hardest to delegate on a stitched stack and most valuable to delegate at all.

The other honest caveat: this is an architectural argument backed by component measurements, not an end-to-end benchmark of agent task success, because the agent runtime (beam) is the newest piece. What's measured is that each of the four properties costs less and composes better when unified - sub-millisecond cross-surface retrieval, 65 tools from one schema, zero-escalation permissions in one place, one identity and one gate across every surface. Whether that compounds into measurably better agent outcomes is the thing we'll measure next; the components are the reason to expect it will.

FAQ

Isn't "unified is better" just a pitch for buying one tool instead of five?

For humans it's partly a preference argument - some teams like best-of-breed and accept the seams. For agents it's more structural, and that's the specific claim here: an agent can't "just check the other tab" the way a person papers over a stitched stack. It has exactly the context its integrations assembled and exactly the permissions its four consoles granted, so the seams that are a mild human annoyance become a hard ceiling on what an agent can see and safely do. The unified workspace removes a ceiling, not just a friction.

Why does this post have no benchmark of its own?

Because it's the synthesis of a cluster that does - deliberately. Each claim links the sibling post that measured it: retrieval latency, tool count, permission soundness, identity, the gate. Running one more benchmark here would be less honest than showing that the thesis is just what those five numbers add up to. The argument's job is to connect measurements, not manufacture a new one.

Does this mean Rezee's agents are better than a coding agent in an IDE?

Different jobs. An IDE agent is excellent at the surface it lives in - your local code - and Rezee isn't trying to replace it; you can point your own agent at Rezee over MCP. The claim is narrower and about a different task: for work that spans the lifecycle - issue to code to CI to doc - the workspace that unifies those surfaces gives any agent, first-party or yours, the context and guardrails to do it safely, which the surfaces-as-separate-tools model structurally can't.