Harness Agents

A harness agent is an autonomous, software-engineering-oriented agent built on the Microsoft Agent Framework harness (create_harness_agent()): a tool-calling loop with a persistent todo list, plan/execute mode tracking, file-based session memory, jailed file access, Agent Skills, shell execution, hosted web search, context compaction, tool approval, and a keep-going-until-the-todos-are-done loop -- all assembled behind one factory call.

Harness agents are the third declarative kind, next to Declarative Agents (kind: Prompt) and Declarative Workflows (kind: Workflow): a kind: Harness YAML in the same DECLARATIVE_AGENTS_DIR folder. The rule stays the same: the YAML is a specification, and ChatWalaʻau owns every input -- the model client, credentials, tools, workspace directories, and skills are always resolved by ChatWalaʻau, never taken from the file.

What you get

• An agent that works a task list. The harness plans, tracks todos, switches between plan and execute modes, and re-invokes itself until the todos are done (bounded at 10 iterations).
• A real workspace. With CODING_WORKSPACE_DIR set, the agent gets jailed file-access tools and a shell scoped to your workspace, plus file-based session memory (agent-file-memory/) for notes that persist across turns. Without the directory, those capabilities simply don't exist.
• Approvals you already know. File writes and shell commands raise the same approval card as everything else in ChatWalaʻau -- nothing executes unattended. Read-only tools never prompt.
• Composable in a GUI. Create and edit harness agents in the same management modal as your other agents (they carry a HARNESS tag), with a full-screen editor: form panels for instructions and the building-block switches, a canvas showing the model, tools, and enabled blocks, and a live canonical YAML preview.
• Run in chat as a run-target. Activate a harness agent in the modal and your next message runs it -- the composer shows Harness: <name> and hides the per-message model controls, because the YAML fixes the model. Selecting a harness agent and a workflow are mutually exclusive; activating a regular agent clears both.

A minimal harness agent

kind: Harness
name: repo-fixer
displayName: Repo Fixer
model:
  id: gpt-5.3            # exactly ONE catalog offering
instructions:
  agent: |
    Focus on this repository. Prefer small, verifiable changes.
tools:
  - function:weather_get_current   # optional: built-in tools / whole MCP servers
mode:
  initial: execute       # plan | execute
loop:
  maxIterations: 10      # capped at 10

Drop it into DECLARATIVE_AGENTS_DIR (or use the GUI) and it appears in the management modal. Anything the file gets wrong -- an unknown model, an unknown tool, an out-of-range budget -- is a blocking warning: the agent is listed, but cannot be selected until you fix it.

What ChatWalaʻau decides for you

Concern	Policy
Chat history	In-memory per conversation (reset on restart)
Todo list / loop	Always on; loop runs while todos remain, max 10 iterations
File / shell tools	Only under CODING_WORKSPACE_DIR; writes need approval
Skills	Loaded from SKILLS_DIR
Web search	On by default, but obeys the per-model capability gate
Token budgets	From the offering's context_window unless the YAML narrows them
Credentials / provider	Always ChatWalaʻau's -- never read from YAML

Harness agents are SPA-only for now: the OpenAI-compatible API and Teams keep following the active regular agent. In demo mode, harness agents are visible but read-only.