{
  "uid": "cogitave.learn.build-your-first-agent-with-namzu.what-is-namzu",
  "kind": "moduleUnit",
  "href": "/modules/build-your-first-agent-with-namzu/what-is-namzu/",
  "title": "What is the Namzu agent kernel?",
  "summary": "",
  "type": null,
  "products": [],
  "roles": [],
  "levels": [],
  "subjects": [],
  "headings": [
    "Framework or kernel",
    "What is in the kernel, and what is not",
    "Providers are drivers",
    "Authority is declared",
    "How it is licensed"
  ],
  "source": "**Namzu is an agent *kernel*, not an application framework.** That distinction is\nthe whole design, so it is worth being precise about it before you write code.\n\n## Framework or kernel\n\nMost agent libraries are application frameworks. They bundle a chat interface, a\nhosted dashboard, a fast path for one vendor, and drivers for a handful of\ndatabases. You get a demo in an hour; three months later the library owns your\nfrontend, your storage, your observability, and your model choice — and none of\nthose were decisions you made.\n\nNamzu takes the Unix position instead. At the bottom sits a kernel that isolates\nwork, schedules tool calls, propagates signals across a call tree, manages memory\npressure, persists checkpoints, and emits an auditable event stream. Above it is\nuser space: shells, editors, IDEs, voice gateways, React apps. The kernel does not\ncare which one you pick, and the one you pick cannot break the isolation the\nkernel provides.\n\n## What is in the kernel, and what is not\n\n| In the kernel | Not in the kernel |\n| --- | --- |\n| Lifecycle, scheduling, signals | User interface |\n| Budgets and memory pressure | Hosted service or control plane |\n| Durability and checkpoints | A favoured model vendor |\n| Inter-process communication, MCP and A2A | Your database |\n| Provider abstraction | Your frontend |\n| Auditable event stream | |\n\nThe right-hand column is a feature. Nothing phones home, and there is no console\nyou must sign into for the kernel to work.\n\n## Providers are drivers\n\nA model vendor is not part of the kernel; it is a driver in its own package.\n\n| Package | For |\n| --- | --- |\n| `@namzu/ollama` | Local inference, zero config, no key |\n| `@namzu/lmstudio` | Local inference over LM Studio |\n| `@namzu/openai` | OpenAI Chat Completions |\n| `@namzu/anthropic` | Anthropic Messages API |\n| `@namzu/bedrock` | AWS Bedrock Converse |\n| `@namzu/openrouter` | Many models behind one key |\n| `@namzu/http` | Any OpenAI- or Anthropic-compatible endpoint |\n\nEvery driver returns the same response shape, so the code below your registration\nline does not know which vendor answered:\n\n```typescript\n{ id, model, message: { role, content, toolCalls? }, finishReason, usage }\n```\n\nThat uniformity is what makes changing vendor a one-line edit rather than a\nmigration.\n\n## Authority is declared\n\nA tool declares what it is and what it may reach — its typed input schema, its\npermissions, whether it is read-only, whether it is destructive, whether it is\nsafe to run concurrently. The kernel validates input against the schema *before*\nyour `execute` function runs, so it only ever sees well-formed arguments.\n\n> [!IMPORTANT]\n> Permissions are an allow-list. A tool can reach exactly what it declares and\n> nothing more, and an empty permission set is a tool that may compute and reach\n> nothing. Adding a behavior means declaring the authority it needs — never\n> widening a declaration to make a failing check pass.\n\n## How it is licensed\n\nNamzu is Fair Source: `FSL-1.1-MIT`. Every published version converts to MIT two\nyears after its release, so you can read it, run it, and build on it today, and\nthe code becomes fully permissive on a published schedule.\n",
  "partOf": "cogitave.learn.build-your-first-agent-with-namzu",
  "durationInMinutes": 5,
  "quiz": null
}