# K1412 Agent documentation

This directory is the canonical technical record for K1412 Agent. The public
documentation portal at <https://agent.k1412.top/doc/> is a curated rendering
of the same design. When behavior, infrastructure, or an experiment changes,
update the relevant Markdown document and the portal snapshot in the same
commit.

## Start here

| Document | Audience | What it answers |
| --- | --- | --- |
| [Architecture](architecture.md) | Everyone | What runs where, and why are the boundaries drawn this way? |
| [Agent loop](agent-loop.md) | Agent researchers and backend engineers | How do context, tools, scheduling, evidence, memory, and child Agents work? |
| [Experiment system](experiments.md) | Agent researchers | How do we change the loop without losing comparability or production safety? |
| [Project history](project-history.md) | Maintainers | Which product and architecture decisions have already been made? |
| [Open WebUI integration](openwebui-integration.md) | Frontend and platform engineers | What belongs to Open WebUI, and what remains K1412-owned? |
| [Security model](security.md) | Security and platform engineers | How are users, credentials, workspaces, and Docker separated? |
| [Infrastructure map](infrastructure.md) | Operators | Which services are shared infrastructure and which are Agent core? |
| [Development and verification](development.md) | Contributors | How do I run, test, and safely change the system? |
| [Operations runbook](operations.md) | Operators | How is production built, deployed, verified, backed up, and migrated? |

## Current product contract

- There is one user-facing mode: the K1412 Agent loop. The earlier Chat/Work
  split was removed deliberately.
- Open WebUI owns accounts, sessions, approval, conversation storage, and the
  chat shell. K1412 owns Agent behavior.
- Four server-defined model choices are exposed: Luna, Terra, Sol, and
  DeepSeek V4 Pro. Model identity and thinking capability are displayed
  separately.
- Every Open WebUI user receives an isolated Docker container, network, and
  persistent volume on the dedicated physical execution host.
- Generated files can be browsed and downloaded through the authenticated Web
  UI. Internal dependency directories are hidden.
- Provider credentials, internal prompts, Docker access, SSH configuration,
  and tool-service credentials are never browser-configurable.

## What is experimental

The stable platform boundary is authentication, user/workspace isolation,
durable storage, and the public OpenAI-compatible Runtime API. The intended
experimental surface is:

- context selection and compaction;
- memory retrieval and lifecycle;
- tool descriptions, normalization, and routing;
- parallel scheduling and mutation serialization;
- child-Agent delegation policy;
- evidence and completion gates;
- recovery prompts and retry policy;
- model routing and per-tier budgets.

Every experiment should be versioned in run events and evaluated against a
fixed task set before production rollout. See [experiments.md](experiments.md).