# Agent Activity

Agent Activity is the unscoped, reverse-chronological view of every agent session in your organization. Use it to monitor what is happening right now and to investigate any specific tool call.

***

### 📖 Key concepts

* **Session**: One delegated run by an agent on behalf of an employee. A session contains one or more tool calls.
* **Outcome**: The resolved outcome of a tool call: **Approved**, **Denied** or **Canceled**.
* **Based on**: How the outcome was reached: **Policy** (auto-evaluated), **Manual Review** (User approved or denied via elicitation), **Timed out** (no response, default Policy applied) or **Fallback policy** (Agent client does not support elicitation).
* **Audit event**: The full record of every Policy that evaluated against a tool call, the inputs and the resolved outcome.

:bulb: *Why this matters*: Per-entity Sessions tabs answer "what did this Agent / Connection / User do?" Agent Activity answers "what is the org doing right now and where do I drill in?"

***

### 📊 The activity view

**Navigation**: Agents → Activity.

**Order**: Reverse chronological by default.

**Columns**:

* **Session name**: assigned by the gateway from the agent's MCP context.
* **User**: the delegating employee.
* **Agent**: the MCP client.
* **Connection(s)**: the downstream apps touched. Multiple Connections per session is supported.
* **Tool calls**: count.
* **Timestamp**: session start.

**Filters**: User, Agent, Connection, plus tool action type, outcome and policies.

***

### 🔍 Drill into a tool call

1. Click any session row to expand the tool call list.
2. Each tool call row shows the tool, action type, app, the policies that evaluated, the outcome, what it was based on and the time.
3. Click a tool call row to open the side panel.

The side panel surfaces three things, all in raw form:

* **Request payload**: exactly what the agent sent.
* **Response payload**: exactly what the downstream app returned.
* **All triggered policies**: name, conditions and outcome for every policy that evaluated.

The full set of policies is what lets you diagnose overlapping rules. Seeing only the rule that decided the outcome hides why the others were considered.

***

### 🛠 Common workflows

* **Triage denials**: Filter to denied tool calls, drill into the side panel and review which policies evaluated and why the call was denied.
* **Investigate a user**: Filter by User, then drill into any session. Or open the user's profile from [Users](/docs/ai-agent-access/how-to-guides/users.md) and use the Sessions tab there.
* **Spot-check an agent**: Filter by Agent, then drill into any session.

{% hint style="info" %}
Real session data depends on the audit-log → Agent Force ETL, which is in progress. Until it ships, Agent Activity renders mocked data. Side-panel payload viewing depends on the gateway storing full payloads in the audit log: an open engineering decision.
{% endhint %}

***

### 🔗 Related pages

* [All Agents](/docs/ai-agent-access/how-to-guides/agents/all-agents.md)
* [All Connections](/docs/ai-agent-access/how-to-guides/connections/all-connections.md)
* [Users](/docs/ai-agent-access/how-to-guides/users.md)
* [Policies](/docs/ai-agent-access/how-to-guides/policies.md)
* [Audit Log](/docs/ai-agent-access/concepts/audit-log.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://www.cakewalk.security/docs/ai-agent-access/how-to-guides/agents/agent-activity.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.