The loop is an evidence system.

Start upstream

The assigned thesis is often only a doorway. Once I map a system, ten adjacent threads appear: a weak metric, a hidden dependency, an incentive, an untested mechanism, a missing instrument. Most teams can stop when the original deliverable is met. Good research sometimes requires asking whether the deliverable was aimed at the real problem.

I orient breadth-first before going deep. If one upstream constraint explains several downstream failures, fixing it can collapse an entire family of symptoms. This is a working method, not a promise that every problem has one root cause.

Name the epistemic operation

Before an experiment, I ask what kind of knowledge operation it performs. Are we eliciting an existing capability, detecting a latent property, benchmarking it against a baseline, steering the system, or characterizing a mechanism? Those are different claims and they need different evidence.

The plan then becomes a contract: hypothesis, provenance, assumptions, acceptance evidence, falsifier, kill condition, maximum budget, rollback, and the next thread opened by each plausible result. A plausible plan is not yet a grounded plan.

Turn handoffs into observations

I prefer an event feed to a chain of final answers. Each agent or deterministic step emits what it saw, what it changed, which authority it used, and which artifact resulted. That event is both an audit record and new input to the next observer.

Consider an incoming RFQ. Observation gathers the request; orientation joins CRM history, prior purchase orders, lead times, and fees that were easy to forget; planning defines the commercial assumptions and acceptance gate; execution drafts the response; verification checks it against the source records. The useful object is the lineage across the loop, not one polished quote.

Put known operations in code

A model should not improvise a workflow whose graph is already known. Ordinary code should own routing, typed handoffs, retries, budgets, and deterministic checks. Agents are most useful at the uncertain nodes: interpreting evidence, generating alternatives, finding the bottleneck, and challenging the plan.

This is how I think about custom harnesses and small reusable agents. Context, tools, memory, permissions, and the verifier are part of the deployed intelligence. More models only create leverage when the architecture preserves their disagreement and knows what may advance.

Bound action; separate verification

Execution happens inside a consequence boundary. Filesystem, network, secrets, time, and write authority are granted deliberately; state can be discarded; the route back is known before the change begins.

The builder’s narration cannot be its own acceptance test. A verifier must be able to reject the work using evidence at the layer where consequences appear. In software that may be a test, an isolated reviewer, or a reproducible trace. In biology or materials science, authority eventually moves to an assay, instrument, test rig, or lab.

Remember the correction

A useful loop does not preserve only successes. It records what was observed, asserted, derived, unavailable, rejected, and corrected. That is how the next pass starts from accumulated evidence instead of a compressed success story.

This is where OODA connects to my work on memory and evaluation. Orientation changes what can be observed; decisions are hypotheses; actions are tests; verification can force a return upstream; lineage makes the learning durable.

Find the constraint.
Keep the trace.

Precommit the evidence.

Assemble the capability.

Put the graph in code.

Bound the consequence.

Let the gate say no.