Designing "Explore" Mode: Define by Entry, Not by Fences
I run a small multi-agent dev setup (my-ai-team) with three session modes: team (planner/developer/reviewer relay), adhoc (one agent owns the whole delivery cycle), and explore. The explore mode is still an RFC — we haven't shipped it yet. But the design already taught us something useful about how to scope agent autonomy.
The first draft was all negatives
The obvious way to define an investigation-only mode is to list what it can't do: no issues, no branches, no PRs, report findings and stop. That works — until it doesn't.
The problem: there's always a case the fence didn't anticipate. If poking at a bug turns up a one-line fix, the rules force an awkward choice between "break protocol and just fix it" or "hand off to a separate session for a trivial change." Neither is right.
Define by entry condition instead
The fix was to redefine explore by how it starts, not what it's forbidden from doing. Team and adhoc carry a delivery obligation from the first message — they begin with a predefined task. Explore enters from an open topic with an uncertain goal. That's the only difference.
That single shift dissolves the fence. The mode now has several legitimate exits — adjourn with findings, park a ticket for later, or hand work off to delivery — and none of them needs a special-case rule, because none contradicts the definition.
The gate is the ticket, not the PR
The hard part of any "investigation that might turn into work" mode is the autonomy boundary: when is the agent allowed to commit to real consequences?
The answer turned out to be a primitive we already had. Opening a ticket is a serious act. A ticket without a blocked label is a clear signal that delivery may run all the way to merge. A ticket with blocked means "real, but the timing isn't ripe." So the gate isn't a new checkpoint bolted on before the PR — it's the ticket's own blocked/non-blocked status. No new machinery, and the decision lives where the seriousness already lives.
The ticket as a membrane
We also cut the scope so explore never writes delivery code. Its output ceiling is a (possibly newly created) repo plus one or more detailed tickets. Implementation always belongs to adhoc or team.
The ticket becomes a membrane: explore writes it, delivery consumes it, and no single prompt is asked to be both an investigation prompt and a delivery prompt. The detail written into the ticket carries the discussion's context across the handoff.
A nice side effect: no repo → no ticket → no PR. The repo is a precondition for a ticket, the ticket is the delivery gate, so a discussion that never produces a repo simply can't produce delivery. That's a valid ending, not an error to guard against.
Two smaller things worth keeping
Gate autonomy on reversibility and blast radius, not on who's human. The instinct was "two agents shouldn't land work without a person in the loop." But the honest axis is actor-neutral: an irreversible, wide-blast-radius action deserves a second check regardless of whether a human or an agent is driving it. Publishing a ticket, by contrast, is reversible and low-blast — it needs no special gate.
We designed explore by spending an hour inside it. The session had actually booted under the adhoc prompt, but because we kept the conversation open-ended and goal-uncertain, it behaved exactly like the mode we were inventing. It ended, fittingly, by publishing a single ticket and nothing more.