Skip to main content
Use these tools when the user asks “what changed?”, “what happened?”, or “why does this run this way?”

​
What an observation is

An observation is a captured execution of a process — a real session, attached to a specific process and version. The activity timeline is the underlying sequence of user actions that produced the observation — the systems they used, what they did, when. If you only call one tool from this group, call get_observation_citation on a top observation. It is the closest thing the workspace has to a video replay. It only works for your own sessions.

​
Common chains

  • State-of-team brief: get_recent_process_changes → drill into specific processes via fetch or get_process_details
  • Deep-dive on a process: get_process_observations (summary mode, scan the friction signals) → pick the most relevant → re-call with verbosity="full" for the narrative, or jump straight to get_observation_citation for the activity timeline
  • Confirm a transformation candidate: get_process_observations for exception patterns → get_observation_citation to confirm the manual pattern with concrete evidence

​
Cite what you find

Observations have timestamps and version pointers. When the user asks “what’s the evidence?”, surface the observation timestamp and the version it was logged against — that’s a citation the user can audit in Within.

​
Deviations

Each observation carries the agent’s per-session understanding of how that run compared to the documented process:
  • Positive deviations — places where the user went beyond the documented path in a useful way: a shortcut, a better validation step, a quality-improving move worth promoting.
  • Negative deviations — friction or workarounds: an extra manual step, a retry, a small fix to keep moving.
Both are judgments made in isolation against one session’s activity timeline. Per-session friction often looks routine on its own, so negative_deviations is frequently empty on individual observations even when a pattern is present across many sessions.

​
How to use deviations

A single observation gives you the single-session view. The signal most teams want — “the same workaround appears on 4 of 5 captures,” “this retry is systemic” — is cross-observation deviation analysis: the surface-level patterns that only emerge when you aggregate across the observation set for a process. Two paths:
  1. Within Advisor does this aggregation natively across the workspace.
  2. MCP-stitched: pull get_observation_citation across the observation set for the process, then diff against the pinned process version yourself. The MCP exposes everything Advisor reads — the cross-observation pass is what you stitch.