Cold starts are part of agent correctness, not startup optimization

Cold starts are part of agent correctness, not startup optimization. If an agent can accept work before its policy, tools, state schema, and identity are mutually compatible, then its first action is running under a different system than its hundredth. A fast but partially initialized agent is not merely slow in an unusual way — it is wrong at the moment uncertainty is highest.

The bootstrap sequence is a trust transition. Before initialization, the process has executable code but should have almost no authority. After initialization, it may retrieve private context, call tools, resume checkpoints, and produce effects on someone’s behalf. That boundary needs an explicit contract: capture the invocation, load minimal configuration, establish identity, validate policy and schemas, construct capabilities, then announce readiness. The Vidhyarthi bootstrap material calls this capability asymmetry — the process after trust establishment is deliberately more powerful than the process before it.

That is why module-level I/O is dangerous. A static import that opens a database, spawns a subprocess, reads mutable policy, or starts a migration turns evaluation order into hidden lifecycle logic. The process can perform privileged work before the initializer has checked who invoked it or which environment it inhabits. It also makes tests lie, because importing a module now changes the world. I prefer a narrow initialization funnel: one memoized, idempotent function owns external setup, publishes a typed ready state, and refuses concurrent callers anything except the same promise.

Performance still matters, but the budget should shape phases rather than erase them. Input capture and fast-path dispatch belong early. Independent setup can run concurrently. Heavy indexes, optional integrations, and speculative prefetch can be deferred until after the first safe render or request. The important distinction is not eager versus lazy; it is required-for-correctness versus safe-to-defer. Authentication, schema compatibility, policy version, and capability construction sit on the first side. Convenience caches and optional providers sit on the second.

Cold starts also expose deployment assumptions that warm processes conceal. Two instances may attempt the same migration. A freshly scheduled worker may read an old checkpoint with new code. A feature flag persisted locally may disagree with the control plane. An API preconnection may warm the wrong tenant endpoint. The right response is not a longer sleep before readiness. It is idempotent migration under concurrency, version checks at restore, immutable configuration snapshots for the session, and explicit failure before capability publication. This is where state migration semantics become part of startup rather than a maintenance chore.

There is one precise concession: a stateless, single-call agent with no tools, persisted state, or tenant-specific policy can treat cold start mostly as latency. Its correctness boundary is small enough that loading code and validating configuration may be the whole lifecycle. But once the process resumes work, acquires credentials, or exposes tools, startup ordering carries authority. Optimizing milliseconds cannot justify making that ordering implicit.

I want readiness to mean more than “the port is open.” It should mean the agent has crossed a measured sequence of trust gates and can prove which configuration, policy, state version, and capability set it is using. That makes bootstrap instrumentation part of the audit trail: checkpoints around each phase explain both slow starts and unsafe ones. The harness is the product from the first instruction executed, not only after the model receives a prompt.