Public source, safety model, lifecycle controller, and examples.
Open ↗Project / Bounded agent execution
ForgeClaw
A framework for supervised agent execution with explicit authority boundaries, observable tool handoffs, evidence capture, verification, and controlled escalation.
01 / Project
ForgeClaw explores how an agent can act on a declared surface, preserve what happened, and require separate evidence before a result is accepted.
Status
Alpha / experimental · v0.1.0-alpha.6 · 2026
Technical focus
- Declared execution surfaces and explicit tool authority
- Bounded action loops with policy checks
- Evidence capture and concrete failure classification
- Acceptance criteria separated from execution success
- Human review and controlled escalation
02 / Design review
Capability is presented with its evidence and boundary.
This record distinguishes what the current project can demonstrate from what remains experimental or unproven.
Problem
- A tool call can return successfully while the actual task remains incomplete, incorrect, or unproven.
- ForgeClaw addresses that gap by separating intent, execution, and verification and by keeping the operating boundary visible throughout the run.
Design approach
- Each session declares its execution surface, objective, permitted actions, and stop conditions before mutation occurs.
- The controller observes, plans, performs one bounded action, records the result, then verifies the observed state against acceptance criteria.
- Structured failure classes preserve useful evidence when a target is unavailable, a surface is unknown, approval is missing, or human review is required.
Boundaries
- Successful tool execution does not automatically mean the result passed verification.
- Unknown surfaces fail closed, and native desktop control is treated as elevated risk and disabled by default.
- ForgeClaw is not a security sandbox, an autonomous correctness guarantee, or permission to expand beyond the declared objective.
Evidence / verification
- Lifecycle artifacts retain requested intent, observed state, action results, expected state, and the verification verdict.
- A public contract-only example demonstrates a no-mutation run where execution completed but acceptance remained unproven and the result was rejected.
- Browser and workflow checks can test URLs, visible text, field values, controls, artifacts, and combined acceptance conditions.
Current limitations
- Visual perception and OCR can misread a target, and weak acceptance criteria can produce weak verification.
- The current lifecycle coordinates separated phases within one controller; it does not claim process-level or security-principal isolation.
- Native desktop automation remains elevated risk and requires deliberate enablement and supervision.
03 / Selected artifacts
Source, notes, and inspectable records.
Selected references connect the project description to its public source, technical notes, and evidence records.
Why intent, execution, and verification carry different authority.
Open ↗Inspectable pass/fail records designed to preserve the reason a result was accepted or rejected.