T3 Code explained: the client controls work on another machine
T3 Code architecture: durable intent before agent side effects
Follow a command through RPC, event log, outbox and provider work
What you will learn
- Respect the environment boundary
- Trace committed intent
- Let workers perform effects
Before you start
- A disposable project on an environment host
- One authenticated supported provider
Turn a disposable trial into evidence before connecting important repositories
Key takeaways
- The server owns files, Git and providers.
- The event log is the durable source of truth.
- A command receipt does not mean an agent finished.
Respect the environment boundary
The RPC contract in `packages/contracts/src/rpc.ts` connects independently versioned clients and environments. Subscriptions narrow data to what the active view needs. Client preferences stay client-side; project and environment defaults stay with the owning server.
A mobile or browser client must not use its own filesystem or provider credentials in place of the server’s. The connection runtime shares domain and reconnect behavior across platforms.
Trace committed intent
The v2 orchestrator decides events without doing external provider or filesystem I/O. `EventSink` commits events, projections, accepted-command receipt and outbox effects in one database transaction, then subscribers see the result.
An acknowledged command therefore means durable intent was accepted, not that an agent finished its turn. This distinction keeps retries idempotent and prevents the UI from assuming that a queued effect has succeeded.
Let workers perform effects
`EffectWorker` performs recorded side effects after the transaction and feeds results back into orchestration. Provider turn completion and later checkpoint or diff work are separate milestones.
If a provider process disappears, effects tied to it cannot simply be replayed against a new session. Recovery has to retire stale work before admitting more. These are source and design claims, not measurements from a running server here.
Decision guide
| Criterion | Option A | Option B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
Implementation steps
- 1
Locate the RPC contract and owner environment.
- 2
Distinguish command receipt from effect completion.
- 3
Observe provider turn and checkpoint settlement separately.
Copy-ready example
client RPC -> orchestrator decisions -> EventSink transaction
outbox -> EffectWorker -> provider / files -> result eventFrequently asked questions
Does a successful RPC receipt mean the code change is complete?
No. It records accepted intent; worker and provider outcomes follow later.
Why not write files inside the event transaction?
The documented design keeps external I/O out of that transaction and records effects for later work.
Sources
- T3 Code / docs/internals/overview.mdSource checked 2026-10-04
- T3 Code / packages/contracts/src/rpc.tsSource checked 2026-10-04
- T3 Code / apps/server/src/orchestration-v2/Orchestrator.tsSource checked 2026-10-04
- T3 Code / apps/server/src/orchestration-v2/EventSink.tsSource checked 2026-10-04
- T3 Code / apps/server/src/orchestration-v2/EffectWorker.tsSource checked 2026-10-04