Lesson 11 — Driver, Instance, Strategy, Capability

Outcome

Implement the provider identity/configuration model without starting a real agent.

Why this comes now

Agent products expose multiple protocols/accounts with different guarantees. “if agent == Claude” is not an architecture.

Understand

Driver is the integration family. Instance is one configured account/installation lifecycle. Strategy is one concrete protocol. Capabilities belong to Strategy and describe semantics, not marketing features.

Two instances of the same driver must not accidentally share mutable session/catalog/account state. A richer strategy must not silently fall back to a weaker one when doing so changes product guarantees.

Build the real project

1. Add DriverID, AgentInstance, StrategyID, and CapabilitySet types.
2. Create an in-memory/compiled strategy registry.
3. Persist Agent Instances only as much as current settings need.
4. Define the first capability names needed by the fake adapter (structured events, interrupt, interactive decision later, etc.).
5. Add capability snapshots to future Run creation model.
6. Write tests showing feature checks ask capabilities rather than driver names.

Completion gate

No domain/application branch checks a literal provider name to enable a behavior. Two instances can exist with the same driver ID. Capability snapshot is copyable/immutable for a Run.

Pitfalls to avoid

Avoid a giant capability list before behavior exists. Avoid supportsEverything bool. Avoid silent fallback.

References

T3 provider constraints: https://github.com/pingdotgg/t3code/blob/main/docs/internals/providers.md ; Mux policy/runtime behavior: https://github.com/coder/mux/blob/main/docs/config/policy-file.mdx

Checkpoint

Before next lesson, explain Driver/Instance/Strategy using a concrete Claude/Codex example.