Agent runtime and pipelines

Every Chat in Kaizen uses an agent and a runtime pipeline. These two ideas explain most behavior in Chat, Agent Studio, and Tasks.

What an agent is

An agent is a reusable configuration. It bundles:

• a persona — instructions and tone,
• a set of tools it is allowed to use,
• a knowledge scope — what it retrieves over,
• a mode — Search or Chat.

Kaizen ships defaults for both surfaces, and members can build their own.

An agent is configuration, not authority. Its tool list is a ceiling; its knowledge scope narrows the runner's access and never widens it.

Runtime pipelines

The agent-runtime service is separate from the backend. Each admitted run uses one controller from a static registry. The admission stays fixed for the run, including reconnect and recovery.

The controller orders model steps, tool requests, compaction, checkpoints, steering, and completion. A shared host executes those requests and applies common budgets, retries, lifecycle rules, and protocol checks.

Controllers do not hold data, secrets, identity, policy, credentials, or tool executors. Consequential work calls the api-backend, which rechecks authority and executes the work with the member's current permissions.

The authority bundle

A run carries a fixed bundle: conversation id, accepted input position, initiating member, selected agent version, audience version, and authorized resource digest.

Every retry, resumed model stream, tool callback, timeout salvage, and terminal publication must present that same bundle. One that borrows a different member, conversation, audience, agent, or resource scope is rejected — not reconciled, not downgraded.

A provider exchange that succeeds at the transport layer but yields neither text nor a tool call receives the same bounded pre-commit retry as another retry-safe provider failure. The retry reuses the exact admitted step snapshot and authority bundle. Visible Thinking alone does not close this retry window. Thinking already shown from an incomplete attempt stays in the member-visible trace. With the turn engine enabled, it is excluded from retry payloads and durable model history, including future turns. Correction-buffered Thinking is discarded when a correction matches, before it becomes visible. The legacy compatibility rollback does not provide the same model-history isolation. Once any answer text, tool call, or external effect is committed, this automatic retry is no longer permitted.

Python owns usage settlement and member-visible terminal publication. A run produces one safe terminal outcome when controller completion and recovery race.

Conditional stream correction

Operators may define a small set of bounded literal response patterns with fixed correction reminders. For a run with those rules, the runtime buffers model-visible response events until the response passes. A match discards the uncommitted response, records only the rule ID, appends the server-authored reminder, captures a new step snapshot, and samples again within the configured correction and model-step budgets.

AGENT_STREAM_CORRECTION_MAX_ATTEMPTS defaults to 1 and is capped at 3. AGENT_STREAM_CORRECTION_RULES is a JSON list of {id, pattern, reminder} objects. IDs, literal patterns, reminders, and count are bounded before a run manifest is authored; matching is case-insensitive and linear-time. The exact rule set and attempt limit are manifest-bound.

Correction happens only before logical commit. A response that already published text or committed an external effect is never rewound. Exhaustion fails the turn instead of releasing the rejected output.

This is a model-quality mechanism, not an authorization control. Backend tool policy, approvals, and publication guards remain authoritative even when no correction rule is configured.

One serialized lane per room

A collaborative chat has one durable first-in-first-out input queue and at most one active agent run.

Sending a normal message while the agent is busy adds a turn to that queue; it never silently changes the active run. An explicit steering action is recorded separately as a steering message and keeps its place in the same queue. It carries the steering member's server-resolved model, runs with the room's selected agent once the run ahead of it settles, and receives its own answer.

Because the queue and its positions live in the conversation journal, two backend replicas cannot start competing turns for the same room. This is the property that makes horizontal scaling of the backend safe.

The browser's live connection is only an observer. Closing a tab, changing screens, or losing the network does not own or cancel room execution. The detached room runner retains the full authority bundle for the life of the run.

Completion notifications use a shared contract across chat, prompt, and task producers. A producer supplies a typed chat, prompt, or task-run destination and an attendance state; it cannot inject an arbitrary navigation URL. The common gate suppresses an attended chat or foreground prompt stream before durable inbox insertion. Presence lookup failure falls back to durable delivery because losing an unattended completion is worse than a duplicate reminder. Exact resource identities also let the client acknowledge only the destination that is actually open.

Actor-specific execution in one shared room

The initiating member is the only authority for a turn. Kaizen rebuilds model context from the durable room journal, then resolves tools, connectors, credentials, confirmation state, approvals, private libraries, packages, and sandbox identity for that member alone.

Project or chat membership never intersects privileges across the room, and a turn can never borrow the owner's authority.

Committed responses, artifacts, citations, and linked resources become shared room content for every active participant. Each response records the initiating agent, model, and effort, so collaborators can identify how it was produced.

Budgets and the synthesis grant

A turn is bounded:

Setting	Default	Bound
AGENT_LOOP_MAX_CYCLES	10	General tool-bearing model rounds per turn; staged creation gets a separate 52-round protocol allowance derived from the artifact size bounds
AGENT_LOOP_BUDGET_MS	120000	Maximum inactivity between healthy model or tool events
AGENT_LOOP_MAX_PARALLEL_TOOLS	1	Concurrent tool calls
LLM_PER_USER_DAILY_TOKENS	0 (unlimited)	Optional per-member daily cap when set to a positive number

When the model-step budget is exhausted, the controller requests one forced synthesis step. The shared host enforces that grant. The answer uses evidence already gathered, and the run records exactly one terminal outcome.

The same single grant covers a model that stops without writing an answer. A run with evidence is re-prompted to synthesize it. A run that called tools but gathered no evidence, which is the usual shape of a request no exposed tool can perform, is re-prompted with a separate instruction: answer without further tools, say plainly what cannot be done and which capability is missing, and do not suggest a retry, unless a tool failed or timed out, in which case say so and that a retry may work. Both texts are authored in the Python policy and applied identically on every agent. The grant is never repeated. With the turn engine enabled, if the re-prompted step is also empty, a run with evidence fails as an empty response and a run without evidence settles as answer_unavailable; the compatibility leg settles both as answer_unavailable. The member-facing fallback asks the member to check the activity before retrying only when a call could have changed something: a write or sensitive tool, a tool with no declared capability, a delegation to another agent (whose own tools the parent run cannot see), or any call that failed, since a delegation that errors or times out reports no detail of what its agent did. Only a run whose calls were all read-only and all completed without delegating drops the suggestion.

Durable tasks enter the same runtime

Run-now and safe-test work does not use a task-only agent loop.

A worker receives one opaque run ID, reacquires short-lived authority for the task owner, resolves the exact agent, saved prompt, or prompt-chain version, and submits a message through the same accepted-input queue and room runner used by native chat.

The run carries a server-owned task_test or task_run posture through the shared model gateway, tool registry, guardrails, budgets, sandbox, journal, and terminal projection. Stable input idempotency lets a worker restart resume the accepted turn without creating a second model request.

Normal runs differ only in unattended policy. Safe tests isolate or deny external writes. Normal runs may reach existing tools, but every external side-effect decision and execution callback must reacquire current task authority first. Missing transient authority blocks; it never falls back to a stored snapshot.

Shared capabilities, not per-agent features

Certain capabilities come from the common runtime rather than from any agent's definition:

• conversation_history_search — authorized prior-work discovery,
• list_available_agents — the member-safe roster,
• task inspection and management, owner-bound,
• the compression settings projection, so any agent can answer questions about its own configuration from authoritative runtime values.

Their scope, timeouts, result limits, and access checks apply uniformly. An individual agent definition never implements its own version.

Delegation

An agent can delegate to other agents in a bounded way — a coordinator hands off sub-tasks and combines the results. Delegation runs under the same permission, budget, and approval limits as any other turn. See Sub-agents & orchestration internals.

Remote agents

In isolated deployments an administrator may enable the A2A proof of concept and register a managed remote agent. Kaizen still dispatches through the same agent-runtime interface, but the selected turn is sent using the A2A protocol.

Remote cards describe skills and media modes. They do not grant access — Kaizen applies member, workroom, registration, and policy checks separately. See A2A & remote agents.

Local and remote completions cross the same terminal answer-normalization boundary before Kaizen persists or emits them. In particular, a requested native file is reported as delivered only when that adapter's member-safe artifact projection contains a matching durable reference. Adapter choice does not weaken the delivery contract.

A note on MCP

Kaizen can record MCP tool descriptors on an agent package, but it does not host or execute those package-declared servers. They remain forward-compatible metadata, not package authority.

Separately, Kaizen discovers administrator-enabled Kamiwaza MCP Guard tools for each run under the initiating member's forwarded platform envelope. Deployment policy and the selected agent's exact tool or server grant both narrow that live inventory. Discovery failure or a missing grant produces no tool; it never falls back to the package runner or a stored credential.

Closed first-party platform adapters are different again. Demo Builder's inspect_kamiwaza and manage_kamiwaza_demo names are source-reviewed in Kaizen's registry and implemented in the trusted backend with the exact-pinned SDK. They are wired only when the agent grants them and the request carries a complete validated platform envelope. Their schemas and bounded result projections—not SDK reflection or package metadata—define the callable surface. The write adapter delegates its six reviewed ensure operations to a Kaizen-owned Demo Reconciler. That service reuses in-process SDK seeding primitives with the already-authenticated client; it does not start the separate operator CLI or load CLI contexts and tokens.