LLM MODULE FEATURE
Execution Flow
The important part is not that the model can talk. The important part is that the path from intent to execution is structured, inspectable, and policy-gated.
Feature Guide
A quick orientation block that answers the essential questions: what this feature does, how it works, why it matters, and the key concepts behind it.
What this does
How a user request becomes a planner decision, a reviewed skill proposal, and finally a real console execution.
Execution Stages
From prompt to command run
The model does not get arbitrary shell access. It receives a bounded skill catalog and must answer in one of a few typed planner formats.
// Scoped to the surface: what the planner is shown is what it may propose.
$manifest = $registry->buildManifest()->forChannels(['web']);
$systemPrompt = $planner->buildSystemPrompt($manifest);
$request = new LlmRequest(
systemPrompt: $systemPrompt,
userMessage: $input,
history: $session->getHistory(),
);
$llmResponse = $provider->complete($request);
$decision = $planner->parseResponse($llmResponse);
if ($decision->type->value === 'propose_skill' && $decision->skill !== null) {
$result = $executor->execute($decision->skill, $decision->arguments, $manifest, 'web');
}| Stage | Primary class | What happens |
|---|---|---|
| Build skill surface |
SkillRegistry + ScopedSkillManifest
|
Collect the skills this surface may run and compress them into the planner prompt. |
| Ask the provider |
LlmProviderInterface + LlmRequest
|
Send system prompt, user message, and recent conversation history to the backend. |
| Parse the decision |
Planner + PlannerResponse
|
Accept only answer, ask, propose_skill, or refuse in structured JSON form. |
| Gate execution |
AiConfirmationMode + SkillExecutor
|
Check confirmation needs, validate arguments, and reject anything outside the manifest. |
| Maintain context |
ConversationSession
|
Keep a trimmed in-memory history so the assistant can continue the same operator conversation. |
Verified against Semitexa Ultimate 2026.09.19.1020
Execution Flow
The LLM execution path is intentionally staged: manifest, planner prompt, provider response, parsed decision, human confirmation when needed, and only then command execution.
How it works
The assistant command builds a constrained system prompt from SkillManifest, sends the user request plus recent conversation history to the provider, parses the JSON decision into PlannerResponse, and passes approved proposals into SkillExecutor.
Why this matters
This makes the path inspectable. When something goes wrong, you can tell whether the failure came from the provider, the planner decision, policy validation, or the underlying command itself.