You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Part of #58 (the open-to-third-party epic). This is the long pole — the public open is gated on it being solid.
Goal: creators ship custom logic that runs isolated, never touching platform/other-tenant secrets.
Integrate Worker Loader API (Dynamic Workers): store creator source in D1/R2 → load into an isolated V8 sandbox at runtime. NEVER `eval()` inside the platform worker (would run creator code with platform bindings).
Scoped per-tenant bindings + server-side secret injection — creator code sees only its instance's scoped resources; platform/other-tenant secrets are injected server-side and never exposed.
Define the creator-code contract: available tools/bindings, resource limits (CPU/time/subrequests), egress policy (reuse `lib/ssrf.ts`).
Labelled deferred: no demand — not cancelled, and not started.
Per #250 ("the board contradicts the focus bet — make deferred-by-strategy legible"), and #58's own wording, which gates this work on demand rather than on readiness.
The measurement that decides it, taken 2026-08-06 over 30 days (GET /v1/admin/usage/external):
external users: 0
operator calls: 2,782
spend: $40.92 — entirely the operator's own
This issue serves third-party creators. There are none, and nothing on the board measures progress toward getting one. Leaving it as live work makes the roadmap read as if it were in flight, which is precisely what #250 objects to.
The un-gate condition is #68's: external users on a first-party runtime agent. When that number is non-zero, this comes back — the endpoint above makes it checkable rather than a matter of opinion.
Nothing here is judged wrong or wasted. The platform work that already landed (capability registry, connector framework, declarative pipelines, per-tool consent) is what makes first-party agents cheap to build, and it stays. What is deferred is the marketplace layer on top: sandboxing untrusted creator code, curated publish review, payout metering, creator onboarding.
Owner decision on 2026-10-14: retire/defer marketplace work for now. Do not start third-party marketplace expansion, creator-code sandbox, public creator submission/review, payout/metering, or related 3P launch work from this ticket set. Current focus is making first-party runtime agents and core PAGS flows work coherently for real users. Reopen/reactivate marketplace work only with a new explicit owner decision.
❓ The coder stopped on a question: Issue #52 is explicitly deferred by your own directive (2026-10-14): "not started, gated on non-zero external-user count per #68." The run objective says to implement it. How should I proceed?
Options: Lift the deferral — implement #52 fully now (Dynamic Workers sandbox; scoped bindings; metering; tests) · Implement only the scaffolding / contract layer (no live sandbox); so it's ready to activate when demand hits · Keep the deferral — mark this objective as blocked/done-nothing · Cancel this queued objective entirely
Why it asks: The owner's comment on #52 defers all work until a demand signal is met. Implementing it would contradict that decision. Only the owner can lift the deferral.
Answer it on the run's card or with answer_instance_input. The run is parked until it is answered — answer any time; it continues from where it stopped.
Activity
docs: program plan for opening PAGS to third-party agent creators (#58)
serge-ivo commentedon Aug 6, 2026
Labelled
deferred: no demand— not cancelled, and not started.Per #250 ("the board contradicts the focus bet — make deferred-by-strategy legible"), and #58's own wording, which gates this work on demand rather than on readiness.
The measurement that decides it, taken 2026-08-06 over 30 days (
GET /v1/admin/usage/external):This issue serves third-party creators. There are none, and nothing on the board measures progress toward getting one. Leaving it as live work makes the roadmap read as if it were in flight, which is precisely what #250 objects to.
The un-gate condition is #68's: external users on a first-party runtime agent. When that number is non-zero, this comes back — the endpoint above makes it checkable rather than a matter of opinion.
Nothing here is judged wrong or wasted. The platform work that already landed (capability registry, connector framework, declarative pipelines, per-tool consent) is what makes first-party agents cheap to build, and it stays. What is deferred is the marketplace layer on top: sandboxing untrusted creator code, curated publish review, payout metering, creator onboarding.
serge-ivo commentedon Oct 14, 2026
Owner decision on 2026-10-14: retire/defer marketplace work for now. Do not start third-party marketplace expansion, creator-code sandbox, public creator submission/review, payout/metering, or related 3P launch work from this ticket set. Current focus is making first-party runtime agents and core PAGS flows work coherently for real users. Reopen/reactivate marketplace work only with a new explicit owner decision.
proagentstore commentedon Oct 22, 2026
❓ The coder stopped on a question: Issue #52 is explicitly deferred by your own directive (2026-10-14): "not started, gated on non-zero external-user count per #68." The run objective says to implement it. How should I proceed?
Options:
Lift the deferral — implement #52 fully now (Dynamic Workers sandbox; scoped bindings; metering; tests)·Implement only the scaffolding / contract layer (no live sandbox); so it's ready to activate when demand hits·Keep the deferral — mark this objective as blocked/done-nothing·Cancel this queued objective entirelyWhy it asks: The owner's comment on #52 defers all work until a demand signal is met. Implementing it would contradict that decision. Only the owner can lift the deferral.
Answer it on the run's card or with
answer_instance_input. The run is parked until it is answered — answer any time; it continues from where it stopped.