AI-Native Design

Part of Project Kaze Architecture

---

1. What AI-Native Means

Most "AI platforms" place humans as operators with AI as a tool:

Human defines → Human deploys → Agent executes → Human monitors → Human improves

Kaze inverts this. AI is the operating layer. Humans are governors:

Human sets goals & guardrails
         │
         ▼
   AI orchestrates → AI executes → AI evaluates
        ↑                              │
        └──── AI improves & adapts ────┘

Human intervenes only at:
  - Goal setting
  - Guardrail violations
  - Escalation thresholds
  - Approval gates (when configured)

2. AI Monitors AI

The first responder for system health is not a human looking at Grafana — it's an AI agent.

Supervisor Agent Layer:

• Health Monitor Agent — Watches agent fleet health, detects failures, restarts stuck agents, identifies degraded performance. Takes corrective action, not just alerts.
• Cost Monitor Agent — Tracks token spend across the fleet, detects budget anomalies ("Agent X just burned 10x normal tokens"), throttles or pauses agents proactively.
• Quality Monitor Agent — Evaluates agent outputs for quality, catches hallucinations or drift, scores task completion.

These are not static rules (if error_rate > 5% then alert). They are AI agents reasoning about other agents' behavior, capable of catching novel failure modes that no human would have written a rule for.

Hard circuit breakers remain deterministic code, not AI reasoning:

• Budget limits → hard stop (code)
• Error rate thresholds → hard alert (code)
• Permission boundaries → hard enforcement (code)

AI supervision augments static monitoring — it does not replace safety-critical deterministic rules.

3. AI Improves AI — The Self-Optimization Loop

Every agent execution produces signals that feed a continuous improvement cycle:

Execution → Outcome → Evaluation → Learning → Adaptation

What can self-improve:

Layer	What improves	How
Prompts	Agent system prompts, few-shot examples	A/B testing, measuring output quality, auto-selecting winners
Tool usage	Which tools an agent uses, in what order	Analyzing successful vs. failed runs, optimizing tool call patterns
Orchestration	Workflow structure, parallelism, routing	Identifying bottlenecks, reordering steps, adding/removing stages
Model selection	Which LLM for which task	Cost vs. quality tracking per model per task type, auto-routing to cheapest model meeting quality bar
Knowledge	What context an agent receives	Learning which knowledge is useful for which tasks, pruning noise

Self-improvement lifecycle example:

1. Agent "Invoice Processor" handles 1000 invoices this week
2. Quality Monitor notices 15% of outputs needed human correction
3. Improvement Agent analyzes failure patterns — most corrections are tax calculations for international invoices
4. Improvement Agent proposes a prompt refinement with better tax handling + adds a tool call to a tax API
5. Change deploys as canary — 10% of traffic runs the new version
6. Quality Monitor confirms improvement — error rate drops to 3%
7. New version promotes to 100%

No human in this loop unless the Improvement Agent's confidence is below threshold.

Safeguard: All self-improvements are versioned, canaried, and reversible. An agent never modifies itself for all traffic simultaneously.

4. Shared Knowledge Graph

The knowledge graph is the persistent brain of the system, organized in three layers:

┌──────────────────────────────────────────────────┐
│              Shared Knowledge Graph               │
│                                                   │
│  Vertical Knowledge (shared across clients)       │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐          │
│  │   SEO   │  │   CRM   │  │  Sales  │  ...     │
│  └────┬────┘  └────┬────┘  └────┬────┘          │
│       └────────────┼────────────┘                 │
│                    ▼                              │
│  Cross-Vertical Knowledge                         │
│  ┌─────────────────────────────────────┐          │
│  │ - Business operations patterns      │          │
│  │ - Communication best practices      │          │
│  │ - Data analysis methods             │          │
│  │ - Reporting frameworks              │          │
│  └─────────────────────────────────────┘          │
│                                                   │
│  Client-Specific Knowledge (isolated per client)  │
│  ┌───────────┐ ┌───────────┐ ┌───────────┐      │
│  │ Client A  │ │ Client B  │ │ Client C  │      │
│  │ context,  │ │ context,  │ │ context,  │      │
│  │ history,  │ │ history,  │ │ history,  │      │
│  │ prefs     │ │ prefs     │ │ prefs     │      │
│  └───────────┘ └───────────┘ └───────────┘      │
└──────────────────────────────────────────────────┘

Knowledge isolation rules:

• Vertical knowledge — Shared across all clients in a vertical. SEO best practices don't change per client. In agency mode, this knowledge compounds across clients.
• Cross-vertical knowledge — Patterns that apply everywhere, shared across the entire platform.
• Client-specific knowledge — Brand voice, industry quirks, preferences, history. Never leaves the client's cell/namespace. In customer VPC mode, all client knowledge stays in their VPC.

Knowledge provenance classification (D43):

Every knowledge entry is tagged with a source class that determines who can see it:

Source Class	Description	Visibility
public	Public domain sources	All clients
speedrun_internal	Speedrun's own operations (V0)	All clients
speedrun_research	Funded research and benchmarks	All clients
client_contributed	Anonymized from client engagement, with consent	Contributor-tier clients only
client_private	Client-specific, never shared	Owning client only

Default: no client data enters shared knowledge. Clients opt into a contributor tier to share anonymized learnings and access the contributed pool. This protects against trade secret misappropriation and GDPR purpose limitation violations. See research/data-rights-knowledge-sharing.md.

Knowledge in customer VPC deployments: Client-specific knowledge always stays local. Vertical knowledge (Speedrun-sourced tiers) can sync from Speedrun's central repository to the VPC (read-only). Contributor-tier VPC clients can opt in to share anonymized learnings back, governed by the same consent framework.

5. Adaptive Orchestration

Orchestration in Kaze is AI-driven, not static DAG definitions:

• Dynamic task decomposition — An orchestrator agent receives a goal, breaks it into subtasks, assigns to worker agents. The decomposition adapts based on the specific input, not a hardcoded workflow.
• Runtime re-planning — If step 3 of 5 fails, the orchestrator reasons about why it failed and may choose an entirely different path rather than just retrying.
• Resource-aware scheduling — The orchestrator factors in token budgets, agent availability, and latency requirements, making cost/speed tradeoffs in real-time.

6. Agent Safety Boundaries

AI autonomy requires hard boundaries that no amount of reasoning can override. These are enforced by deterministic platform code, not by agent self-discipline.

Capability Manifests

Every agent has a manifest declaring exactly what it can do:

• Tools: Whitelist of tools the agent may call (e.g., github_create_issue, semrush_keyword_overview)
• Knowledge domains: Which knowledge domains the agent can read from and write to
• Communication: Which other agents it can message, which channels it can send to

The runtime enforces the manifest on every action. An agent cannot discover or invoke tools outside its manifest, even if the underlying registry contains them.

Instruction Hierarchy

When an agent processes context, a strict trust ordering applies:

System prompt (platform-defined, immutable)
  > Skill definition (admin-authored, versioned)
    > Retrieved knowledge (quality-gated, provenance-tracked)
      > User input (untrusted by default)
        > Tool output (untrusted, external)

Higher levels override lower levels. If user input contradicts a skill definition constraint, the skill definition wins. This is the primary defense against prompt injection — untrusted content cannot override trusted instructions.

Supervision State Isolation

Supervision levels (supervised → sampling → autonomous) are read-only to agents. Only the platform's supervision ramp logic can promote or demote. An agent cannot:

• Query or modify its own supervision statistics
• Skip the approval queue for supervised tasks
• Influence sampling rates for its own outputs

Subagent Privilege Inheritance

When an agent spawns a subagent:

• The subagent inherits at most the parent's capability set (tools, knowledge domains, communication)
• The subagent inherits at most the parent's supervision level (a supervised agent cannot spawn an autonomous subagent)
• The parent's resource quotas are shared, not duplicated — subagents draw from the parent's budget