Agentforce D360 Analyze

agentforce-d360-analyze — Data Cloud 360° session view

Hierarchical session reconstruction from Data Cloud STDM + GenAI DMOs for one Agentforce session. Three stages — fetch → assemble → render. Typical wall-clock: ~10–30s for a ~15-turn session.

The pipeline is DC-only: it reads runtime audit rows that Data Cloud has materialized. It is not a runtime-availability tool — see "DC-only blind spot" below for what this skill cannot answer.

If the user hasn't given enough to proceed

When invoked with no session id AND no discovery criteria, print this block verbatim — do not paraphrase, do not pre-run any script. Trigger condition: the input is empty OR contains no session-id shape (neither a UUID nor a 0Mw… messaging id) AND no discovery expression (no time phrase / --agent / --channel / --outcome / --grep / verbs like "find" / "list").

Which session should I pull from Data Cloud, and in which org?

I need:

• Session id — either an Agent Session UUID (019db7f6-…) or a MessagingSession id (0Mw…, 15/18 chars).
  • No session id? — Tell me what you remember and I'll find it: how recent (e.g. "last 2 hours", "today", a date), which agent, which channel (Messaging / Builder / Voice), how it ended (escalated, user ended, transferred, timed out), or a phrase from the conversation. I'll show matching sessions as a numbered list — you pick one, I pull it.
• Org alias — for sf CLI auth (the alias you configured with sf org login).

Artifacts land in ~/.vibe/data/agentforce-d360-analyze/<org_id15>/<agent>__<ver>/<session_id>/ (override per-script with --data-dir <path>).

Session id forms — UUID or MessagingSession id

Both forms are accepted on --session:

Multi-match is real. One MessagingSession id can map to multiple Agent Session UUIDs. On multi-match the resolver prints every candidate and exits non-zero; the user re-invokes with a specific UUID.

Artifacts always land under ~/.vibe/data/agentforce-d360-analyze/<org_id15>/<agent>__<ver>/<session_id>/ (default; overridable per-script with --data-dir <path>) — the messaging id is a lookup key only, never a directory name. The dominant agent (first in sorted(agents_observed)) names the <agent>__<ver>/ segment.

Resolving the script prefix

<SKILL_DIR> = the absolute path to this skill's own directory (the folder holding this SKILL.md); resolve it from the skill path in context and substitute it below. Runtimes install skills in different places (~/.claude/skills/, ~/.vibe/skills/, a plugin cache, a project .claude/skills/), so the block also probes the known install roots at runtime and uses the first that actually contains this skill's scripts. An exported SKILL_ROOT wins.

_skill=agentforce-d360-analyze
for _c in "${SKILL_ROOT:-}" "<SKILL_DIR>" \
          "${CLAUDE_PLUGIN_ROOT:+$CLAUDE_PLUGIN_ROOT/skills/$_skill}" \
          "${VIBES_SKILLS_DIR:+$VIBES_SKILLS_DIR/$_skill}" \
          "$HOME/.claude/skills/$_skill" "$PWD/.claude/skills/$_skill" \
          "${PLUGIN_ROOT:-$HOME/.vibe/skills}/$_skill"; do
  [ -n "$_c" ] || continue
  # Some stagers (ADK eval) nest the bundled files under <skill>/artifacts/.
  for _r in "$_c" "$_c/artifacts"; do
    [ -f "$_r/scripts/fetch_dc.py" ] && { SKILL_ROOT="$_r"; break 2; }
  done
done
[ -f "${SKILL_ROOT:-}/scripts/fetch_dc.py" ] || { echo "$_skill: scripts not found — set SKILL_ROOT to this skill's directory" >&2; exit 1; }
prefix="$SKILL_ROOT/scripts"

Every subsequent invocation in this doc uses "$prefix/...".

Session discovery (no id yet)

When the user doesn't have a session id, run discover_sessions.py against the STDM session DMO. Prints a numbered picker; user picks one; proceed with the chosen UUID.

python3 "$prefix/discover_sessions.py" [--org <alias>] [filters...]

--org is optional. "My org", "our org", or no alias at all means the sf CLI default target org — omit --org and the script uses sf config get target-org. Pass --org <alias> only when the user names an alias. If no default is set the script exits with "no --org given and no default target org set"; relay its sf config set target-org <alias> hint and ask the user for an alias.

Filters (all optional): --since <expr> (default last 24h; accepts "last 2 hours", "today", ISO dates), --agent <api-name>, --channel <Messaging|Builder|Voice>, --outcome <USER_ENDED|ESCALATED|TRANSFERRED|TIMEOUT|NOT_SET>, --grep <substring> (conversation text), --tz <IANA>, --limit <N> (default 20).

Output: markdown table with #, UUID, Start (UTC), Agent, Channel, Duration, Outcome. User replies with a number; proceed with that UUID.

Pipeline — three stages

fetch_dc.py     →  24 dc.<name>.json + dc._session_manifest.json     (DC Query REST waterfall, 5 waves)
assemble_dc.py  →  dc._session_tree.json                             (pure in-memory hierarchical join)
render_dc.py    →  dc._session_summary.md                            (human summary, multi-section)

Each stage is independently runnable. fetch_dc.py --session <sid> [--org <alias>] chains all three by default.

Invocation

python3 "$prefix/fetch_dc.py" --session <session-id-or-messaging-id> [--org <alias>]

--org is optional here too: without it (the user said "my org" or named no alias) the CLI default target org is used. With no default set, fetch_dc.py reports DC_ACCESS_DENIED with reason no_org (exit 10 when headless) — ask the user for an alias and re-run with --org <alias>.

Flags: --verbose for per-DMO row counts; --no-assemble / --no-render to stop early. All entry scripts (fetch_dc.py, assemble_dc.py, render_dc.py, resolve_session.py, discover_sessions.py) accept --data-dir <path> and --cache-dir <path> to override the default ~/.vibe/{data,cache}/agentforce-d360-analyze/ roots — pass these when the host runtime needs artifacts under a different distribution layout.

Output artifacts

Everything lands under ~/.vibe/data/agentforce-d360-analyze/<org_id15>/<agent>__<ver>/<session_id>/ (default; override with --data-dir <path>):

dc.sessions.json              dc.steps.json                dc.gateway_requests.json
dc.interactions.json          dc.messages.json             dc.gateway_responses.json
dc.participants.json          dc.generations.json          dc.gateway_request_llm.json
dc.content_quality.json       dc.content_category.json     dc.gateway_request_metadata.json
dc.tags.json                  dc.tag_definitions.json      dc.gateway_request_tags.json
dc.tag_associations.json      dc.tag_definition_associations.json
dc.feedback.json              dc.feedback_details.json     dc.gateway_records.json
dc.moments.json               dc.moment_interactions.json
dc.telemetry_spans.json       dc.app_generation.json

dc._session_manifest.json     (per-DMO row counts + empties)
dc._session_tree.json         (hierarchical join — session → interactions → steps → messages → generations → gateway)
dc._session_summary.md        (rendered human summary)

Zero-row queries are recorded in the manifest with status: empty; no file is written. assemble_dc tolerates missing files. See references/artifacts.md for the full read order.

The DC-only blind spot — read before committing to a root cause

DC alone answers what happened — steps that ran, generations that fired, gateway requests that were logged. It does NOT answer what could have happened but didn't:

• Which topics were eligible for the classifier on a given turn (this lives in runtime planner telemetry, not DC).
• Which actions were declared on a topic vs. which survived rule expressions and were actually offered to the LLM.
• Why the LLM picked one topic/action over another (the full prompt + response text only lives in the planner runtime telemetry).

If the user's question is about why a particular topic or action was or wasn't used, DC-only is almost never sufficient. Tell the user: "Availability questions need the runtime planner trace for that turn — which is outside this skill's Data Cloud surface. Check the platform telemetry that mirrors the planner's logged decisions." Don't fabricate a root cause from runtime-only evidence.