Status: Proposal Scope: extension design, extension/runtime capability fit, non-code gap analysis
Session names currently reflect either an explicit manual label or a fallback based on recent user text. As work progresses, the purpose of a session can shift substantially while the visible session name lags behind. This makes session trees, resume flows, and long-running work harder to scan.
We want an extension that keeps a session name aligned with the session's current purpose without adding user-facing noise or mutating the source conversation.
For each eligible session, after every N completed prompt-lifecycle turns,
when the session has returned to :idle, the extension evaluates whether the
session name should change.
Default:
N = 2The evaluation runs in the background. If it succeeds and the result is still current, the original session name is updated to a terse phrase describing the current purpose of the session.
If it fails, the original session remains unchanged.
A session is eligible when all of the following hold:
A completed turn is one source-session assistant turn that has fully completed
on the shared prompt lifecycle and returned the session to :idle.
Implications:
The current purpose is the best terse description of what the session is now trying to achieve, based on user-visible conversation content.
When the source session reaches the rename threshold:
The rename workflow must capture enough source-session state to detect staleness before applying the result.
The marker should identify the source snapshot used for inference, for example:
Exact representation is an implementation detail, but the workflow must be able to answer: "Has the source session advanced since the rename evaluation began?"
If yes, discard the result.
The rename inference must use a sanitized view of the source session.
The rename inference should run in an internal helper context rather than in the source session itself.
Required properties:
Preferred shape:
Recommended prompt:
Based on this conversation, what is the current purpose of the session? Reply with only a terse phrase of 2–8 words. No quotes. No explanation.
The result should be treated as invalid if it does not satisfy the response contract.
A proposed title is valid when it satisfies all of the following:
Suggested defaults:
Apply the proposed rename only when:
For each source session:
This must be explicit. Recommended v1 policy:
Alternative policies are possible, but the system should not silently oscillate between user intent and automatic renaming.
On helper-run failure, validation failure, or stale-source detection:
This feature adds one extra model inference every N completed turns per
eligible session.
To bound cost and churn, v1 should support:
NSuggested extension configuration:
:enabled? — default true:turn-interval — default 2:max-title-chars — default 60:min-words — default 2:max-words — default 8:helper-model — optional override:manual-name-policy — default :suppress-when-manual:debug-visibility? — default falsePrefer an event-driven workflow over timer polling.
Preferred trigger model:
A scheduler may still be useful for debounce/coalescing, but a blind periodic polling loop is not the preferred architecture.
This section evaluates whether the current architecture appears to provide the necessary pieces for the design.
The system appears to have most of the major building blocks needed for this extension, but not yet all of them as a clean extension-facing path.
Current fit:
Present
The platform already exposes the ability to set a session name.
Fit
Strong. This part appears ready.
Gap
The current visible model appears to support a name string, but the design also benefits from name metadata such as:
manual vs auto)Without this metadata, conflict handling between user renames and automatic renames will be brittle.
Present
The platform appears to support child/helper session creation and execution in an isolated context.
Fit
Strong, conceptually.
Gap
The design needs a clean distinction between:
If helper sessions are visible in normal session navigation, the feature will introduce noise and confusion.
Present
The runtime already has workflow-backed background jobs and job reconciliation.
Fit
Moderate to strong.
Gap
The extension needs a simple canonical way to express:
These are architectural policies on top of the current job substrate and should be made explicit.
Present
A scheduler primitive exists in the runtime/dispatch layer.
Fit
Moderate.
Gap
It is not yet clear that extensions have a clean, direct, high-level scheduling surface for "run this rename evaluation after the next eligible idle boundary" or "debounce repeated triggers".
This may not block the feature if workflow/background execution can be triggered from lifecycle events, but it does mean that "use the scheduler" is currently a design preference rather than a clearly complete extension surface.
Present
The prompt lifecycle is explicit and completed-turn semantics exist in the architecture.
Fit
Moderate.
Gap
The design needs a canonical extension-observable hook for:
If extensions do not currently receive a clean event at that semantic boundary, then the runtime is missing the most natural trigger surface for this feature.
This is the single most important likely gap.
Present
The system already distinguishes user-visible display content from some command noise, and transcript/message projections exist.
Fit
Moderate.
Gap
The extension needs a canonical sanitized conversation view tailored to purpose inference, not merely a raw journal dump.
Needed semantics include exclusion of:
If each extension has to reconstruct this on its own, behavior will be inconsistent and fragile. A shared projection or query surface would make this feature much cleaner.
Present
Helper contexts and extension workflows exist, so recursion can likely be avoided by convention.
Fit
Moderate.
Gap
The design needs an explicit way to mark helper contexts as internal and make extension triggers ignore them. Without a standard marker, recursion prevention will be ad hoc.
Present
The architecture already values explicit routing and traceable lifecycle stages.
Fit
Moderate.
Gap
The extension needs a stable source revision marker or equivalent read-model so it can determine whether the source session advanced during the helper run.
Without a canonical notion of "source snapshot version", stale overwrites are more likely.
Present
Session names exist.
Fit
Weak.
Gap
There does not appear to be a first-class naming policy model. The proposed feature needs one, even if minimal.
At minimum, the architecture should answer:
Present
The UI and background-job systems can surface status if desired.
Fit
Moderate.
Gap
This is optional for v1, but operationally useful. If the extension silently fails all renames, users may not know whether the feature is disabled, blocked, or merely finding no better title.
A lightweight optional observability surface may be desirable later.
These are not code-level prescriptions; they are capability-level additions that would make the extension clean and robust.
Completed-turn extension event
Sanitized conversation projection
Internal helper-session marker
Name metadata / policy model
High-level extension scheduling/debounce surface
Source revision marker
This extension is viable, but it should be treated as a feature that will also clarify a few missing extension/runtime seams.
Recommended path:
With those pieces in place, the extension should be straightforward and architecturally consistent.
Can you improve this documentation?Edit on GitHub
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |