Claude Code's Agent View, /goal Command, and Background Sessions: A Practical Guide

Anthropic shipped a significant Claude Code update in May 2026 that fundamentally changes how developers manage AI-assisted work: Agent View, the /goal command, and background sessions. Together, these three features move Claude Code from a single-session coding assistant to a genuine multi-agent orchestration platform. Agent View gives you a real-time visual display of all active agents and their current tasks. The /goal command lets you describe a high-level objective and have Claude Code automatically decompose it into subtasks and execute them in sequence. Background sessions let you launch agents that run independently while you work on other things — you get notified when they complete. For most Claude Code users, the day-to-day workflow changes substantially with these features. You're no longer limited to one thing at a time. You can set a goal, let Claude Code decompose and execute it, and simultaneously work on a different feature in a separate session — with both running in parallel. This post is a practical guide to each feature: what it does, when to use it, and how to integrate it into your vibe coding workflow for maximum leverage.

What You'll Learn

You'll understand exactly how Agent View works and how to use it to monitor and manage multiple active agents, how to write effective /goal prompts that produce well-decomposed task execution rather than one large undifferentiated implementation, how background sessions work technically and how to structure your work to take advantage of parallel execution, the practical workflows that become possible with these features that weren't possible before, and common pitfalls and how to avoid them when orchestrating multiple Claude Code agents simultaneously.

Agent View: Monitoring Your Agent Fleet

Agent View is a persistent UI panel in Claude Code that displays all active agents, their current task, and their execution status. Before Agent View, managing multiple Claude Code sessions meant switching between terminal windows and losing track of what each agent was doing.

How Agent View works:

Agent View panel shows:
├── Agent name/ID: auto-generated or set with /agent-name [name]
├── Current task: what the agent is currently executing
├── Status: THINKING | READING | EDITING | WAITING | DONE | ERROR
├── Progress: subtask completion if launched via /goal
├── Duration: how long the current session has been running
└── Last action: most recent tool call (e.g., 'Read: src/app/page.tsx')

Opening Agent View:
├── Keyboard shortcut: Ctrl+Shift+A (Mac: Cmd+Shift+A)
├── Command: /agent-view
└── Auto-opens when you launch a background session

Agent statuses explained:
├── THINKING: model is reasoning, about to make a tool call
├── READING: agent is reading files (Glob, Grep, Read tool calls)
├── EDITING: agent is writing or editing files
├── WAITING: agent hit a checkpoint and is waiting for your input
├── DONE: agent completed its task successfully
└── ERROR: agent encountered an unrecoverable error (needs attention)

When an agent reaches WAITING or ERROR:
├── Agent View highlights it with a notification badge
├── You can click into the agent to see the context
├── Provide input or guidance and the agent resumes
└── Error agents show the specific error and suggested resolution

Practical use of Agent View:

Scenario: You have 3 agents running simultaneously
├── Agent 'auth': Implementing Supabase authentication (EDITING)
├── Agent 'tests': Writing acceptance tests for auth (READING)
└── Agent 'docs': Generating API documentation (DONE)

Your workflow:
├── Glance at Agent View — 'auth' is editing, 'tests' is reading, 'docs' is done
├── Review 'docs' output while 'auth' and 'tests' are still running
├── When 'auth' hits WAITING (needs your input on RLS policy decision),
│   Agent View notifies you, you provide guidance, agent resumes
└── When 'tests' completes, Agent View shows DONE — review and merge

Time saved: ~2-3 hours vs. sequential execution of the same 3 tasks

---

The /goal Command: High-Level Task Decomposition

The /goal command is the biggest workflow change in this update. Instead of prompting Claude Code with a specific implementation task, you describe a high-level engineering objective and Claude Code decomposes it into an ordered execution plan.

Syntax:
/goal [high-level objective]

Example:
/goal Add a comment system to the blog. Users can post comments,
reply to other comments, and upvote. Use Supabase. Include
RLS policies, TypeScript types, and component tests.

What Claude Code does with /goal:
1. Analyzes the objective against the current codebase
2. Generates a decomposed task list:
   Task 1: Create Supabase migration for comments table + RLS policies
   Task 2: Generate TypeScript types from Supabase schema
   Task 3: Build CommentList, CommentItem, CommentForm components
   Task 4: Implement upvote API route with rate limiting
   Task 5: Wire components into blog post pages
   Task 6: Write component tests for CommentList and CommentForm
3. Confirms the task list with you before executing
4. Executes tasks in sequence, surfacing blockers for your input
5. Reports completion with a summary of what was built

Writing effective /goal prompts:

Weak /goal prompt (underspecified):
/goal Add authentication

Result: Agent makes assumptions about:
├── Which auth provider to use
├── Which routes to protect
├── Whether to use sessions or JWTs
└── How to handle auth errors

Strong /goal prompt (well-specified):
/goal Add Supabase authentication to this Next.js app.
Requirements:
- Email/password login and Google OAuth
- Protected routes: /dashboard, /profile, /settings
- Redirect to /login if not authenticated
- Redirect to /dashboard after login
- Session persists across browser refresh
- Display user email in the header when logged in
Do NOT modify the existing API routes or database schema.

Result: Agent decomposes accurately:
├── Task 1: Configure Supabase auth providers (email + Google)
├── Task 2: Build login page and auth forms
├── Task 3: Add auth middleware for protected routes
├── Task 4: Update header component to show user email
└── Task 5: Test each auth flow end-to-end

Key elements of a strong /goal prompt:
├── Clear objective (what, not how)
├── Explicit constraints (what NOT to do)
├── Success criteria (what does 'done' look like?)
├── Technology choices specified (Supabase, not 'some auth provider')
└── Scope boundaries (which files/features to include or exclude)

---

Background Sessions: Agents That Run While You Work

Background sessions let you launch a Claude Code agent that executes independently while you continue working in your primary session. The agent runs in the background, uses the same file system, and notifies you when it completes or needs input.

Launching a background session:

Method 1: Explicit background flag
/goal --background Refactor the src/utils/ directory to use
TypeScript strict mode throughout. Fix all type errors. Don't
change any function signatures.

Method 2: Background command on existing prompt
> Write unit tests for all functions in src/utils/
/background  (runs current prompt as background agent)

Method 3: Background from Agent View
├── Click 'New Background Agent' in Agent View panel
├── Enter the task description
└── Agent launches and appears in Agent View as THINKING

What happens during background execution:
├── Agent runs using Claude Opus 4.7 (same model as foreground)
├── Agent reads, analyzes, and edits files on your local file system
├── Changes are made directly to your working directory
├── If agent needs input, it sends a notification and enters WAITING
├── When done, notification appears: 'Agent [name] completed: [summary]'
└── You review the changes like a code review, accept or request revision

Important: background agents share your file system
├── Two agents editing the same file simultaneously = conflicts
├── Best practice: assign non-overlapping file scopes to each agent
│   Agent 1: src/components/ only
│   Agent 2: src/app/api/ only
│   Agent 3: src/utils/ only
└── Agent View shows which files each agent is currently editing
    to help you avoid conflicts

---

Practical Workflow: Combining All Three Features

Here's how the three features work together in a real development session:

Scenario: Building a notification system for your app

Step 1: Set the primary goal
/goal Add a notification system. Users receive in-app notifications
for: new comments on their posts, replies to their comments, and
weekly digest. Notifications persist in Supabase. Mark as read
functionality. Notification bell in header with unread count badge.

Claude Code decomposes into 6 tasks. You review and approve.

Step 2: Launch parallel background agents
While the main agent (foreground) works on Supabase schema + RLS:

/goal --background Write the notification bell component
and mark-as-read UI. Use the Notification type from
src/types/notifications.ts (agent 1 will create this file).
Poll for updates every 30 seconds.

/goal --background Write acceptance tests for the notification
system. Test: unread count increments on new notification,
mark as read updates count, weekly digest sends at correct time.

Step 3: Monitor in Agent View
├── Foreground agent: EDITING (creating Supabase migration)
├── Background agent 1: READING (found types file, building component)
└── Background agent 2: THINKING (designing test structure)

Step 4: Handle the WAITING state
Foreground agent hits WAITING:
'Should weekly digest notifications be stored in the same
table as real-time notifications or a separate audit log table?'

You provide guidance: 'Same table, add a type column:
real-time | digest'
Agent resumes.

Step 5: Review completed agents
├── Background agent 2 (tests) completes first: DONE
│   Review: tests look comprehensive, merge to working branch
├── Foreground agent completes: DONE
│   Review: migration + types + API routes, all correct
└── Background agent 1 (component) completes: DONE
    Review: component works, but uses wrong polling interval
    Request revision: 'Change polling to 60s, not 30s'
    Agent revises and marks DONE

Total wall-clock time: ~90 minutes
Sequential execution would have taken: ~4 hours

---

Setting Up for Background Sessions

Prerequisites:
├── Claude Code version 1.8+ (includes Agent View and /goal)
│   Update: npm update -g @anthropic-ai/claude-code
├── Active Claude Pro or Max subscription (background sessions
│   use Opus 4.7 and count toward your monthly usage)
└── CLAUDE.md configured with your project context
    (background agents rely heavily on CLAUDE.md since they
     can't ask clarifying questions as easily)

Recommended CLAUDE.md additions for multi-agent work:

---
# Agent execution context
## File scope
- This agent should only edit files in [YOUR_SCOPE]
- Do not edit files outside this scope without explicit permission

## Completion criteria
- Task is complete when: [YOUR_CRITERIA]
- If blocked on a decision, WAIT for input rather than guessing
- Always verify TypeScript compiles before marking complete

## Conflict avoidance
- Before editing a file, check if it appears in Agent View
  as being edited by another agent
- If conflict detected, WAIT and report the conflict
---

Common Challenges

'Background agents keep editing the wrong files.' — This is the most common issue when starting with background sessions. The fix is explicit scope boundaries in your /goal prompt and in CLAUDE.md. Add 'Only edit files in src/components/ — do not touch any other directories' to every background agent prompt. Agent View shows which files each agent is editing; check it when you notice unexpected changes. 'The /goal decomposition doesn't match what I wanted.' — This usually means your /goal prompt was underspecified. Review the decomposition before approving it: if a task is too broad ('implement the backend') or too narrow ('add a single validation check'), refine the /goal prompt and regenerate. It takes 2-3 tries to write /goal prompts that consistently produce good decompositions. 'Background sessions use too much of my API quota.' — Background agents running Opus 4.7 are expensive on long tasks. For lower-stakes background work, use /model claude-sonnet-4-6 before launching the background session. Sonnet 4.6 is 3-4x cheaper and performs well on well-specified implementation tasks. 'Agent View shows ERROR — what do I do?' — Click into the errored agent to see the full error context. Most errors fall into three categories: (1) file not found — the agent referenced a file that doesn't exist yet; (2) TypeScript error — the agent's output doesn't compile; (3) tool timeout — a network or filesystem operation took too long. In most cases, provide context and the agent recovers. If it can't, start a new session with what you learned from the error.

Advanced Tips

Name your agents for easier management. Use /agent-name [name] at the start of each session — 'auth', 'tests', 'components'. Agent View becomes much more readable when you know which agent is doing what without reading the task description. Pre-write your CLAUDE.md agent sections before launching parallel agents. The more complete your CLAUDE.md is, the less often background agents will hit WAITING states requiring your input. A background agent that runs to completion without intervention is the goal. Use background sessions for tasks with clear, verifiable output. Background agents work best on tasks where 'done' is objectively measurable — tests pass, TypeScript compiles, a specific file exists with specific content. They're less reliable on tasks that require aesthetic judgment ('make the UI look better') because there's no objective completion criterion. Chain goals for complex multi-phase projects. Use /goal for Phase 1, review the output, then use /goal again for Phase 2. Don't try to express a 3-day project as a single /goal — the decomposition becomes too complex and agents make more mistakes. Treat /goal as a sprint planning tool: each goal is one sprint's worth of work, well-specified and bounded. The Vibe Coding Academy Module 11 (Multi-Agent Development) includes hands-on exercises for all three features — Agent View, /goal, and background sessions. Complete walkthroughs from setup to parallel agent orchestration. Stay current on Claude Code updates at EndOfCoding — we publish practical guides with every major Claude Code release. Reference workflows and prompt templates are in the Vibe Coding Ebook Chapter 5 (Tool Landscape), updated to reflect the May 2026 Claude Code release.

Conclusion

Agent View, /goal, and background sessions collectively represent the most significant Claude Code update since the product launched. Together they transform Claude Code from a smart single-session assistant into a lightweight multi-agent orchestration platform that any individual developer can use without infrastructure setup or additional tooling. The practical impact is immediate: tasks that used to take 4 hours now take 90 minutes when you can run 3 agents in parallel. The /goal command removes the overhead of breaking down complex features into prompts — you describe the outcome, Claude Code handles the decomposition. And background sessions finally let you use the time AI agents are working on something, rather than waiting for them to finish. The learning curve is real — effective multi-agent orchestration requires better specs, clearer scope boundaries, and more systematic verification than single-session vibe coding. But the payoff is proportional. The Vibe Coding Academy Advanced Track is updated with hands-on exercises for all three features. For ongoing Claude Code coverage and vibe coding technique updates, follow EndOfCoding.