remember, recall, getContext, checkpoint, and the learning-loop APIs.
State method families
| Domain | Typical purpose |
|---|---|
| Variables | Small explicit run-scoped state values |
| Concepts | Named planner concepts / controlled vocabulary |
| Goals | Goal trees and roll-up planning state |
| Actions and cycles | Action logs and planning / reasoning history |
Current route groups
| Capability | Routes |
|---|---|
| Variables | /v2/control/variables/set, /v2/control/variables/get, /v2/control/variables/list, /v2/control/variables/delete |
| Concepts | /v2/control/concepts/define, /v2/control/concepts/list |
| Goals | /v2/control/goals/add, /v2/control/goals/update, /v2/control/goals/list, /v2/control/goals/tree |
| Actions and cycles | /v2/control/actions/submit, /v2/control/actions/log, /v2/control/cycles/run, /v2/control/cycles/history |
Recommended usage guidance
- Keep explicit state in the same
run_id/session_idas the memory it explains. - Use goals for planner structure; use lessons and rules for reusable learned behavior.
- Use actions and cycles for replayability and debugging, not as a substitute for memory retrieval.
- Use checkpoints when the task is about to compact or cross a risky boundary.
Failure modes and troubleshooting
| Symptom | Root cause | Fix |
|---|---|---|
| Planner state exists but the model still forgets things | Only state was stored, not memory | Persist facts, lessons, or rules alongside variables/goals |
| Goal trees become noisy | No hierarchy discipline | Use parent-child goals and retrieve with goals/tree |
| Debugging is hard | Actions and cycles are missing | Record planner decisions explicitly |
Next steps
- Review the main control surface at Control HTTP reference.
- Apply planning plus memory in Stateful task trees.