Aleph
Concepts

Intent Detection

Intent is handled by the LLM under R7; the Harness does not run a separate intent rule engine.

Current model

Under R7 (LLM sovereignty), Aleph no longer runs regexes, keyword rules, confidence thresholds, or a separate intent classifier before a message reaches the model. The LLM understands the user's message during its normal reasoning call. The Harness connects model requests to tools, permissions, and the execution loop; it does not pre-classify message intent.

Therefore KeywordPolicy, KeywordIndex, AiIntentDetector, ExecutionIntentDecider, IntentCache, TaskCategory, and message-intent-based tool relevance scoring are not part of the current R7 configuration or runtime path. They must not be added to config.toml or used as implementation guidance.

Tool presentation and permissions

Tool visibility and invocation use static boundaries that are independent of message content:

  • session_mode (chat, work, code) partitions the presented tool surface without changing permissions;
  • progressive tool disclosure loads deferred tools on demand through tool_search;
  • allowlists, permission Deny, health state, and [sandbox.command_policy] remain independent static security constraints;
  • policies.exec_tier controls the approval policy and cannot lower the sandbox hard floor.

The model may request a tool; the existing tool registry, permission checks, and execution loop then process the call and its result. Tools must not be filtered or labeled by message keywords.

Direct routes

Explicit protocol operations such as registered slash commands, Gateway RPCs, and tool_search may still be routed directly. These are protocol or tool calls, not intent detection applied to natural-language messages.

There is no intent-specific configuration section. Models and failover are configured through [providers.*] and provider references in [general]; tool presentation and approval policy are configured under [policies]. See Configuration and Architectural Redlines.

On this page