Agentic sessions are the bounded execution structures through which AchillesAgentLib carries multi-step work across planning, tool or skill invocation, intermediate state, and stopping conditions. In the current implementation, the runtime exposes two complementary session regimes: a loop-based mode for adaptive step-by-step deliberation and a SOP-based mode for plan-first execution through Plan SOPlang.
In AchillesAgentLib, an agentic session is not a metaphorical “brain” and not a loose chat wrapper. It is a concrete runtime object with explicit state, explicit completion signals, and explicit execution boundaries. The two session classes, LoopAgentSession in LLMAgents/AgenticSession.mjs and SOPAgenticSession in LLMAgents/SOPAgenticSession.mjs, are created by LLMAgent through startLoopAgentSession() and startSOPLangAgentSession(). From that point onward, the session becomes the local structure that holds the evolving execution trace, the latest answer, the intermediate variables, and the current status.
This distinction matters because the rest of the runtime builds on it directly. Orchestration skills use these sessions as their execution substrate, and Anthropic Skills rely on the loop-based variant as their operative runtime. The two regimes should therefore be understood as complementary orchestration styles over the same skill ecosystem rather than as unrelated mechanisms. One favors adaptive local replanning at each step. The other favors explicit plan compilation followed by structured execution.
Both regimes also share a common stopping contract. They reserve the completion names final_answer and cannot_complete and add them to the active tool or command surface automatically. A session does not simply end when the text looks plausible. It ends when execution reaches one of these bounded completion signals, when an interactive pause is raised, or when the configured budgets and error conditions force termination.
The session objects themselves are ordinary in-memory JavaScript structures, but loop-based subsystems may store them in sessionMemory when they pause in awaiting_input state and may resume them on the next user message. The important point is therefore not persistence to disk, but governed continuity of execution across turns.
The diagram below places the two execution regimes under the same runtime contract. The point of divergence is not the entry surface, but the way multi-step execution is governed after the session starts.
startLoopAgentSession() or startSOPLangAgentSession()
Outcomes: final_answer, cannot_complete, or awaiting_input. If paused, the session can be stored in sessionMemory and resumed later.
Outcomes: final answer from the plan, bounded replanning on failure, or direct continuation of a pending command. In planOnly, execution stops after plan generation.
final_answer and cannot_complete automatically.getLastResult().The most useful distinction is not between simple and complex sessions, but between two different ways of governing multi-step execution. In the loop regime, the runtime keeps deciding the next admissible action during execution and stores intermediate results under symbolic references. In the SOP regime, the runtime first compiles a Plan SOPlang artifact and then executes that artifact under a bounded commands registry. The two approaches therefore differ in where deliberation occurs and how explicit the execution structure becomes before downstream work begins.
The loop-specific contract, including result references, interactive continuation, execution limits, and the return surface of LoopAgentSession, is documented in Loop Sessions. The plan-first contract, including skillsDescription, commandsRegistry, planOnly, direct continuation of pending commands, and bounded replanning, is documented in SOP Sessions.
This split is justified because the two session classes are not cosmetic variants of the same object. They expose different configuration surfaces, different state structures, and different operational failure modes. Keeping them under one overview page preserves the common architecture. Giving each regime its own chapter preserves technical precision.