Agent Harness API
fharness is the top-level orchestration layer for long-running agent workflows in Fiddlesticks.
It currently supports:
- initializer flow
- task agent incremental loop
- runtime wiring + run-level policy
- reliability + guardrails for production usage
fharness composes lower layers (fmemory, fchat, ftooling, fprovider) into a structured multi-run harness.
Responsibilities
- Run initializer setup for a session (manifest + feature list + progress + checkpoint)
- Run incremental task iterations one feature at a time
- Enforce clean handoff by recording explicit run outcomes
- Coordinate health checks, execution, validation, and persistence updates
fharness does not:
- Implement provider transports (
fprovider) - Implement turn orchestration internals (
fchat) - Implement tool runtimes (
ftooling) - Implement persistence internals (
fmemory)
Add dependency
[]
= { = "../fharness" }
= { = "../fmemory" }
= { = "../fchat" }
Core types
Harness: orchestrator for initializer and task iterationsHarnessBuilder: runtime wiring for provider/chat/tooling/memoryInitializerRequest/InitializerResultTaskIterationRequest/TaskIterationResultRuntimeRunRequest/RuntimeRunOutcomeHealthChecker(NoopHealthCheckerdefault)OutcomeValidator(AcceptAllValidatordefault)FeatureSelector(FirstPendingFeatureSelectordefault)HarnessError/HarnessErrorKind
Initializer flow
run_initializer(...):
- Validates objective and feature list rules
- Builds/versions
SessionManifest - Uses
initialize_session_if_missing(...)for idempotent initialization - Persists initial progress + run checkpoint
If no feature list is provided, Harness generates a starter skeleton via starter_feature_list(...).
use Arc;
use ;
use ;
let memory: = new;
let harness = new;
let request = new;
let _result = harness.run_initializer.await?;
Task-Iteration incremental loop
run_task_iteration(...) executes one bounded run:
- Get bearings
- loads manifest/progress/features from
fmemory - runs health check using manifest
init_plan
- loads manifest/progress/features from
- Picks one highest-priority failing feature (
passes == false) - Delegates execution to
fchat(run_turnorstream_turn) - Validates outcome via
OutcomeValidator - Updates artifacts:
- marks feature passing only when validated
- appends progress entry
- records completed checkpoint with status/note
Integrated runtime and policy ownership
HarnessBuilder wires lower-layer runtime dependencies directly:
- provider (
fprovider) - chat service (
fchat) with transcript storage fromfmemory - tool runtime (
ftooling) - memory backend (
fmemory)
fchat stays responsible for turn orchestration. fharness owns run-level policy:
- phase selection (
initializervstask-iteration) - feature selection strategy (
FeatureSelector) - validation gate before marking feature pass (
OutcomeValidator)
Reliability + guardrails
Harness run policy now supports reliability constraints:
mode(strict_incremental,bounded_batch,unlimited_batch)max_turns_per_runmax_features_per_run(used by strict/bounded modes)retry_budget- fail-fast conditions (
health check,chat,validation)
Mode semantics:
strict_incremental: exactly one feature per run (max_features_per_runmust be1)bounded_batch: process up tomax_features_per_runfeatures in one rununlimited_batch: process features until completion gate or turn/retry constraints stop progress
Completion guardrail:
- harness does not declare done early
- completion requires all required features in
feature_listto havepasses = true
use Arc;
use ;
use ;
let memory: = new;
let harness = builder
.provider
.tool_runtime
.build?;
match harness.run.await?
use Arc;
use ;
let harness = new.with_chat;
let request = new;
let _result = harness.run_task_iteration.await?;
Extensibility hooks
HealthChecker- run startup/baseline checks before task-iteration work
OutcomeValidator- enforce real validation gates before marking features as passing
Use with_health_checker(...) and with_validator(...) to override defaults.
Clean handoff guarantees
Every task-iteration run records terminal outcome artifacts:
- run checkpoint with explicit
status(Succeeded/Failed) and note - progress entry summarizing what happened
This avoids ambiguous handoff state across context windows.
Error model
HarnessErrorKind variants:
InvalidRequestMemoryChatValidationHealthCheckNotReady