Opportunity Scout — Grounded proposals with approval before action

The problem

Finding suitable work involves repetitive screening and drafting, but a proposal also makes factual claims and may incur a submission cost. Automating the reading is useful; granting the same autonomy to external commitments requires stronger controls.

I designed Scout to prepare work for a decision while keeping that decision with me.

The system I designed

Scout reads opportunities, applies rule-based filters and a model fit assessment, then drafts from an owner-reviewed facts file. Validation checks structured claims such as numbers, links, project names and bid amounts. The owner receives the draft and cost through a private approval interface.

A separate Software Factory extension structures delivery work into requirements, acceptance, planning, implementation, validation and handoff. Scout's opportunity workflow and the Factory's delivery workflow are connected, but their maturity and evidence are reported separately.

Engineering decisions

Check authority before the tool call. Reading an execution transcript afterward cannot undo an unauthorized external action. The model's request must pass the application's gate before the connector executes it.

Bind approval to the actual action. A prior button, revised draft or changed price must not silently authorize a different submission. State transitions and atomic claims protect against stale controls and repeated taps.

Treat uncertainty as a stop condition. An ambiguous write outcome should pause the workflow rather than trigger an automatic retry that could duplicate the action.

Use validation without overstating it. Matching a number to a fact is useful, but a free-form sentence can still make an unsupported claim. Human review remains necessary.

A failure that changed the design

Review found paths where tool permissions, inherited settings or absent hooks could undermine the intended write gate.

The execution configuration was tightened around project-only settings, restricted connector access and an explicit pre-execution permission decision. The reviewed configuration denied the tested action when its hook was silent or absent. Later preflight work checks for conflicting settings before a process starts.

The lesson is broader than one prompt: an approval promise needs enforcement in the execution path and tests of the denied path.

What this demonstrates

Scout combines model-assisted preparation with application-owned authority. Its engineering spans provenance, approval state, tool permissions, retry behavior, redaction and recovery.

Role and limits

I conceived Scout and the delivery workflow, defined what may be claimed or submitted and retained approval over external commitments. Coding agents performed substantial test-driven implementation and cross-model review.

It is a private system for one operator. Providers and connectors can interrupt it. Automated claim checks are incomplete, and the evidence does not establish higher earnings, proposal conversion or fully autonomous client delivery.