17  New in Claude Managed Agents: Schedules and Vaults

17.1 Time-Based Execution and Secure Secrets

On June 9, 2026, Anthropic announced two more additions to Managed Agents: Schedules and Vaults. Where earlier features (Chapters 11–14) focused on execution, memory, quality, and connectivity, these two addressed the operational essentials of running agents in production: when they run and how they handle secrets.

Schedules let agents run on cron-defined timetables, enabling proactive and recurring work without human initiation. Vaults let agents use credentials and environment variables securely, without ever seeing the actual secret values. Together, they rounded out the production-readiness story for Managed Agents.

This chapter covers both features, their mechanics, and the CLI integrations announced alongside them.

17.2 Schedules: Agents on a Timetable

17.2.1 What Schedules Do

Scheduled deployments let you run agents on a cron schedule — the same time-based scheduling system used by Unix cron. Instead of an agent running only when invoked by a user or application, a scheduled agent runs automatically at defined times.

# Conceptual schedule configuration
schedule:
  cron: "0 2 * * *"           # Every day at 2:00 AM
  agent: security-scanner
  task: "Scan the codebase for new vulnerabilities and open issues for findings"

The cron expression defines when the agent runs; the agent configuration defines what it does. Once set up, the agent runs on schedule without further intervention.

17.2.2 Why Schedules Matter

Schedules transform agents from reactive tools (they run when you ask) to proactive services (they run when needed, automatically). This enables a class of use cases that were previously impractical:

Use Case Schedule Value
Nightly security scan Daily at 2 AM Catch vulnerabilities without manual effort
Weekly dependency audit Every Monday Stay on top of outdated/vulnerable deps
Hourly log analysis Every hour Detect anomalies in near-real-time
Monthly compliance report First of month Generate reports automatically
PR review on open Event-triggered* Review code as soon as it’s submitted

(*Event-triggered scheduling uses webhooks or proactive loops — Chapter 4 — rather than cron, but the principle is the same: the agent runs without human initiation.)

Note

Schedules are the infrastructure that makes proactive loops (Chapter 4) practical in production. An agent that runs nightly to scan for vulnerabilities is a proactive loop — it monitors and acts without human initiation. Managed Agents’ schedule feature provides the reliable execution infrastructure (cron parsing, failure handling, retry) that makes this dependable.

17.2.3 Schedule Execution Model

When a scheduled agent runs:

  1. The schedule triggers at the defined cron time.
  2. A new agent session starts with the configured task.
  3. The agent executes — doing its work, using tools, producing output.
  4. Results are delivered via configured channels (webhooks, stored results, notifications).
  5. The session ends — each scheduled run is a discrete session.

This model means each scheduled run is independent — the agent starts fresh (though it can access memory, Chapter 12, for accumulated knowledge). Failures in one run don’t affect the next.

17.3 Vaults: Secure Secret Management

17.3.1 The Secret Problem

Agents frequently need credentials and secrets to do their work: API keys for external services, database passwords, authentication tokens, cloud provider credentials. In a traditional setup, these secrets are provided as environment variables — but that means the code (and the agent) can read them, creating several risks:

  • Exposure in logs: If the agent logs its environment, secrets leak.
  • Exposure in prompts: If the agent includes environment variables in its context (e.g., to reason about configuration), secrets enter the model’s context.
  • Exposure in outputs: If the agent writes configuration files or error messages, secrets may be written to disk.
  • Broad access: Any tool the agent calls has access to all secrets in the environment.

The fundamental issue is that if the agent can see the secret, the secret is at risk — of leaking, of being used inappropriately, of being exposed through the agent’s behavior.

17.3.2 How Vaults Solve It

Vaults securely store environment variables and credentials such that the agent never sees the actual key. The mechanism:

  1. Secrets are stored in a vault — a secure, managed store.
  2. In the sandbox, a placeholder is provided instead of the real secret.
  3. At the network boundary, when a call is made to an external service, the real key is attached — substituting the placeholder.
┌─────────────────────────────┐
│  Vault (Secure Storage)     │
│  API_KEY = "real-secret..." │
└──────────┬──────────────────┘
           │ (secret stays here)
           │
    ┌──────┴───────────────────────────┐
    │   Network Boundary               │
    │   (substitution happens here)    │
    └──────┬───────────────────────────┘
           │
           │ placeholder ↓    real key ↑
           ▼
┌─────────────────────────────┐
│  Sandbox (Agent Execution)  │
│  API_KEY = "placeholder"    │  ← Agent sees only placeholder
│                              │
│  Agent calls external API   │
│  with API_KEY="placeholder" │
└─────────────────────────────┘

The agent operates with placeholders — it knows a secret exists (by name) but never sees the value. When the agent’s code makes a network call that uses the secret, the network boundary substitutes the real value transparently.

Tip

The vault pattern is a significant security improvement because it follows the principle of least exposure. The agent doesn’t need to see the secret to use it — it just needs to reference it by name. By substituting at the network boundary, vaults ensure secrets are used correctly without ever entering the agent’s context, logs, or outputs. This is the agent equivalent of how cloud platforms manage service accounts — the code references a role, the platform provides the credentials.

17.3.3 Benefits of Vaults

Benefit Description
Agent never sees the secret Placeholders in sandbox; real keys at network boundary
No secret leakage in logs Placeholders are logged, not real values
No secret leakage in prompts Secrets never enter the model’s context
Centralized management Secrets stored and rotated in one place
Scoped access Control which agents can use which secrets

17.4 CLI Integrations

Alongside schedules and vaults, the announcement included CLI integrations that expanded what managed agents could do. Several popular tools and services were now accessible to agents via their CLIs:

CLI What It Enables
Browserbase Browser automation — agents can browse the web, interact with pages
KERNEL [Platform-specific integration]
Notion Read and write Notion pages, databases
Ramp Access financial data, expense management
Sentry Query error data, manage issues

These CLIs are configured in the agent’s environment (with credentials stored in vaults) and become tools the agent can use. This dramatically expands the range of tasks agents can accomplish.

17.4.1 Browser Capabilities: A First

The Browserbase integration was particularly notable because it gave managed agents browser capabilities for the first time. Previously, managed agents could call APIs and execute code but couldn’t drive a web browser — limiting them to tasks with API access. With browser capabilities, agents can:

  • Navigate websites that don’t have APIs.
  • Interact with web UIs (click buttons, fill forms, extract data).
  • Perform web research by actually browsing, not just calling search APIs.
  • Automate web-based workflows (data entry, scraping, form submission).

This opened a vast new space of use cases — any task that a human would do in a browser can now be done by a managed agent.

17.5 How Schedules and Vaults Compose

Schedules and vaults work together naturally in production deployments:

  1. A scheduled agent runs nightly (schedule).
  2. It needs credentials to access external systems (vault).
  3. The vault provides placeholders in the sandbox; real keys are substituted at the network boundary.
  4. The agent does its work — securely, automatically, on schedule.
# Combined schedule + vault configuration
deployment:
  schedule:
    cron: "0 2 * * *"
  agent: nightly-auditor
  task: "Audit all cloud resources for compliance and report findings"
  vault:
    - name: AWS_CREDENTIALS
      placeholder: true
    - name: SLACK_TOKEN
      placeholder: true
  tools:
    - bash
    - browserbase
    - sentry

This configuration defines a nightly audit that runs automatically, uses credentials securely (via vault), and can browse the web (via Browserbase) and query error data (via Sentry).

17.6 Production Readiness

With schedules and vaults, Managed Agents reached a level of production readiness that covered the essential operational concerns:

Concern Feature Chapter
Execution Sandboxes (managed or self-hosted) 11, 14
State Built-in state management 11
Memory Built-in memory 12
Quality Outcomes (rubric-based grading) 13
Complexity Multiagent orchestration 13
Connectivity MCP tunnels 14
Timing Schedules 15
Secrets Vaults 15

Together, these features mean organizations can deploy agents that run reliably, securely, on schedule, with accumulated knowledge, graded quality, and controlled execution — all without building the infrastructure themselves.

17.7 Schedules in Depth

Scheduled execution transforms agents from reactive tools into proactive services. Let’s examine the practical considerations in depth.

17.7.1 Cron Expression Primer

Schedules use cron expressions — the standard time-based scheduling syntax from Unix cron. Understanding cron syntax is essential for configuring schedules.

A cron expression has five fields:

┌───────────── minute (0–59)
│ ┌───────────── hour (0–23)
│ │ ┌───────────── day of month (1–31)
│ │ │ ┌───────────── month (1–12)
│ │ │ │ ┌───────────── day of week (0–6, where 0 = Sunday)
│ │ │ │ │
* * * * *

Common schedule patterns:

Cron Expression Meaning
0 2 * * * Every day at 2:00 AM
0 9 * * 1 Every Monday at 9:00 AM
0 0 1 * * First day of every month at midnight
0 */6 * * * Every 6 hours
*/30 * * * * Every 30 minutes
0 9,17 * * * Every day at 9:00 AM and 5:00 PM
Tip

When designing schedules, consider timezone. Cron expressions are typically interpreted in UTC. If your team is in a specific timezone, adjust accordingly. A “nightly at 2 AM” schedule means 2 AM UTC, which may be mid-day in your timezone. Always verify the effective local time of your schedules.

17.7.2 Schedule Reliability

Scheduled agents must be reliable — if a schedule doesn’t fire, work doesn’t get done. Managed Agents provides:

  • Guaranteed execution: Scheduled runs are queued and executed even under load.
  • Retry on failure: If a scheduled session fails (e.g., due to a transient error), it’s retried.
  • Missed schedule handling: If the service was unavailable when a schedule should have fired, the missed run can be caught up.
  • Health monitoring: Dashboard visibility into whether schedules are firing on time.

17.7.3 Session Isolation Between Runs

Each scheduled run is a discrete session — independent of previous runs. This means:

  • No context bleed: A failure in one run doesn’t affect the next.
  • Fresh start: Each run begins with a clean context (though it can access memory).
  • Independent results: Each run produces its own results, archived separately.

The session isolation is important for reliability. A scheduled security scanner that crashes on Tuesday doesn’t affect Wednesday’s scan — each runs independently.

17.8 Vaults in Depth

The vault architecture — where the agent never sees the real secret — is a significant security improvement. Let’s examine how it works in practice.

17.8.1 The Placeholder Mechanism

When a vault is configured, the agent’s sandbox environment contains placeholders instead of real secrets:

# In the sandbox environment:
AWS_ACCESS_KEY_ID=vault:aws-access-key-id
AWS_SECRET_ACCESS_KEY=vault:aws-secret-access-key
DATABASE_URL=vault:production-database-url
SLACK_TOKEN=vault:slack-bot-token

The agent sees that these variables exist (by name) but the values are references to vault entries, not the actual secrets. The agent can use these variables in code — when it makes an AWS API call using AWS_ACCESS_KEY_ID, the call works correctly.

17.8.2 The Network Boundary Substitution

When the agent’s code makes a network call that uses a vault-protected variable, the network boundary intercepts the call:

  1. The agent’s code makes a network call using AWS_ACCESS_KEY_ID (which contains the placeholder).
  2. The network boundary recognizes the placeholder format (vault:...).
  3. The boundary looks up the real secret in the vault.
  4. The boundary substitutes the placeholder with the real secret.
  5. The network call proceeds with the real secret — transparently to the agent.

The agent’s code works correctly; the secret is used; but the agent never saw the real value.

Agent Code:        api.call(key=os.environ["AWS_ACCESS_KEY_ID"])
                               │
                               ▼ (placeholder: "vault:aws-access-key-id")
Network Boundary:  intercept → lookup in vault → substitute
                               │
                               ▼ (real key: "AKIAIOSFODNN7EXAMPLE")
External Call:     api.call(key="AKIAIOSFODNN7EXAMPLE")

17.8.3 Security Benefits in Detail

The vault architecture provides defense-in-depth against secret exposure:

Risk Without Vaults With Vaults
Agent logs environment Secrets leak to logs Placeholders logged (no leak)
Agent includes env vars in prompt Secrets enter model context Placeholders in context (no leak)
Agent writes config files Secrets written to disk Placeholders written (no leak)
Agent calls a malicious tool Tool accesses all secrets Tool sees placeholders (no access)
Agent error message includes env Secrets in error output Placeholders in errors (no leak)
Note

The vault pattern is the agent equivalent of how cloud platforms manage service accounts. In AWS, your code references an IAM role; the platform provides the actual credentials transparently. Your code never handles the raw credentials. Vaults apply the same principle to agent-accessible secrets: the code references the secret by name; the platform handles the actual value. This is a mature, proven security pattern.

17.8.4 Secret Rotation

Because secrets are stored centrally in vaults (not scattered across agent configurations), rotation is straightforward:

  1. Update the secret in the vault (one place).
  2. All agents using that secret automatically get the new value on their next call.

There’s no need to update each agent’s configuration, redeploy agents, or coordinate across services. The vault is the single source of truth; updating it propagates the change everywhere.

17.8.5 Scoped Secret Access

Not every agent should access every secret. Vaults support scoped access:

  • Agent A has access to GITHUB_TOKEN and SENTRY_DSN.
  • Agent B has access to DATABASE_URL and SLACK_TOKEN.
  • Agent C has no vault access.

This principle of least privilege ensures that each agent can use only the secrets it needs, reducing the blast radius of any compromise.

17.9 CLI Integrations in Depth

The CLI integrations announced alongside schedules and vaults significantly expanded what managed agents can do.

17.9.1 Browserbase: Browser Automation

The Browserbase integration gives managed agents browser capabilities — the ability to navigate websites, interact with page elements, extract data, and automate web-based workflows. This was a first for managed agents.

What browser automation enables:

  • Web research: Browse websites, read content, extract information — even from sites without APIs.
  • Form interaction: Fill out forms, submit applications, complete web-based workflows.
  • Data extraction: Scrape structured data from web pages.
  • UI testing: Interact with web applications to test functionality.
  • Screenshot capture: Take screenshots for documentation or verification.
# Conceptual browser automation via Browserbase
agent.tools.append(browserbase)

result = agent.run(
    task="Go to our competitor's pricing page, extract the pricing "
         "tiers, and compare them to our pricing in pricing.json"
)

17.9.2 Notion Integration

The Notion CLI integration lets agents read and write Notion pages and databases:

  • Read: Access documentation, project plans, meeting notes stored in Notion.
  • Write: Create pages, update databases, add notes.
  • Search: Find information across the Notion workspace.

This enables agents that interact with team knowledge bases — generating reports, updating project trackers, or extracting information for analysis.

17.9.3 Sentry Integration

The Sentry CLI integration lets agents query error data and manage issues:

  • Query errors: Find recent errors, error trends, affected users.
  • Triage issues: Assign priority, add tags, comment on issues.
  • Analyze patterns: Identify error patterns and root causes.

This enables agents that monitor application health and respond to incidents — for example, a scheduled agent that reviews new Sentry errors each morning and triages them.

17.9.4 Ramp Integration

The Ramp CLI integration provides access to financial data and expense management:

  • Query expenses: Find transactions, spending patterns, budget status.
  • Manage expenses: Categorize transactions, flag anomalies.

This enables finance-oriented agents — for example, an agent that monitors spending and flags unusual transactions for review.

17.10 The Complete Production Readiness Picture

With schedules and vaults, Managed Agents addressed all the essential operational concerns for production deployment. Let’s summarize the complete picture:

Concern Feature Status
Execution Managed and self-hosted sandboxes ✅
State Built-in state management ✅
Memory Built-in memory with scoping and audit ✅
Quality Outcomes (rubric-based grading) ✅
Complexity Multiagent orchestration ✅
Connectivity MCP tunnels for private systems ✅
Timing Schedules (cron-based execution) ✅
Secrets Vaults (agent never sees keys) ✅
Governance Audit trails, access controls, observability ✅
Tool ecosystem CLI integrations (Browser, Notion, Sentry, Ramp) ✅

This comprehensive feature set means organizations can deploy agents that are reliable, secure, scheduled, knowledgeable, and well-tooled — all managed, without building infrastructure.

Tip

The rapid evolution of Managed Agents from launch (April) to this announcement (June) — just two months — illustrates how quickly the platform matured. What started as a suite of basic APIs became a comprehensive production platform. For organizations considering adoption, the platform now covers the full spectrum of production concerns.

17.11 Key Takeaways

  • Two features announced June 9, 2026: Schedules and Vaults — addressing timing and secrets for production agents.
  • Schedules let agents run on cron-defined timetables, enabling proactive and recurring work (nightly scans, weekly audits, hourly analysis) without human initiation.
  • Each scheduled run is a discrete session — independent, with access to memory for accumulated knowledge.
  • Vaults securely store credentials such that the agent never sees the actual key — a placeholder appears in the sandbox; the real key is substituted at the network boundary.
  • Vault benefits: no leakage in logs/prompts/outputs, centralized management, scoped access.
  • CLI integrations expanded agent capabilities: Browserbase (browser automation), KERNEL, Notion, Ramp, Sentry.
  • Browser capabilities for the first time — the Browserbase integration let managed agents browse the web, interact with pages, and automate web-based workflows.
  • Schedules and vaults compose naturally: scheduled agents use credentials securely via vaults, run on timetable, with expanded tool access.
  • These features completed the production-readiness story for Managed Agents: execution, state, memory, quality, complexity, connectivity, timing, and secrets all addressed.