Domain model: definitions and executions

Start with the problem

A single long prompt hides who is authorized to act, which part of a task failed, and whether a rerun is safe. Kaigents separates reusable definitions from execution instances so a team can review a capability once, run it many times, and inspect each outcome independently. This distinction comes from the product domain model; not every proposed domain relation is implemented by the current chart.

Who, what, how, and with what

• Agent: the actor definition—system prompt, model reference, and attached Tool names. A human reviewer is a participant in a gated workflow, not a general-purpose Agent resource in the chart.
• Team: named bindings to Agents. It groups actors but does not by itself specify supervisor, debate, or parallel-merge semantics.
• Task: a reusable prompt and agentName, with an optional requiresGate flag; it is not an execution history.
• Process: ordered Task references with step identifiers. Its chart schema does not encode arbitrary branching.
• Skill: a reusable methodology rather than an Agent identity or Process sequence. The source operator has Skill support, but the published chart does not install its CRD.
• ModelEndpoint: a pointer to an existing model service, not a model installation. MCPServer describes a server endpoint; Tool maps a Kubernetes name to a server-advertised tool name.
• Run: the instance that requests work. Run.status contains observed phase, outputs, and optional artifact references. The current chart accepts only Agent and Team targets.

A concrete relationship

Define a ModelEndpoint and Agent, then create a Run targeting that Agent. The operator resolves references in the Run namespace, builds an execution contract, creates a runner Job, and reflects its outcome in Run.status. A Process can refer to Tasks, but the chart currently rejects Process as a Run target; the Temporal Work Request adapter is a separate way of executing ordered Work Items. Do not assume a Process manifest automatically starts a Temporal workflow.

Why separate definitions from instances?

• Changing an Agent prompt should not rewrite the historical status of a previous Run.
• A missing Tool or ModelEndpoint should be diagnosable as a reference or connectivity problem, not mistaken for poor model quality.
• The same Agent can serve distinct Runs with different inputs and optional model overrides.
• Approvals belong to a specific execution and decision, not a blanket promise encoded only in a Task description.

Version boundary

The product model also describes Roles, Personas, Workspaces, Quality Gates, and Work Requests with richer coordination. Those concepts are design vocabulary, not automatically installed CRDs or guaranteed workflow behavior. Always compare the Helm chart schemas with operator/api/core/v1alpha1 and the Temporal adapter before implementing against a conceptual diagram.