KOT — the harness that refuses skills, MCP and permissions

A single-executable agent harness with a web UI, ten built-in tools and cross-provider orchestration, published by Loqira Labs on 2026-08-20 and tagged v1.0.0 a day later. Its README opens "KOT — simply the best AI harness" and its whole design argument is a list of things it will not do: no sandbox, no permission prompts, no skills subsystem, no MCP.

Read 2026-08-23: 4 stars, 0 forks, 0 open issues, repository three days old. Everything below is the project's own description of itself, and unusually for this spoke there is no way to check it — see What cannot be verified.

Provider as a per-agent role, not a config setting

The pitch is a team split across providers by job, the README's own example table:

Multi-provider support is ordinary in this corpus — oh-my-pi claims 40+, deepseek-harness ships an adapter for rivals, nanoclaw swaps Codex or Ollama per agent group. What is different here is where the dial sits: provider is a parameter on every spawn, every hire, every pipeline step and every team member, so a child starts on a different vendor from its parent and "the parent's model never leaks across providers." Agent{set_model} moves a live teammate to another provider between turns.

That makes provider choice part of orchestration rather than part of installation, and it gives the cost argument in agentsys — a cheaper model plus structure beating an expensive one — a mechanism at the level of the individual subagent. Nobody has measured it. There are no benchmarks, no cost comparisons and no evaluation anywhere in the repository. Corrected 2026-09-16 (claim drain). A measurement now exists, with one qualification. On 4 September 2026 k-kolomeitsev opened PR #9 on frontier-harness-eval/eval, a third-party suite that runs ten harnesses on the same model (Kimi K3 via Moonshot's coding endpoint) over 30 verifier-scored tasks (21 Terminal-Bench, 9 DeepSWE). The submitted KOT row: 23 of 30 (76.7%), the highest pass rate in the table, median $2.83 per pass, 94.1% cache coverage, 5-minute median task time, with a kot-harbor repo holding the Harbor wrapper and fingerprints. The qualification: the PR was still open when checked, and the submitter published KOT's own reproducibility kit, which reads as the harness's side running its own entry — the pattern the hub's "nobody re-runs anybody's numbers" item tracks. So: a number, produced by the interested party, on a neutral suite, not yet merged.

Three refusals

Permissions. "There is no security, and there will not be. The agent runs commands and edits files with the rights of the user who started it." The stated reason is throughput: "an agent that asks for permission every other step does not finish the job, it spends your money on a conversation about intentions." Isolation is delegated outward — "take a ready-made one — a container, a virtual machine, a separate user account … Isolation is a property of the environment, not of the agent."

This is the same premise nanoclaw argues from and the opposite conclusion. NanoClaw says application-level allowlists are not real isolation, therefore ship containers. KOT says application-level gates are not real isolation, therefore ship none and let the operator supply the boundary. Against agent-permission-model's two documented designs — per-action confirmation (13.6% of harmful actions caught) and model-judged auto-approval (89% caught, 11% through) — KOT is a third position with no measurement attached: the gate is removed rather than moved, and whether the operator actually builds the container is outside the product.

Skills. "A skill is a text with instructions that someone wrapped into a separate mechanism with a registry, an installer and versions. You have an agent that reads files and follows instructions." This is a direct rejection of the open skills standard thread this spoke tracks, and it is the first source here to argue the packaging layer is the whole of what skills add. It does not engage the progressive-disclosure argument — that the point is not loading every instruction into context — which is the part agent-skills rests on.

MCP. "MCP is a transport for tools an agent does not have. Here they are built in." The replacement is Tools{add: "cli-wrapper"}, which turns any CLI script — including one backed by a resident process — into a typed tool with parameter validation, "without an intermediate protocol, an extra process and its protocol limits." Tool surfaces are otherwise fixed at ten: Agent, Shell, Search, Files, Plan, Memory, History, Media, Tools, cli-wrapper.

The orchestration surface is the detailed part

Four child kinds, all through one Agent tool (alias Task):

• spawn — synchronous sub-agent, parent blocks, report returns in the same turn.
• delegate — background, returns a launch confirmation, terminal result arrives later as a <task-notification>; addressable and stoppable while running; 12-hour hard lifetime.
• hire — a persistent teammate: a peer session that briefs, sleeps, and is woken by mail. Teammates of one team share a task board.
• workflow — a TOML-declared DAG in .kot/workflows/<name>.toml, laid onto a durable board, ready steps running concurrently, a run surviving restart and resuming by run_id.

Two details carry the design. The until gate: a delegate repeats its turn until a check command exits zero (check = "npm test", max_iterations, timeout), with an optional supervisor agent — itself on a cheaper model — that can accept, send back for rework, or stop the loop. That is verification wired into the spawn call rather than into a prompt. And mail: send delivers to an agent, team:<name>, or orchestrator, queued into the target's re-entry and read at its next turn boundary; a running child can message the lead back. Unknown recipients are a soft refusal returning the roster, not an error.

Pipelines make the declarative-graph shape a first-class peer of runtime fan-out (agent-orchestration), with depends_on edges, transactional worktree steps, on_error = retry/escalate, team steps, nested pipelines, and ask gates that stop and question the owner. Ceilings are stated: 12h timeout, 100 iterations.

Memory, history, and edits that never touch disk

Three memory scopes — project (.kot/agent-memory, shared through version control), user (machine-wide), local (this project, this machine) — auto-loaded at session start. This is the same three-tier split claude-md and agent-memory describe; the difference is that the project scope is a directory of notes the agent writes, not a file the human curates.

The virtual file layer is the unusual piece: agent edits accumulate off-disk and land on an explicit sync, and the layer is rebuilt from the transcript after a restart. Every child gets its own. It buys non-destructive editing without a worktree — although worktrees are also available per child — and it means the transcript, not the filesystem, is the recovery record. Compaction folds the older prefix into a summary, archives the full history first, and is on for sub-agents and off for the main session by default.

What cannot be verified

The repository contains no source code. Its entire tree is three README translations, an assets/ directory, tools/ documentation in English, Russian and Chinese, and releases/ holding prebuilt binaries for Linux x86-64, macOS arm64 and Windows. GitHub reports the repository language as null and no license. So "self-hosted" here means run the binary yourself, not read what you run — and for a tool whose stated position is that it executes with your full user rights, no sandbox and no confirmations, the audit path is closed by construction. That combination is worth naming plainly: the security model is "trust the operator's container," and the operator cannot inspect the thing inside it.

Two smaller flags. The homepage agentkot.ai in the repo metadata fails TLS — it serves a certificate for *.timeweb.ru, so the product site did not load at all on 2026-08-23. And the org bio for Loqira Labs reads "Everyday AI you own, not rent. Runs on your own hardware — no cloud, no frontier API", which is the opposite of KOT, whose headline feature is routing work across Anthropic, OpenAI, DeepSeek and a dozen other hosted APIs at once. Both statements are the same publisher's, three weeks apart.

The tool surface is Claude Code's, field for field

Set the Agent documentation beside claude-code's own. spawn takes description ("short (3–5 word) description of the task"), prompt, subagent_type defaulting to general-purpose, model accepting the aliases sonnet/opus/haiku, effort over off/low/medium/high/xhigh/max (effort-level), and isolation of "worktree" or "remote" — where remote is documented as unavailable. Background results arrive as <task-notification>. ENABLE_TOOL_SEARCH switches on "deferred-tools mode."

The naming, the defaults and the shape of the returned result match Anthropic's harness closely enough that the surface reads as modeled on it — including a parameter carried over with no implementation behind it. This is an observation about the documentation, not a claim about the code, which nobody can read. It does place KOT in the same lineage as mimiclaw, nemoclaw and the other reimplementations this spoke tracks: the harness API is becoming a de-facto interface that clones adopt wholesale, refusals and all.

Provenance and weight

T1 as a first-party publication, but a three-day-old repository with four stars, one release, no source, no license, no users and no independent coverage. The engineering described is specific and internally coherent — the pipeline schema, the mail semantics and the until gate are the level of detail a working system produces, not a mock-up README — and none of it is confirmed to exist. Read this page as a record of a stated design, and re-check the repository before treating any of it as a fact about running software.

Related

agentic-coding-harness · agent-orchestration · agent-permission-model · agent-memory · durable-agents · loqira-labs · nanoclaw · oh-my-pi · deepseek-harness · agent-skills · model-context-protocol · synthesis