[FEATURE]: Separate an agent's configuration from its running state #628

Summary

Agent holds config-derived values — model, turn depth, system prompt, context window — alongside state belonging to a single run, such as its scratchpad budget and turn-nudge state, and the whole thing is constructed fresh for every chat request. Separating the two is what makes an agent something that can be reused rather than rebuilt, and it is the delineation between AgentConfig and a running Agent that #575 asks for.

The reusable half is built rather than declared — it owns a live provider client, the tools discovered at build time, and open MCP connections — so PreparedAgent names it and Agent keeps meaning one run. That leaves AgentRuntimeConfig unambiguously the TOML.

Goals

• The config-derived half constructible once and shareable across a session's turns.
• The per-run half owned by one run and dropped with it, including the state that reaches tools through wrappers rather than through a field.
• No change in behavior, so it can land without a flag or a migration.
• The precondition satisfied for warm agent and MCP reuse in [FEATURE]: Session Backed Agent Runtime #578, without implementing caching here.

Additional Context

A prepared agent serves one run at a time. Rig owns its tool server at agent scope — tool_server_handle is a field on rig's Agent, spawned once when the agent is built — so every tool call for that agent arrives on one long-lived task. Two runs sharing a prepared agent would have no way to tell their tool calls apart: the task-local run scope does not survive the spawn, and a single bound-run slot races. Concurrency belongs at the session level, one prepared agent per session.

Worth enforcing rather than documenting alone, because the failure is silent — tool events attributed to the wrong run, no error. Lifting the restriction means per-call run correlation, which rig's design does not currently allow.

Ordering: this rewrites the Agent struct, which the #575 event stack also modifies, so it wants to land after that stack rather than under it.

Searched Issues

• No similar issues found

Code of Conduct

• I agree to follow this project's Code of Conduct