Agent Session

How it works in practice

A roadmap🛣️RoadmapProduct SpecificationA strategic plan of features and milestonesView reference →-triage agent runs nightly. Tonight's agent session opens with a fixed context (the current backlog, the latest metrics🔢MetricStrategyA unified metric that measures progress, health, or behaviour across the productView reference →), makes nine tool calls, and ends by proposing that two low-traffic features⭐FeatureProduct SpecificationA product capability or featureView reference → be deprecated. That proposal is captured as a decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference →, and the session is the evidence🔎EvidenceValidationData supporting or refuting a hypothesisView reference → behind it: the transcript shows which metrics the agent read and how it reasoned to the recommendation. Tomorrow's session starts fresh from the same definition, with new context and a new transcript. Each run stands alone, so when someone asks why a feature was flagged, the answer points to one dated session rather than to "the agent" in the abstract.

Agent session vs. its neighbours

• Agent definition is the reusable specification; the session is one execution of it. A definition persists across hundreds of runs; a session is a single, bounded, time-stamped event with a transcript.
• Decision is an output a session can produce. The session is the activity and its full record; the decision is one durable conclusion lifted out of it for the product to act on.
• AI trace🪡AI TraceAI & Machine LearningAn AI inference traceView reference → is the fine-grained telemetry of model calls, tokens, and latency within a run. The session is the unit of work and its narrative; the trace is the instrumentation beneath it, used for debugging and cost rather than product reasoning.

In the graph

In the Unified Product Graph, an agent session sits in the automation region and is the execution record of its agent. It connects upward through agent_definition_runs_agent_sessionAgent DefinitionrunsAgent Sessionhierarchy, tying every run to the specification that produced it, and outward through agent_session_creates_decisionAgent SessioncreatesDecisioncross-domain, linking a run to any decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference → it generated. Modelling the session as its own entity, distinct from both the definition above it and the decisions it yields, gives the graph a clean audit trail: you can trace any agent-made decision back to the exact run that produced it, and any run back to the agent that was allowed to make it.