Core thesis

DKG is a deterministic orchestration layer that separates capability from responsibility in AI agents.

It routes queries, selects tools, configures model parameters, and defines execution strategy before the LLM begins reasoning. Every decision is reproducible, inspectable, and ready for cryptographic audit.

Traditional agent frameworks maximize autonomy. DKG maximizes accountability.

Why this matters

Most modern agent frameworks allow an LLM to choose which tools to use, decide whether to search, select its execution strategy, and operate with fixed or loosely tuned generation parameters. This works for consumer applications.

It does not work in high-stakes environments where tool choice must be explainable, search behavior must be enforceable, configuration must be reproducible, and execution must be auditable.

In most systems, routing is an internal LLM decision. Opaque and probabilistic. DKG moves routing outside the model.

What DKG changes

Instead of letting the LLM decide how to operate, DKG embeds the user query once, deterministically activates a hierarchical gate tree via cosine similarity, and produces a configuration object. That object contains: skills to inject, tools to expose, model selection, execution mode, temperature, top_p, top_k, and grounding level.

Only then does the agent begin execution.

The LLM does not choose its tools. The LLM does not choose its temperature. The LLM does not decide whether to search. DKG decides. Transparently and reproducibly.

What DKG is not

DKG is not a new LLM, a training-time alignment system, a compliance policy engine, or a replacement for agent frameworks. It is an orchestration layer that constrains and configures agents dynamically, based on semantic routing.

Architectural principles
  1. Determinism over autonomy. Routing decisions are made by embedding math, not LLM reasoning.
  2. Routing outside the LLM. The model never sees the full tool inventory. Only what DKG selects.
  3. Risk-calibrated generation. Temperature, top_k, top_p are set by gate match score, not by default.
  4. Capability filtering before reasoning. The agent's skill set is narrowed before it starts thinking.
  5. Audit-ready execution path. Every step from query to response has a cryptographic anchor.

Gate tree

The tree has three concentric levels radiating from the user's prompt at center. The prompt is embedded once. That single vector is compared via cosine similarity against pre-computed gate embeddings at each level. Gates exceeding their threshold activate. Active gates at each level constrain which child gates are evaluated at the next ring.

L3 L2 L1 P prompt research verify writing analysis data PLAN- NING deep research entity lookup source discovery claim check stats verify formal report narrative draft summary brief document parse pattern detect extract transform cross reference task decompose agent assign tool 1 llm 1 tool 2 tool 3 llm 2 tool 4 llm 3 tool 5 llm 4 tool 6 llm 5 llm 6 tool 7 tool 8 tool 9 tool 10 llm 7 llm 8 Prompt L1: Domain L2: Skill L3: Tool + LLM config PLANNING gate Shared tool (cross-branch)
Fig 1 -- DKG radial gate tree. User prompt at center. Three concentric rings activate via cosine similarity. L3 nodes determine both tools and LLM configuration.

Level 1 gates classify the domain. Level 2 gates select the skill. Level 3 gates map to concrete tools and LLM configurations. Multiple branches activate simultaneously. The same tool can appear under different branches. DKG deduplicates the final set.

Risk-calibrated generation

Temperature, top_k, and top_p are not fixed settings. They are determined by the embedding similarity score of the best-matching L3 gate. High-confidence match to a verification skill: low temperature, low top_k. Match to a creative writing skill: higher temperature, higher top_p. The agent does not choose its own parameters. DKG sets them based on what the query requires.

The cosine similarity score acts as a continuous signal. The closer the match, the more confidently DKG applies that gate's prescribed configuration. When multiple L3 gates activate, the highest-scoring gate determines the agent's final setup.

The PLANNING gate

Most queries are single-intent. They map to one domain and one execution path. Complex professional work produces multi-step queries that span several domains with sequential dependencies.

The PLANNING gate detects these situations through two mechanisms. First, embedding similarity against multi-intent utterances. Second, an automatic trigger: three or more L1 gates active simultaneously means the query is too complex for a single pass.

Override: If PLANNING activates but fewer than two other L1 gates are active, it deactivates. This catches false positives like "plan when to release the report."

When PLANNING activates, the agent decomposes the query into tasks and assigns each task to a specialized subagent. Each subagent receives its own DKG configuration. The gate tree is re-evaluated per subtask. Each executor gets only the skills and tools relevant to its phase.

Execution modes

ModeTriggerBehavior
DIRECT1 gate, >0.85Deterministic tool execution. Agent formats the result.
AGENT1-2 gates, 0.55-0.85Autonomous agent with DKG-filtered skills and tools.
CONVERSATION0 gates activeNo skills, no tools. Pure dialogue.
PLANNERPLANNING activeMulti-phase plan. Each phase delegated to subagent with own DKG config.

DKG switches between these modes per query. No user configuration required.

Example execution
"Check whether Company X misreported Q3 revenue and write a two-page compliance brief."
DKG routing (50ms): Embedding activates L1 verify + L1 writing + L1 data. Three gates active. PLANNING triggers automatically.
Phase 1 -- verification: Subagent with claim check skill, stats verify skill. Tools: financial database, web search. LLM config: temperature 0.1, top_k 1. Grounding: HARD (search forced in code).
Phase 2 -- data extraction: Subagent with extract/transform skill. Tools: document parser, cross-reference engine. Grounding: MEDIUM.
Phase 3 -- writing: Subagent with formal report skill. Tool: document generator. LLM config: temperature 0.4, top_p 0.85. Grounding: NONE (writes from verified data).
Every step: Logged to immutable ledger via HDK. Each subagent's identity, config, inputs, and outputs cryptographically signed.

Hooks and audit trail

Every routing decision and agent action passes through hooks that log to an immutable ledger via HDK. Hooks operate in the application runtime, outside the LLM context. The agent cannot bypass them.

PreQuery log query hash PostDKG log config, gates PreToolUse can BLOCK PostToolUse log result hash PreResponse grounding check Immutable ledger -- cryptographically signed per agent
Fig 2 -- Hook chain. Five interception points per query. Red hooks can block execution. All events anchored to ledger via HDK.

Each agent and subagent has a unique cryptographic identity (see HDK). Every audit record is signed with the acting agent's private key. For any output, you can prove which agent produced it, what configuration it ran, what data it accessed, and when.

Grounding enforcement

The higher the epistemic risk, the lower the agent autonomy.

LevelMechanismApplied to
NONENo search requirementConversation. Writing from provided data.
SOFTSkill instructionAgent mode. ~95% effective.
MEDIUMInstruction + guardrailResearch subagents. <3 searches = rejected.
HARDSearch is code, not agent decisionVerification. LLM interprets pre-fetched results.

Cost and scaling

DKG overhead: ~50ms latency, ~$0.0001 per query. Less than 2% of total query time. The token savings from filtered context often exceed the routing cost.

The architecture scales by adding depth. Phase 1: flat router for 6-8 tools. Phase 2: two-level hierarchy at 15+ tools. Phase 3: full three-level tree with PLANNING and subagent dispatch at 30+ tools. The hook chain works identically at every phase.