If you cannot classify an agent session, you will eventually lose track of it.
That is not a tooling problem. It is a labeling problem.
The more sessions you run across Claude Code and Codex, the more important it becomes to have a simple taxonomy for naming, searching, and archiving those runs. Without one, session history turns into a pile of similar-looking titles and half-remembered outcomes.
Why taxonomy matters
A good taxonomy gives you three things:
- faster search
- cleaner handoff
- better review habits
If you know what kind of session you are looking at, you can answer the right question faster. Is this a bug fix, a refactor, an investigation, or an automation candidate? Is it safe to stop? Is it ready to archive? Does it belong on desktop, or can it stay mobile-first?
Junction is useful here because it keeps session history attached to the actual local work, rather than forcing you to reconstruct the story from memory.
The fields worth standardizing
You do not need a complex schema. You need a few stable categories.
Intent
Intent is the reason the session exists.
Useful intent labels include:
- bugfix
- refactor
- docs
- investigation
- automation
- review
This is the most important field because it tells you what the session was trying to accomplish.
Risk
Risk tells you how careful the session needs to be.
Simple risk labels might be:
- read-only
- edit
- shared-state
- external-side-effect
That is enough to separate a harmless investigation from a migration or release step that deserves more attention.
Lifecycle
Lifecycle describes where the session is in its life.
Common states are:
- queued
- active
- waiting-approval
- blocked
- complete
- archived
That makes it much easier to search for work that needs attention versus work that is already done.
Surface
Surface tells you how you expect to interact with the session.
For example:
- desktop
- mobile
- overnight
- shared
This matters in Junction because the browser is not just a viewer. It is the control surface for the run.
Owner or target
You may also want to record the repo, branch, or machine involved.
That helps when you are managing multiple daemons or multiple repositories and do not want every session to look the same.
A practical naming pattern
Here is a lightweight pattern that works well:
intent-risk-repo-target
Examples:
bugfix-edit-api-failing-testrefactor-shared-web-auth-flowdocs-readonly-site-pricing-copyautomation-edit-switchboard-issue-routing
The exact format matters less than the consistency. The goal is to make a title searchable without forcing you to open every run.
How the taxonomy helps search
Once the labels are consistent, you can sort sessions by the kind of question you are asking.
For example:
- show me all blocked sessions
- show me all shared-state runs
- show me all automation candidates
- show me the last docs session on the site repo
That is much faster than scanning a wall of vaguely similar names.
It also makes archive and resume workflows more practical. If a run is archived, you should still be able to recover its intent quickly later.
A concrete example
Suppose you have three active sessions:
- Claude Code fixing a flaky test in one package
- Codex updating a docs page and preparing a PR
- Claude Code investigating a branch drift issue after a failed merge
Without taxonomy, those are just three sessions.
With taxonomy, they are different operational objects:
- bugfix / edit / active / desktop
- docs / read-only / waiting-approval / mobile
- investigation / shared-state / blocked / desktop
That difference matters when you are deciding what to do next.
What taxonomy is not
Taxonomy is not bureaucracy.
If the labels do not help you find, route, or review work faster, they are too detailed. The point is not to build a perfect ontology. The point is to keep the operational story readable.
That is why a small number of categories usually beats a giant custom schema.
How Junction supports the habit
Junction keeps the live stream, approvals, Git state, and notifications in the same environment, so the labels can stay attached to the actual work.
That makes it easier to build a mental map of your sessions over time:
- what kind of work you run
- which runs need review
- which ones belong on mobile
- which ones should stay local and isolated
The more sessions you manage, the more valuable that map becomes.
A good rule of thumb
If a session title would make sense to someone who was not in the room, it is probably good enough.
If the title only makes sense after you remember the whole conversation, the taxonomy needs work.
That is a useful standard for Claude Code and Codex runs alike because it keeps history searchable even when the details of the original prompt fade.
Next step
If you want to make the taxonomy useful in practice, start with the setup guide and then compare pricing. For a related workflow, read Archive AI Agent Sessions Without Losing History.