Native config-parameterized deterministic-pipeline agents (the lead-finder shape)

[serge-ivo]

The deeper limitation behind #91/#92, surfaced by the lead-finder (2026-08-02).

Some agents are deterministic data pipelines, not chat/judgment agents: grid-tile a metro → paginate an external API → classify → dedupe → store. This shape:

• can't be config-only — the LLM chat loop is capped (8 rounds) and the logic is mechanical (no language/judgment), so it's inherently code;
• can't be hosted by the platform today — the only options are a hand-written first-party Workflow (closed workflow union) or a standalone external Worker (what the lead-finder is), which the platform can't run, configure, or observe.

So a creator (or the operator) cannot build "a scheduled sweep with these parameters" without a bespoke external repo + deploy. The platform owns nothing about it — its parameters (city, business types, schedule, thresholds) are hardcoded in the worker (GRID = { city: "Melbourne"… }) instead of being settings.

What "configure it yourself" should mean for code agents

• The pipeline logic stays code — but the platform hosts + runs it (sandboxed) rather than it living in an external repo → Tier-2 Dynamic Workers ([3P] Tier-2: sandboxed creator code via Dynamic Workers (CRITICAL PATH) #52). Supply the code once (or via the Coder flywheel: describe → Coder writes → platform runs it sandboxed).
• The parameters become settingsSchema (UI/MCP/prompt-editable): target metro, types, schedule, thresholds.
• The schedule fires it via a trigger→workflow (Triggers: let a cron/webhook trigger run a durable pipeline, not just the 4 canned actions #92).
• The output lands in the instance collection via native storage (readable over MCP, MCP: instance-scoped collection read/write (insert_record/query_records/list_collections) #91).

Ask

• Define the "scheduled pipeline" capability: parameters as settings + a durable runner + collection output, hostable by the platform.
• Land on Tier-2 ([3P] Tier-2: sandboxed creator code via Dynamic Workers (CRITICAL PATH) #52) as the execution substrate; use the lead-finder as the reference migration (external Worker → platform-hosted, parameterized).

Acceptance

• The lead-finder can be rebuilt so its metro/types/schedule are instance settings, its code is platform-run, and its leads land in the instance collection — no external repo.

Part of #58. Depends on #52, #91, #92.

[serge-ivo]

Assessment (2026-08-02). #93 (this) = host creator code + parameterize it (Tier-2 #52) — the escape hatch. Its declarative counterpart is now #94 (no-code pipelines: source→transform→filter→dedupe→sink over connectors #84 + collections #91, fired by triggers #92).

Per #58's principle ("declarative data, never bespoke code"), prefer #94 for the source→transform→sink class (the majority); keep #93/#52 only for logic that genuinely can't be declared. The lead-finder is the reference for both — #94 shows how much becomes pure config (source=Places via generic HTTP #95, transform/filter/dedupe/reachability via #96, geocode #96, sink=collection #91), #93 covers any residual code.

[serge-ivo]

Superseded by #94 ([Epic] No-code declarative data pipelines, CLOSED/shipped) — the pipeline framework + durable runner + audit trail this described (list_pipeline_runs, per-record audit) is built. Closing as a duplicate; #94 is the delivered form.

[serge-ivo]

Update (2026-08-03): the config-only portion of this is no longer blocked on #52. Since this was filed, the declarative pipeline framework (#94/#96/#97/#98/#99) shipped — its step library (geocode → fan_out grid → http_request → enrich/http_reachable → filter → dedupe_upsert) expresses the lead-finder entirely as data, and PUT /v1/instances/:id/pipelines/:name attaches it per-instance. So the lead-finder can be rebuilt as a config PipelineDef with metro/types as parameters — no external repo, no Tier-2 sandbox. Concrete plan + acceptance in #173. This issue can be narrowed to 'Tier-2 for pipelines that genuinely need arbitrary code' (the rest is done).