Summary
Persisting an AI session and restoring it later (e.g. on the user's next login) requires the developer to coordinate two unrelated APIs:
AIOrchestrator.getHistory() and AIOrchestrator.Builder.withHistory(history, attachments) — for chat history and attachments.ChartAIController.getState() / restoreState(ChartState) and GridAIController.getState() / restoreState(GridState) — for the visible chart/grid state.
To save a session a developer has to:
- Read the chat history from the orchestrator.
- Read the state from each controller separately.
- Persist all of them.
To restore on a later session, the dance reverses: pass withHistory(...) to the orchestrator builder, and call restoreState(...) on each controller individually. State-change wiring (addStateChangeListener) is also per-controller, so a "save everything when something changes" workflow has to fan out across N hooks.
Why it's worth addressing
- Discoverability. A developer looking at
AIOrchestrator doesn't see that controllers also carry persistable state. It's easy to ship a "we persist the chat" implementation and forget the chart/grid state entirely.
- Coordination. The orchestrator already knows about its registered controllers. Keeping them as separate persistence surfaces pushes coordination work to every consumer.
Proposal
Discuss extending AIController with state capabilities (e.g. opaque getState() / restoreState(...) typed via the interface) and surfacing the aggregate through the orchestrator — for example:
AIOrchestrator.getSessionState() returning a snapshot that bundles chat history + per-controller state.- A corresponding
Builder.withSessionState(...) (or equivalent restore method) that pushes the bundle back into the orchestrator and its controllers.
The per-controller state APIs can stay as escape hatches, but the orchestrator becomes the one place you go for "save and reload the session."
Summary
Persisting an AI session and restoring it later (e.g. on the user's next login) requires the developer to coordinate two unrelated APIs:
AIOrchestrator.getHistory()andAIOrchestrator.Builder.withHistory(history, attachments)— for chat history and attachments.ChartAIController.getState()/restoreState(ChartState)andGridAIController.getState()/restoreState(GridState)— for the visible chart/grid state.To save a session a developer has to:
To restore on a later session, the dance reverses: pass
withHistory(...)to the orchestrator builder, and callrestoreState(...)on each controller individually. State-change wiring (addStateChangeListener) is also per-controller, so a "save everything when something changes" workflow has to fan out across N hooks.Why it's worth addressing
AIOrchestratordoesn't see that controllers also carry persistable state. It's easy to ship a "we persist the chat" implementation and forget the chart/grid state entirely.Proposal
Discuss extending
AIControllerwith state capabilities (e.g. opaquegetState()/restoreState(...)typed via the interface) and surfacing the aggregate through the orchestrator — for example:AIOrchestrator.getSessionState()returning a snapshot that bundles chat history + per-controller state.Builder.withSessionState(...)(or equivalent restore method) that pushes the bundle back into the orchestrator and its controllers.The per-controller state APIs can stay as escape hatches, but the orchestrator becomes the one place you go for "save and reload the session."