Skip to content

AGENTS.md

Latest commit

 

History

History
136 lines (93 loc) · 4.14 KB

AGENTS.md

File metadata and controls

136 lines (93 loc) · 4.14 KB
Raw

Agents — Harness Configuration

Harness endpoint: http://127.0.0.1:7700 Registration: POST http://127.0.0.1:7700/harness/register with X-Harness-Register-Secret Protocol: MCP 2025-06-18 (JSON-RPC 2.0 over HTTP)

This project's agent

Field Value
Agent ID awsysco-python-sdk
Trust level worker
Model tier mid → claude-sonnet-4-6
Privacy tier local_preferred
Memory namespace awsysco-python-sdk-worker
Max steps / session 40
Max cost / session $3.00
Session token TTL 15 minutes (re-register to refresh)

Must escalate (blocks until human approves)

  • create_pr

  • deploy

  • spend

Available tools

See harness/TOOLS.md for full reference with parameter schemas.

  • web_search — search the web via Brave/Google
  • web_fetch — fetch and extract URL content
  • file_ops — read/write files within the project root
  • memory_store / memory_search — per-session key-value memory

Project overrides (harness.yaml)

(no harness.yaml found — using manifest defaults)

How to connect (Claude Code)

The proven way to give a Claude Code session live access to this project's harness identity is harness-ctl mcp-bridge awsysco-python-sdk, registered as a stdio MCP server:

{
  "mcpServers": {
    "harness-awsysco-python-sdk": {
      "type": "stdio",
      "command": "harness-ctl",
      "args": ["mcp-bridge", "awsysco-python-sdk"]
    }
  }
}

Add this to .mcp.json in this project (or globally in ~/.claude.json), then reconnect. This gives the session this agent's RBAC-scoped tools directly — no manual HTTP calls needed. The raw HTTP protocol below is what the bridge does under the hood; use it directly only when building a non-Claude-Code integration.

All registered agents (harness fleet)

Delegation rules

Agents can delegate tasks to peers via A2A (POST http://127.0.0.1:7700/a2a/tasks). Delegation narrows authority — a worker cannot delegate to an orchestrator.

orchestrator  →  can delegate to  →  worker, ephemeral
worker        →  can delegate to  →  ephemeral
ephemeral     →  cannot delegate

This agent (awsysco-python-sdk, trust: worker) can delegate to:

  • ephemeral

HITL workflow

Actions in must_escalate block execution until a human approves:

  1. Call triggers → harness returns a HITL token (HTTP 200, not an error)
  2. Slack DM sent to @here (if configured) with approve/deny link
  3. Human runs: harness-ctl hitl approve <token> or harness-ctl hitl deny <token>
  4. On approve → original tool call executes, result returned to agent
  5. On deny / 30-min timeout → call fails with hitl_denied

Check pending approvals: harness-ctl pending

Working on this project

  1. This file is the canonical harness reference for this project. CLAUDE.md points here for anything harness-related — project-specific rules and conventions live in CLAUDE.md itself, below its harness block.

  2. Reference docs, regenerated by harness-ctl update:

    • harness/TOOLS.md — full tool schemas and error cases
    • harness/SECURITY.md — threat model and controls
    • harness/WORKFLOWS.md — operational patterns, HITL gates, delegation
    • harness/ARCHITECTURE.md — project structure and dependencies
    • harness/TESTING.md — test commands and coverage targets
    • harness/INFRASTRUCTURE.md — deploy targets and environments

Session lifecycle

1. Register    POST /harness/register  →  sessionToken (15 min)
2. Call tools  POST /mcp               →  tools/list, tools/call
3. Run LLM     POST /harness/run       →  routed inference
4. Delegate    POST /a2a/tasks         →  peer agent task
5. Re-register when token expires (budget resets on each new session)