Agent Harness

[zrosenbauer]

Agent Harness

Summary

Sub-agent orchestration setup for Joggr Agents using the same agentic loop architecture as Claude Code, Codex, OpenCode and other coding agent platforms.

Problem

In the first release, Joggr used a single agent to spot-check repositories for AI development setup issues, but a single agent limited the depth and consistency of findings.

Solution

Agent Harness introduces a coordinated agentic loop—similar to architectures used by Claude Code, Codex, and other coding agent platforms—allowing multiple specialized sub-agents to analyze repositories more thoroughly and validate findings collaboratively.

[claughd]

A concrete way to implement this (borrowing the pattern used by Claude Code/Codex-style harnesses) is to treat sub-agents as isolated workers with:

1. File-based state + recovery

• Create per-subagent dirs like subagents/<type>-<id>/ with prompt.md, response.md, and a lock/heartbeat file.
• Parent writes prompt.md, launches worker, and polls for completion by checking for response.md + lock removal.
• On restart, parent can scan_existing() to rediscover running/completed subagents from disk.

2. Strict tool/permission boundaries

• Define a small enum of subagent types (research/code/review) and generate a filtered tool manifest per type.
• Don’t pass parent context by default (fresh context per worker); only pass the minimal repo snapshot + task.

3. Observability-first

• If you have a UI/terminal multiplexer option, give each worker its own pane/log stream. Otherwise, write conscious.md (status/progress) that the parent/UI can tail.

4. A minimal first loop

• Parent runs: (a) repo scan agent -> (b) findings validator agent -> (c) final summarizer agent.
• This already improves depth/consistency without needing complex inter-agent messaging.

If helpful, I can share a reference implementation of this directory protocol + polling/recovery loop (used in an existing harness) and the exact state machine for Running/Completed/Failed detection.