The First Mental Model: What T3 Code Unifies—and What It Leaves Native

The first four chapters establish a single judgment problem: which parts of agent work should T3 Code unify, and which must remain owned by the environment or the provider? This checkpoint connects client behavior, remote trust, server-owned state, and provider integration into one model. The result is practical: when a feature or failure appears, readers should be able to identify its owner, the state that matters, the authorization scope involved, and the fallback when a capability is missing.

The same task crosses four layers

Imagine starting a coding task from a phone while the repository and provider are on a workstation. The phone supplies a message and displays the conversation. A route—perhaps direct pairing or T3 Connect—carries that intent to the workstation. The environment authenticates the client, selects the project and provider instance, records the thread state, and launches or resumes the provider process. An adapter translates between the provider’s native protocol and the control plane. The provider then reads files, runs tools, asks for approval, and changes the workspace.

That is not a list of five products. It is one control path with different owners. The client owns the immediate presentation and platform interaction. The route and authentication layer establish reachability and session scope. The environment owns the workspace, credentials, terminals, Git, and durable application state. The adapter mediates the provider protocol. The provider owns the native model, session semantics, tools, and sandbox rules. A single user action can cross all of these layers without making them interchangeable.

flowchart LR I["Client intent"] --> R["Route and authorization"] R --> E["Environment-owned state"] E --> A["Provider adapter"] A --> P["Native provider process"] P --> W["Workspace and durable outcome"] E --> T["Thread and projection"] T --> I

The model explains several otherwise confusing behaviors. If a phone loses its connection, the provider process may still be running because the environment owns it. If the route is reachable but an RPC is rejected, the problem belongs to session scope rather than the provider. If the client displays a provider option that the selected instance cannot use, the adapter or capability boundary is involved. If the provider’s native session cannot resume, the control plane can preserve the application thread while requiring a fresh provider session or a portable handoff.

The layers are connected, but they are not equally authoritative. A client can request a change; it cannot decide that the change succeeded. A route can deliver a request; it cannot grant a scope that the environment did not delegate. An adapter can present a common operation; it cannot give a provider a native capability the provider does not expose. The environment can retain the thread and workspace; it cannot promise that a provider’s hidden session state survived a crash.

This is the smallest complete model of T3 Code: a client directs an authenticated environment; the environment coordinates provider work and durable state; an adapter translates native behavior; and the provider remains the authority for its own execution semantics. The model is compact because it leaves out screens and brand names, not because it erases important distinctions.

What the control plane deliberately unifies

T3 Code unifies the things a person needs in order to manage work across surfaces. Web, desktop, and mobile clients can connect to the same environment and consume server-owned thread or shell state. A project can organize threads, workspace choices, and source-control relationships. Permission modes give a thread a user-facing policy.