# Dashboard & activity > Use the shared workspace to inspect connected devices, recorded agent activity, and the context behind findings. Source: https://docs.agentbeam.com/agent-cli/dashboard The dashboard is your team's shared view at [app.agentbeam.com](https://app.agentbeam.com). It receives records from connected devices. Local Studio remains useful for activity retained on the machine, including records that did not reach the workspace during a network failure. ## Open the right workspace Sign in and check the workspace identity before investigating activity or changing policy. Your current workspace role controls the visible navigation and server-authorized actions. A workspace member can connect a personal device without receiving the security team's activity access. **Overview** summarizes the workspace. **Setup** helps connect an Agent CLI device and request enterprise MDM access. CLI pairing and MDM activation are independent; a device appearing under Agents is not proof of OS management enrollment. ## First sign-in and setup New accounts answer a short survey once. One question, **Do you write or ship code?**, decides which setup Beam shows, both in onboarding and in the connect window on the Overview: | Answer | Setup shown | | --- | --- | | Yes | **CLI** (protect AI coding agents), **Extension** (protect AI in the browser), and **App** (monitor your apps). The App monitoring page appears in the sidebar, with its settings under **Settings, apps and alerts**. | | No | **Extension** only, without the coding-tools question. App monitoring stays out of the sidebar. | People who joined before the question existed see every option. Reopen the connect window at any time with `?connect=cli`, `?connect=extension` or `?connect=app` on the Overview URL. To send someone straight to one setup, link to `https://app.agentbeam.com/start?intent=` followed by `app`, `agents` or `browser`. The link works from any state: - A signed-out visitor signs in or creates an account, finishes the survey and workspace setup, then lands on that setup. - Someone already set up goes there directly. The intent waits in a short-lived cookie and only accepts those three names, so the link can't redirect anywhere else. It's also recorded on the account, which lets you see what brought people in. ## Investigate activity Open **Activity** to browse the records available to your role. Use the page's filters and event details to narrow the relevant agent, time, or risk. Read the summary and findings together with the source and phase of the original event where available. A captured proposed command establishes what the assistant requested, not what the operating system completed. Heuristic findings identify patterns for review. Confirm effects using additional endpoint or provider evidence when the investigation requires it. ## Review sessions and get tips Open **Sessions** to see each agent session as a list of prompts and the actions taken under them. Members see their own sessions; roles with activity access see the workspace's. Sessions only appear for devices on a recent `beam` CLI; older records stay in Activity. Each session shows the model it ran on under the agent (and on its detail page), when the agent reports one. If a session switched models, the most recent shows first with a `+N` count, and search matches any of them. Above the list, **How to improve your sessions** ranks tips by the share of recorded actions each one affects, the same way Claude Code's own usage tips work: - **Start fresh when you switch tasks** (`/clear`): the topic changed partway through a session. - **Compact long sessions** (`/compact`): 8 or more prompts, or 150 or more actions. - **Point the agent at the right files**: the same file was read three or more times in one session. - **Break retry loops**: the same command ran four or more times in one session. - **Turn off MCP servers you don't use** (`/mcp`): MCP calls are 30% or more of actions. - **Pick one model per session** (`/model`): a session changed models partway, which drops the prompt cache so the conversation is read again at full price. - **Use a lighter model for routine work** (`/model`): reads and command runs were handled by an Opus-class model. - **Move to the latest model** (`/model`): a session ran on a Claude model older than the 5.x line. - **Review flagged actions**: sessions with findings that need a look. Tips are rule-based and computed from the sessions already shown, with no model involved and nothing extra collected. A tip appears only at 5% or more of actions, and none show until a workspace has at least 20 recorded actions. A tip is a pattern to look at, not a verdict: re-running tests is often normal. Select **Hide** on the panel to collapse it; your choice is remembered in this browser. ## See usage by person (owners) Workspace owners get **People usage** under Monitor. It lists each person's tokens, estimated cost, prompts (coding agents and AI websites), and efficiency: tokens, cost and agent actions per coding-agent prompt. A person using more than twice the workspace median tokens per prompt is highlighted. Pick a period at the top. Only owners see the page and its navigation entry; administrators and other roles are redirected. Website prompts carry no token data, and cost uses list prices for the models agents report. ## Review and remove skills Open **Skills** to see every skill reported by your devices, with its risk score, the **person** it belongs to, and the device it is on. Owners, administrators and security managers (`devices:write`) can also act on a skill: - **Remove from device.** Select one skill, or tick several rows (or **Select all matching**) and choose **Remove selected**. Nothing is deleted when you click: the request is queued, and the device deletes the skill folder at its next minute-long poll, re-indexes and reports again, after which the skill leaves the list. A queued request shows **Removal queued** and can be cancelled until the device carries it out. Nothing is ever queued unless a person does it, and every request is written to the audit log. - **View SKILL.md.** The text of a skill is not stored by default. Choose **View SKILL.md** and the device sends that one file at its next poll, with secrets redacted and cut at 64 KB. It is shown to people with `devices:write` only, and the request is audited. If the skill changes afterwards, the file is marked out of date until you request it again. **Removal and file viewing need beam v0.2.36 or newer on the device.** An older beam ignores the request, so it stays queued and runs once the device updates; the Skills page warns you when a device is behind, and you can update it from **Devices & agents** (below). On the device, `beam` only deletes a folder that holds a `SKILL.md` inside your home folder or a place it searched, and it only acts on skills from its own inventory, never on a path from the workspace. A linked skill loses the link, not the folder it points to. Set `BEAM_SKILL_REMOTE_ACTIONS=0` on a device to stop it carrying out removals and file requests. Owner data stays hidden from other roles until an owner shares it, here as everywhere. ## Check beam versions and update devices **Devices & agents** has a **Beam versions** panel: every connected device with the person it belongs to, the beam CLI version it last reported, and whether it is up to date against the newest npm release. Devices on a beam from before version reporting show **Not reported** until they update (background auto-update does that by default for interactive installs). Owners, administrators and security managers (`devices:write`) can select devices, or choose **Update all behind**, to queue an update to the latest release. Each device installs that exact version at its next poll with `npm install -g`, never asking for `sudo`, and a supervised background service restarts itself afterwards; the request clears when the device reports the new version. A failed install (for example a global folder that isn't writable) is shown on the row and not retried for 30 minutes. Standalone binaries and source checkouts can't update themselves, so they report that instead. Every request is audited, and a queued update can be cancelled before the device installs it. Set `BEAM_REMOTE_UPDATE=0` on a device to stop it carrying out dashboard-requested updates, and `BEAM_DISABLE_AUTOUPDATE=1` for background auto-update. ## Inspect connected devices Open **Agents** to review registered devices and their status. A registered identity means the CLI paired with the workspace; it does not establish continuous capture, a healthy hook, or complete forwarding. Compare recent local activity with dashboard records when diagnosing a silent device. Authorized operators can revoke a device from this page. Revocation removes its remote access, not its local installation or every historical record. Follow the [offboarding guide](https://docs.agentbeam.com/agent-cli/uninstall) for complete retirement. ## Move from activity to review Use **Risks** for flagged records, **Policies** for workspace restrictions, and **Audit log** for administrative changes. These views answer different questions: what was observed, how it was assessed, what policy is configured, and who changed the configuration. Session scorecards and agent evaluation are not implemented in the current dashboard backend. Do not interpret activity totals or a reviewed finding as a per-session compliance score. ## When data is missing Verify `beam whoami`, `beam account`, collector status, and a real hook event in Studio. Enrolled forwarding is best-effort and has an in-memory batch; it does not guarantee replay after an outage. Use a redacted local export as separate evidence when needed.