Skip to content

id(phase-14): Agents in worlds (MCP bridge) — v2 — outline: agents as citizens #6301

New issue
New issue
Open
Open
id(phase-14): Agents in worlds (MCP bridge) — v2 — outline: agents as citizens#6301
Labels
app/idPackage/app: id (pkgs/ or apps/ in this repo)effort/mMedium: expected under 1 day of workkind/featureNew feature or capability requestmeta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedpriority/lowNice to have; do when convenientsource/humanFiled directly by a humanstatus/parkedDeliberately paused with a recorded resume conditiontask/triageQueue packet kind: verify, reproduce, and route this item

Description

@dezren39
dezren39
opened on Nov 5, 2026

Agents in worlds (MCP bridge) — v2 — outline: agents as citizens

Part of the Phase 14 core topic #6280 (Agents in worlds (MCP bridge)), filed from the next-horizons discussion #1240 per Drew's 2026-11-05 decision. The Phase 14 epic links the whole map.

Scope (rough outline — the core topic's research refines it)

Agent roles and permissions as first-class world configuration; per-agent quotas; owner review tooling for agent actions; multiple agents with distinct roles in one world.

Entry condition

The previous step (v1 — first-iteration design + spike plan) has its design written, with open questions answered or explicitly deferred to this step.

Deliverable

An updated, refined outline on this issue — tightened scope, open questions, dependencies — and the next-step issue breakdown when this step's turn approaches. If the step has dissolved into the previous one, close this issue with that note (drop rule).

Drew's Phase 14 principles (#1240) govern this step: local-first always; hostable by anyone at any scale; p2p behavior identical to hosted behavior; our hosted instance is the public backstop, never a requirement.

Acceptance criteria

  • A design outline for this iteration is recorded on this issue (or in a linked design doc) covering scope, non-goals, and the key decisions this iteration must settle.
  • Open questions and decision points needing Drew's ruling are listed explicitly on the issue.
  • Follow-up implementation work is filed as linked issues (native sub-issues / blocked-by relations per protocol §11), not left as prose in this outline.
  • The relationship to the sibling iterations of the same phase-14 topic is linked from this issue.

Activity

  1. dezren39
    added
    kind/featureNew feature or capability request
    status/needs-triageNot yet triaged; needs a first look
    source/humanFiled directly by a human
    priority/lowNice to have; do when convenient
    app/idPackage/app: id (pkgs/ or apps/ in this repo)
    effort/mMedium: expected under 1 day of work
    on Nov 5, 2026

  2. developing-today commented on Nov 5, 2026

    @developing-today
    developing-todayBot
    on Nov 5, 2026 – with developing.today
    Contributor

    CODE-1866

  3. dezren39
    added
    meta/enrichedIntake review done: acceptance criteria, links, and normalized labels added
    on Nov 5, 2026

  4. dezren39 commented on Nov 5, 2026

    @dezren39
    dezren39
    on Nov 5, 2026
    MemberAuthor

    Intake review

    Fleet monitor intake (repo-fleet-monitor, 2026-11-05) — protocol §5 pass.

    • Related: siblings in the same topic: id(phase-14): Agents in worlds (MCP bridge) — v3 — outline: shared agent worlds #6302 (v3), id(phase-14): Agents in worlds (MCP bridge) — v4 — outline: hosted agent services #6303 (v4).
    • Notes: Human-filed phase-14 design outline (Agents in worlds (MCP bridge), v2 — outline: agents as citizens). It already carries kind/feature, source/human, priority/low and an effort class; the missing piece was an acceptance-criteria section, now appended to the body. This is a design-stage item: per protocol §10/§11 nothing here is finished work until the decisions are recorded and implementation issues are filed as native relations.
    • Risks: Outline issues can sit silently — the failure mode the fleet rules call out ("a design with no implementation link is flagged"). The v1→v4 ladder also risks later versions being read as commitments before earlier decisions land.
    • Suggested approach: Work the ladder in order; record each iteration's decisions on its own issue; file implementation issues with native sub-issue/blocked-by links in the same pass; escalate only genuine Drew decisions, with the substance in the message.

    🤖 Agent: fleet monitor · Found via: monitor intake (Duty 2)

  5. dezren39
    added
    queue/queuedHas a queued task in the Supabase agent queue
    task/triageQueue packet kind: verify, reproduce, and route this item
    on Nov 6, 2026

  6. dezren39 commented on Nov 6, 2026

    @dezren39
    dezren39
    on Nov 6, 2026
    MemberAuthor

    🤖 Agent note · picked up

  7. dezren39
    added
    work/assignedQueue worker lifecycle state
    and removed
    status/needs-triageNot yet triaged; needs a first look
    queue/queuedHas a queued task in the Supabase agent queue
    on Nov 6, 2026

  8. 49 remaining items

  9. dezren39
    added
    queue/parkedQueue task is parked (waiting on CI, time, or an event)
    status/parkedDeliberately paused with a recorded resume condition
    and removed
    status/in-progressQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    on Nov 6, 2026

  10. dezren39 commented on Nov 6, 2026

    @dezren39
    dezren39
    on Nov 6, 2026
    MemberAuthor

    🤖 Agent note · handed off

  11. dezren39
    added
    queue/claimedQueue worker lifecycle state
    status/in-progressQueue worker lifecycle state
    and removed
    status/parkedDeliberately paused with a recorded resume condition
    queue/parkedQueue task is parked (waiting on CI, time, or an event)
    on Nov 6, 2026

  12. dezren39 commented on Nov 6, 2026

    @dezren39
    dezren39
    on Nov 6, 2026
    MemberAuthor

    🤖 Agent note · picked up

  13. dezren39
    added
    status/parkedDeliberately paused with a recorded resume condition
    and removed
    status/in-progressQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    work/assignedQueue worker lifecycle state
    on Nov 6, 2026

  14. dezren39 commented on Nov 6, 2026

    @dezren39
    dezren39
    on Nov 6, 2026
    MemberAuthor

    Triage findings (verified fresh 2026-11-06 via gh + current main @ 0819afd)

    Open, correctly scoped, but gated on v1 — not actionable yet. #6301 is the v2 outline in the #6280 version ladder. Its entry condition requires the preceding v1 design (#6300) to be written, with open questions answered or explicitly deferred.

    Disposition: triaged; issue remains open and parked pending #6300.

    🤖 Agent note · triaged

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    app/idPackage/app: id (pkgs/ or apps/ in this repo)effort/mMedium: expected under 1 day of workkind/featureNew feature or capability requestmeta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedpriority/lowNice to have; do when convenientsource/humanFiled directly by a humanstatus/parkedDeliberately paused with a recorded resume conditiontask/triageQueue packet kind: verify, reproduce, and route this item

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions