claude managed agents: A Nightly Patrol for New 1–2 Star Restaurant Reviews

On November 4, 2026 (Singapore time), we used the EveryInfra API to read new reviews of Katz's Delicatessen in New York. We read Google Maps, Yelp and Tripadvisor. The main finding is about "new". The newest N reviews cover very different time spans on each site. On Google they cover less than 4 days, and on Tripadvisor almost 4 months. Yelp page 1 is not in date order.

One hour later, a second read found a new Google review. Its post time was before our first call, but the first call did not return it. So a nightly job must judge "new" by review ID and remember where it stopped. It cannot just take the newest N or trust post times.

The second finding is about cost. The API fee is small: 4 calls per store per night cost less than one cent. The large part is model tokens on the Anthropic side. With Sonnet 5.5, our estimate puts the model fee at more than ten times the API fee. So a script in the sandbox should cut the raw data down to the 1–2 star reviews before the model reads it.

This article answers one specific question. An operations manager at a New York restaurant group wants a report before 7 a.m. each day. The report must list every new 1–2 star review since last night on Google Maps, Yelp and Tripadvisor. For each review it must say if the problem is food, service, the line or the price, and if anyone replied.

We use scheduled deployments in Claude Managed Agents for this. Each night, the Anthropic cloud starts a new session on a cron schedule. The agent calls three EveryInfra review endpoints over HTTP or remote MCP, picks the new bad reviews, sorts them by cause and writes the report. Then a webhook tells your server that the run is done.

On the EveryInfra side we made 26 real calls, and 20 of them were charged, for $0.02778 in total. On the Anthropic side we did not deploy. Every fact about Managed Agents links to the platform.claude.com docs or release notes, which we read on November 4, 2026.

The job: one morning report for new bad reviews on three sites

We used two public sample stores. We have no link to either business, and the sample report only shows the method. The first store is Katz's Delicatessen on the Lower East Side. It has a 4.5 rating and 56,460 reviews on Google Maps, and a 4.2 rating and 18,710 reviews on Tripadvisor.

It gets many tourists, so it is a good test for "how many new reviews arrive in one night". The second store is Haidilao Hot Pot in Flushing, Queens. It has a 4.8 rating and 8,792 reviews on Google, and a 4.8 rating and 2,643 reviews on Yelp. It stands for a store with a high rating and few bad reviews.

Why run every night and not once a week? In the real Google response for Katz's, the newest 100 reviews span 3.97 days, which is about 24.7 reviews per day. The newest 50 span only 1.80 days, and 29 reviews arrived in the last 24 hours. A bad review is easiest to fix in the first day or two.

That is when a reply, a refund offer or an internal check has the most effect. A weekly job must read 4 Google pages per store, and the oldest bad review is six or seven days old when the report arrives. A nightly job that reads the newest 50 covers everything since last night, with one spare night of margin.

The prices come from the free catalog at https://api.everyinfra.com/api/v1/social/catalog, which we read at 00:13 Singapore time on November 4. All three review capabilities showed available. Each call costs 100 credits, which is $0.001389. You need the three lookup calls only once per store. They turn a store name into the store URL on each site, and after that the nightly job reads reviews by URL.

What claude managed agents is: four objects plus a schedule

Claude Managed Agents is a set of hosted APIs on the Claude Platform. You define the model, the system prompt and the tools of an agent. Anthropic runs the agent loop in its own cloud. It starts a sandbox container, runs the tool calls and keeps the session record. The product launched as a public beta on April 8, 2026. Every request needs the header anthropic-beta: managed-agents-2026-04-01 (overview, release notes).

The overview names four core concepts: agent, environment, session and vault. The scheduled deployment is a fifth object. It arrived on June 9, 2026, and it starts sessions for you on a schedule (Anthropic blog). The table shows how each object maps to the review patrol.

The point that people miss most often is that the environment is new on every run. The sessions doc says each session gets a fresh container. Files that one run writes to the sandbox are gone on the next run (Start a session). For a review patrol this matters a lot.

The list of "reviews we already saw" cannot live in a sandbox file. It must live in a memory store, which is a separate beta mounted under /mnt/memory/ (Using agent memory). The other option is that your own server keeps the list after each webhook and sends it back in the next initial message.

Scheduled deployments: cron, time zone, jitter, budget and no backfill

You create a scheduled deployment with POST /v1/deployments. It needs an agent, an environment, at least one initial event (usually a user.message) and a schedule. The schedule has type: cron and an expression in standard 5-field POSIX cron with minute precision. It also has a timezone with an IANA name such as America/New_York (Scheduled deployments).

The cron fields follow POSIX crontab. The zone names come from the IANA time zone database, and its latest release, 2026f, came out on 2026-10-27. The create response lists the next fire times in schedule.upcoming_runs_at, so you can check the expression at once.

One sentence in the doc decides the report deadline. The fire times are exact, but the real start gets jitter of up to 15% of the run interval. The minimum is 5 seconds and the maximum is 9 minutes. The chart below plots this rule.

A deployment that runs every 5 minutes starts at most 45 seconds late. A deployment that runs every hour or every day starts at most 9 minutes late. If the report must arrive before 7:00, a 6:30 cron leaves room for 9 minutes of jitter plus a 20-minute run.

Daylight saving time is the second trap. The doc says cron uses literal wall-clock matching. So 0 20 * * * in America/New_York fires at 8 p.m. local time in both EST and EDT. On the spring-forward day, a time that does not exist, such as 2 a.m., does not fire.

On the fall-back day, a time that occurs twice fires twice. The doc tells you to avoid 1 to 3 a.m. local time, or to use UTC. In 2026, US daylight saving time ended on November 1. So from this week, 30 6 * * * in New York is 11:30 UTC, and during daylight saving time it is 10:30 UTC.

The third point is the budget. A deployment can carry an optional budget with the same shape as a session budget: {"type": "limit", "max_list_cost": {"amount": "50", "currency": "USD"}}. The amount is a whole number of US cents written as a string, so "50" means 50 cents (Session budgets). The deployment copies this cap onto each new session. So the cap applies to each run, not to a monthly total. The doc example is clear: a deployment with a "2000" cap can spend about $20 on every run.

The budget counts model tokens, web searches ($10 per 1,000) and session running time ($0.08 per hour) at public list rates. The platform checks it between model requests and pauses the session with budget_reached when the cap is hit. The budget does not include your EveryInfra API fee. That fee depends only on the number of calls, which is fixed at 4 per store per night.

The fourth point is failure. When you pause a deployment, scheduled triggers stop, but a running session finishes. When you unpause, the schedule starts again from the next scheduled time. The doc says "Missed triggers are not backfilled". Each trigger writes a deployment run record. You can list the failed ones with GET /v1/deployment_runs?deployment_id=…&has_error=true.

Common error types are environment_archived_error, agent_archived_error and session_rate_limited_error. The last one is recorded and not retried. Each organization can have up to 1,000 scheduled deployments. So the report job must handle "last night did not run" by itself. The next run must not read only the last 24 hours. It must read back to the last review ID that the last good run saved.

Where the key lives: two kinds of vault credentials

The EveryInfra key is used either by an MCP connection or by curl in the sandbox. These two uses match two kinds of vault credentials (Authenticate with vaults). MCP credentials are mcp_oauth and static_bearer, and they are keyed by mcp_server_url. When the session connects to an MCP server at that URL, the token is added for you.

An environment_variable credential is keyed by secret_name. The sandbox holds only an opaque placeholder. The real value replaces the placeholder at the network edge, only for hosts in networking.allowed_hosts, and injection_location can limit the swap to headers.

We recommend the environment variable credential for this job, for three reasons. First, the key can go to one place only. The credential lists only api.everyinfra.com in allowed_hosts. If a hostile line in a review tells the model to call another URL, that request carries only the placeholder.

Second, the credential's allowed_hosts controls which requests get the key, not which requests can leave the sandbox. The environment networking setting controls the second part. When both list only api.everyinfra.com, you get one lock on the network and one lock on the key.

Third, on the HTTP path the raw response goes into a sandbox file first. A jq filter then passes only the rows that matter to the model, and the cost section shows how many tokens this saves. The environment variable credential has limits too. It does not yet work with self-hosted sandboxes. A vault can hold up to 20 credentials. The platform does not test a credential when you create it, so you learn that a key is wrong only at run time.

We tested that last point on the EveryInfra side. At 00:22 Singapore time we called remote MCP tools/call with no key. The HTTP status was 200. The body had isError set to true, with text that said the call was not authorized and "Nothing was charged".

So a wrong or expired key in the vault does not fail when the session connects to MCP. It fails on the first tool call, as an error result. The agent prompt must say: stop on an authorization error and write "key not valid" at the top of the report. It must not retry with other parameters.

Why not use web_fetch to read the review pages

Managed Agents has a built-in web_fetch tool, and it looks like the easy path. You put the three store URLs in the prompt and let the agent read the pages each night. We checked the docs and the robots.txt files of the three sites. For an unattended night job, this path does not work well. The table shows why.

People often miss the first limit. The October 7, 2026 release note says that web_fetch now fetches only URLs that already appeared in the session. The goal is less risk of data exfiltration. A URL in a user message or in a web_search result counts. Some URLs do not count: URLs only in Claude's own output, the system prompt, an attached document, or bash or MCP tool output. For those, the call returns url_not_in_prior_context.

A second note on the same day is about limited networking. With it, the environment allowed_hosts list also applies to web_fetch and web_search (Restrict web search and web fetch domains). Since October 20, an organization admin can also turn off web fetch on the Console Capabilities page. When it is off, every web_fetch call in a Managed Agents session returns an error. With all three rules in place, a nightly job with fixed URLs depends on too many conditions.

The pages themselves are the bigger problem. The Google Maps review list loads with JavaScript, and the web_fetch doc says it does not support sites rendered with JavaScript. Yelp store pages are closed to Claude-User. Tripadvisor robots.txt has Disallow: / for ClaudeBot.

Claude-User is not named, so the general rules apply to it. The official APIs all have small caps: 5 reviews from Google Places, 3 excerpts from Yelp Fusion and 5 from the Tripadvisor Content API. Katz's gets about 25 reviews a night, so these caps are far too low. That leaves one tool path for this job: call a review API over HTTP or remote MCP and get structured JSON.

Remote MCP or HTTP: two paths with different costs

The first path is remote MCP. The EveryInfra MCP server is at https://api.everyinfra.com/mcp and uses the Streamable HTTP transport (MCP transports). Its tools/list returns 12 tools, and the one that costs money is everyinfra_call_api (see the MCP server page). On the agent you declare an MCP server with type: url and add an mcp_toolset. The vault supplies a static_bearer credential that matches the server URL (MCP connector). This path needs the least setup, but it has two traps.

Trap one is approval. The permission policy doc says the agent toolset defaults to always_allow and MCP toolsets default to always_ask (Permission policies). The session pauses before each MCP call and waits for approval. At night nobody approves, so the session waits.

Set default_config.enabled: false on the toolset to turn off all its tools, then set always_allow on everyinfra_call_api alone. The tool has the annotations readOnlyHint: false and destructiveHint: true because each call is charged. So even the auto policy can ask for approval. The MCP tools spec defines these annotations.

Trap two is response size. The MCP connector doc gives a size limit of 100,000 characters (about 25,000 tokens). A larger tool output goes to a file in the sandbox, and the model gets only a short preview. Our real Google response with the newest 100 Katz's reviews was 105,266 characters, just over that line.

In the second round, a real MCP call for the newest 50 returned 53,364 characters. Tripadvisor with 50 reviews was 54,739 characters, and one Yelp page of 10 was about 10,000 characters. The chart puts each real response next to the line.

The second path is HTTP with the environment variable credential. The agent uses its built-in bash tool to run curl with the header Authorization: Bearer $EVERYINFRA_API_KEY. In the sandbox, that variable holds only the placeholder, and the real key replaces it on the way out. The JSON response goes straight into a sandbox file. A jq filter then passes only the 1–2 star reviews that are not in the last ID list.

So the model sees a dozen filtered reviews, not 128,000 characters of raw data per store. The cost is a longer prompt with clear script steps, plus jq in the environment. You can let the environment use package managers, or install jq ahead of time. We recommend the HTTP path for the nightly run. Keep MCP for manual checks. In a manual session the agent can call everyinfra_list_requests to see the status and charge of one call, and that tool is free.

Configuration examples: environment, agent, vault, deployment

We wrote the four files below from the fields in the platform.claude.com docs. They are configuration examples, and we did not create them in an organization. The ant CLI can turn a Markdown file with a YAML header into an object with ant apply. It saves the ID in claude-lock.json (Define your agent). The environment comes first.

# Configuration example: environment (fields from the Cloud environment setup doc; not tested by us)
name: review-patrol-env
config:
  type: cloud
  networking:
    type: limited
    allowed_hosts:
      - api.everyinfra.com
    allow_package_managers: true   # to install jq; turn off after you preinstall it
    allow_mcp_servers: false

The agent comes next. The system prompt fixes three rules: call only four endpoints, judge "new" by ID, and stop on an authorization error.

---
# Configuration example: agent.md (fields from Define your agent, Tools and Permission policies; not tested by us)
name: Nightly review patrol
model: claude-sonnet-5-5
tools:
  - type: agent_toolset_20260401
    configs:
      - name: web_fetch
        enabled: false
      - name: web_search
        enabled: false
---
Each night, read new reviews for every store in the store list. Use only bash and curl to call
https://api.everyinfra.com/api/v1/social with the header "Authorization: Bearer $EVERYINFRA_API_KEY".
Make 4 calls per store: google_maps_reviews/reviews (sort=newest, limit=50), yelp/reviews pages 1 and 2,
and tripadvisor/reviews. Save each response to /tmp/<store>-<site>.json.
Use jq to drop review IDs that are already in /mnt/memory/review-patrol/seen.json. Read only 1-2 star reviews.
Give each bad review one or more labels: food, service, line and seating, price and hype, venue, online order.
Translate reviews that are not in English before you label them.
If a response says unauthorized, stop. Write "EveryInfra key not valid" as the first line of the report. Do not retry.
At the end, write all review IDs from this run back to /mnt/memory/review-patrol/seen.json,
and write the report to /mnt/session/outputs/report.md.

The vault needs one credential. On your own machine, read secret_value from an environment variable so that the key never goes into a file.

# Configuration example: add an environment variable credential to a vault (fields from Authenticate with vaults; not tested by us)
curl --fail-with-body -sS "https://api.anthropic.com/v1/vaults/$VAULT_ID/credentials" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: managed-agents-2026-04-01" \
  -H "content-type: application/json" \
  -d "$(jq -n --arg v "$EVERYINFRA_API_KEY" '{
        auth: {
          type: "environment_variable",
          secret_name: "EVERYINFRA_API_KEY",
          secret_value: $v,
          networking: {type: "limited", allowed_hosts: ["api.everyinfra.com"]},
          injection_location: {header: true}
        },
        display_name: "EveryInfra key for nightly review patrol"
      }')"

The scheduled deployment comes last. The doc says a deployment takes the same settings as a new session. Agent and environment are required. Files, memory stores and vaults are optional. The store list goes into the initial message, and the budget is 50 cents per run. The amount field is in cents, so "50" is $0.50, not $50. A memory store mounts under /mnt/memory/ by its display name, so a store named review-patrol is at /mnt/memory/review-patrol/.

{
  "name": "Nightly review patrol (NYC)",
  "agent": "agent_01...",
  "environment_id": "env_01...",
  "vault_ids": ["vlt_01..."],
  "resources": [
    {"type": "memory_store", "memory_store_id": "memstore_01...", "access": "read_write",
     "instructions": "seen.json holds the review IDs from the last run, grouped by site."}
  ],
  "initial_events": [
    {
      "type": "user.message",
      "content": [{"type": "text", "text": "Store list: Katz's Delicatessen and Haidilao Hot Pot Flushing. URLs are in stores.json. Read all new reviews since the last run and write the morning report."}]
    }
  ],
  "schedule": {"type": "cron", "expression": "30 6 * * *", "timezone": "America/New_York"},
  "budget": {"type": "limit", "max_list_cost": {"amount": "50", "currency": "USD"}}
}

How do you get the result? Webhooks send a thin payload with only the event type, the ID and a time stamp, not the full object. You fetch the object with a GET call (Subscribe to webhooks). Two event types are enough. Note that session.status_idled means "the agent stopped and waits for input".

It fires when the run is done and also when the run waits for an approval. So your server must GET the session and read stop_reason.type on the latest session.status_idle event (Session event stream). deployment_run.failed means that night's run did not create a session. Manual runs through the run endpoint do not send deployment_run events, so do not wait for one in a test.

Each event gets up to 3 delivery attempts, with jittered exponential backoff from 5 to 120 seconds. After the last failed attempt, the event is dropped and not queued. So your server must deduplicate on event.id, and it must check the deployment run list each morning. The signing secret starts with whsec_. The headers are webhook-id, webhook-timestamp and webhook-signature, the same format as Standard Webhooks.

One real round trip: what the model sends and what comes back

We did not deploy on the Anthropic side. But a request that an agent sends to EveryInfra through MCP looks the same on our side as a request it sends with curl. Below is the real request that we sent at 00:21:42 Singapore time through remote MCP tools/call. It reads page 2 of the Katz's reviews on Yelp. The page_token comes from next_page_token in the page 1 response, and we shortened it here.

{"jsonrpc": "2.0", "id": 7, "method": "tools/call",
 "params": {"name": "everyinfra_call_api",
  "arguments": {"platform": "yelp", "action": "reviews",
   "params": {"url": "https://www.yelp.com/biz/katzs-delicatessen-new-york",
              "page_token": "pt1.4EnA2jhN8mJn…"}}}}

The answer came back with HTTP 200 after 24.9 seconds. content[0].text held 9,675 characters of JSON with 10 reviews, and the call was charged $0.001389. Each review has fields such as id, rating, posted_at and text. The field that matters most is id, because the "new" test depends on it. The table lists all first-round (T1) calls for Katz's.

The first call at 00:17:32 got a 429. Our test key has a limit of 10 calls per minute. That call was not charged, and a retry after 30 seconds worked. We then made 13 more calls for Haidilao and for Contramar in Mexico City.

Four of those were searches with no result, and the API refunded each one with empty_result_refunded. In the first round, 15 calls were charged, for $0.020835. With the 5 calls of the second round at 01:20, 20 calls were charged, for $0.02778. Google place search returned no result for the two stores outside the US (Botín in Madrid and Contramar in Mexico City). We then called google_maps_reviews/reviews with a Google Maps search URL and got 50 Contramar reviews.

Test 1: how many days "the newest N" covers on each site

How many reviews you must read each night depends on how much time one page covers. We took the posted_at of the first and the last review in each response and subtracted them. The chart shows the result. Two edited old reviews on Google (dated October 23 and August 10) sat in the middle of the list. Google help says an edited review shows the edit date (Google Business Profile help), so we left those two out of the span.

"The newest 50" covers less than two days for Katz's on Google and more than a year for Contramar on Tripadvisor. Two things cause this gap: the review volume of the store and the review language. Both Tripadvisor responses were all English. All 50 Katz's reviews were in English. For Contramar we used the Mexican site URL, tripadvisor.com.mx, and all 50 reviews were still in English, from 2025-09-02 to 2026-10-21.

So this endpoint reads the English reviews on Tripadvisor, and Spanish reviews are not in the response. For a store with mostly local guests, the Tripadvisor side will rarely show a new review on a given night. One read costs only $0.001389, so it is still worth keeping in the job.

Yelp behaves in a different way. Page 1 for Katz's had 10 reviews from September 20 to November 2, in mixed order. The Yelp support page says the default order uses recency, votes and review quality, so older reviews can appear before newer ones. Only logged-in users can pick "Newest First" (Yelp support).

We added sort_by=date_desc to the URL and called again. The 10 review IDs were exactly the same, so this URL parameter had no effect. Page 2 had a review from November 1, and 5 of its 10 reviews were newer than the oldest review on page 1. So the nightly job must read at least two Yelp pages, and it must judge "new" by ID. The top review on page 1 is not a safe marker.

Test 2: where the bad reviews are and what they say

The chart shows the share of each star rating in each response. In the newest 100 Google reviews for Katz's, 10 had 1–2 stars, which is 10%. On Tripadvisor, 10 of 50 had 1–2 stars, which is 20%. On Yelp, only 1 of the 20 reviews on two pages had 1 star.

For Haidilao, 49 of 50 Google reviews had 5 stars and 1 had 3 stars, with no bad review. All 10 reviews on Haidilao's Yelp page 1 had 4 or 5 stars. For Contramar, the 50 Google reviews included one 1-star and one 2-star review.

We read the full text of the 10 bad Google reviews and the 10 bad Tripadvisor reviews for Katz's. We labeled each one by hand, and one review can have more than one label. Of the 10 Google reviews, 6 were about food (dry meat, bread that falls apart) and 7 said the place is overhyped or overpriced. 3 were about staff, 2 about crowded seats or the room, and 1 about the line.

Of the 10 Tripadvisor reviews, 7 were about food, 6 about price and hype, 5 about service and 3 about the line and seating. Two more were about online orders and shipping, not about the restaurant visit. This split helps the report. Online order complaints should go to the e-commerce team and should not count against the store staff.

Two more findings change the prompt. First, 6 of the 10 bad Google reviews were not in English: 2 Italian, 2 German, 1 Turkish and 1 Spanish. The lang parameter sets the interface language and does not translate reviews, so the agent must translate before it labels. Second, 10 of the newest 100 Google reviews had an owner reply. All 10 replies went out between 21:10 and 21:32 UTC on November 2, a 22-minute window.

Nine of the 10 replies went to 5-star reviews. Only one went to a 1-star review, which was about someone who cut the line. That reply came about 35 hours after the review. So this store replies in batches and replies to good reviews first. A "replied" column in the report puts the bad reviews that nobody handled at the top.

Test 3: how to judge "new" between two snapshots

The first round (T1) ran from 00:19 to 00:21 Singapore time and the second round (T2) at 01:20. The gap of about one hour stands for "last night" and "tonight". In T2 we read the newest 50 Katz's reviews on Google through remote MCP. We read Google again over REST with since=2026-11-03, plus Yelp page 1 and Tripadvisor once each.

That is 4 calls for $0.005556. One more yelp/search call found the Yelp page of Contramar for the Spanish edition. The "new" rule has one line: a review is new if its ID is not in the set from the last run.

The most useful detail is the post time of the 3 new Google reviews: 17:15, 16:49 and 14:54 UTC. The first two are later than the T1 call at 16:19 UTC, so they are normal new reviews. The third one, at 14:54, is 1 hour 25 minutes older than the T1 call. It is even older than the newest review in T1 (15:52), but it was not in the T1 list of 100.

So a review can appear on Google later than its displayed post time. A rule like "read only reviews with posted_at after the last newest one" skips this review forever. Only an ID comparison catches it. For the reviews that appear in both T1 and T2, posted_at, the star rating and the owner reply did not change.

The since parameter also belongs in the prompt. It is a date, not a time. since=2026-11-03 returned all 17 reviews from November 3 UTC, and 14 of them were already in T1. So it cannot replace the ID check. But it cut the response from 53,364 to 21,588 characters, about 60% less, which helps most on the MCP path.

Our advice: set since to the day before the last good run, keep sort=newest, and remove duplicates by ID. Keep limit at 50 as a safety net if since is wrong. Yelp and Tripadvisor had no new review in this hour, and the 10 IDs on Yelp page 1 kept the same order. A page 1 with no change does not prove that page 2 has no change, so read both pages. The report for this night has one line: "3 new reviews in the last hour on three sites, all 5 stars, no new bad review."

This comparison also decides what goes into the memory store. A set of recent review IDs per site is enough. Keep the last 400 IDs for Google, because the endpoint pages up to 400 rows. Keep the last 100 IDs for Yelp and for Tripadvisor. Also keep the date of the last good run. Do not store only "the time of the newest review", because of the 14:54 review above.

What the morning report looks like

Write the label rules into the prompt, with one line of definition and a few clues for each label. If you do not, the same review is "service" today and "line" tomorrow, and the month-end totals do not compare. We built the six labels below from the full text of 28 bad reviews: 21 for Katz's and 7 for Contramar. Each clue comes from words that came up again and again in those reviews. A review can have more than one label. When the agent is not sure, it should add one more label and not force a single choice.

The sample below uses the 10 bad Katz's reviews on Google from the T1 response. We translated and shortened each review. The dates are UTC. A real report should also link each review, so that the manager on duty can open it and reply.

The report should start with a short summary, not a long list. From the table above, the summary can say: "In the last 4 days, Google got 10 new reviews with 1–2 stars. 7 say the place is overhyped or not worth the price, and 6 are about food. 6 reviews are not in English. 9 have no reply, and 3 of those are about staff. Reply to those 3 first today."

Do not put the names of reviewers or staff in the report text. Keep only the links. Contramar's Google review text also contains <br> line break tags (6 of the 30 reviews with text), so the agent must clean them before it writes the report.

claude managed agents pricing: the API fee and the Anthropic side

There are two sides to the cost. The EveryInfra side is simple. Each store needs 4 calls per night at $0.001389, which is $0.005556 per night and $0.1667 for 30 nights. For 10 stores it is $1.6668 per month, and for 50 stores it is $8.334.

There is no monthly fee. Empty results are refunded. The three lookup calls happen only at setup (see the pricing page).

On the Anthropic side, the pricing page that we read on November 4, 2026 says Managed Agents has two charges. Tokens are billed at the list price of the model. Session runtime costs $0.08 per hour, measured to the millisecond, and only while the session status is running. Idle time is free.

Web searches in a session cost $10 per 1,000, and the Batch API discount does not apply (Pricing). The same page lists Opus 5.5 at $4 input and $20 output per million tokens. Sonnet 5.5 is $2 and $10. Haiku 5.5, for prompts up to 100,000 tokens, is $0.10 and $0.50.

We did not measure token use, so the next numbers are estimates. We show the assumptions so that you can use your own. One store and one night give 129,603 characters of raw responses (the real Google 50 response from the second round, Yelp two pages, Tripadvisor 50). The glossary says older models use about 3.5 English characters per token. Models 4.7 and later use about 30% more tokens for the same text (Glossary). We used 2.69 characters per token, so the raw responses are about 48,138 tokens.

The agent loop can read the context more than once. We cannot measure how many times, so we give two levels. 1x (each response goes into the context once) is the low end, and 3x is a high end. Both levels add 15,000 tokens for the system prompt and tool text, and 3,000 output tokens. We did not include any prompt cache discount. On the MCP path with all raw data in context, one night needs about 63,138 to 159,414 input tokens.

On the HTTP path, where jq passes only the 1–2 star rows, one night needs about 17,854 to 23,564 input tokens. At the 3x level, that is about 85% less. The characters-per-token value is also an estimate. For a better number, run the Anthropic token counting endpoint on your own responses. For runtime, we used the measured 69.8 seconds of the 4 tool calls plus 60 seconds of model time, which gives $0.00288 per night.

The API fee is a small, fixed number. The real cost depends on the model and on how much raw data goes into the context. With Sonnet 5.5 on the HTTP path, one store costs about $0.074 to $0.086 per night in total. The API fee is only 6.5% to 7.5% of that. The same model on the MCP path with full data costs about $0.165 to $0.357 per night, which is 2.2 to 4.2 times as much. Haiku 5.5 is probably good enough to label and translate reviews, and then one store costs less than $0.40 per month.

To set the deployment budget, use "stores × estimate per store × 3". For 10 stores on Sonnet with HTTP, the estimate is about $0.86 per night. A budget of "300" ($3) stops a runaway loop and still lets a normal run finish. One Reddit user said three tries of Managed Agents cost about $6 in API fees (Reddit thread). That is why you should set the budget on day one. The table scales the totals to more stores at the 3x level. It assumes that the cost per store stays the same and that one session reads all stores.

claude managed agents vs agent sdk, Claude Code and Cowork schedules

Anthropic now gives you at least four ways to run Claude on a schedule. The right one depends on who runs the loop, who pays and where the key lives. The Agent SDK is a library. It puts the Claude Code agent loop in your own process.

You supply the machine and the scheduler (Agent SDK overview, hosting guide). Managed Agents is a hosted loop plus a sandbox. Claude Code routines and Cowork scheduled tasks are features of the subscription apps, and they use your plan's usage.

We wrote two related articles before. One uses Claude Code routines to read Reddit each night and write a pain-point digest. In that test, one page of 100 posts covered only 18.7 hours (Claude Code scheduled tasks on Reddit). The other uses Cowork scheduled tasks for a Monday competitor price and review table (Cowork competitor price table).

Read the three together. For a weekly report that you read yourself, Cowork is the easiest. For a developer job next to a code repository, use Claude Code. For dozens of stores every night, with a budget cap, failure alerts and results pushed to your own system, use a Managed Agents scheduled deployment.

The Claude Code doc says routines run at most once per hour and use plan usage (Routines). Cowork tasks run in the cloud even when your computer sleeps (Cowork help). If you only need Google Maps reviews in a spreadsheet and no agent, see how to scrape Google Maps reviews.

When something breaks: which layer to check first

When a night job fails, the report often says only "no data". The table puts the likely faults of three layers in one place: the Anthropic deployment and session, the vault and network, and the EveryInfra API. The left column is the symptom that you see. The right columns tell you where to look first. We hit each EveryInfra row in our real calls on November 4. The Anthropic rows come from the doc text on errors and states.

One rule sits behind this table. Each error must appear in the report, and the agent must not work around it by itself. Agents are good at "try again with other parameters". This job costs money and runs at night with nobody watching.

Here a workaround often means the wrong store, a double read, or a config fault that stays for a month. So the prompt must say: on unauthorized, 403 or a budget pause, stop and write the reason. Only a 429 gets one retry after the wait.

Limits and open points

First, we did not test the Anthropic side. Scheduled deployments, vault swaps, permission policies and webhooks are all configuration examples from the platform.claude.com docs, read on November 4, 2026. Managed Agents is still a beta, and fields can change. We wrote vault_ids and resources from the examples in the sessions doc and the memory doc. Check them against the deployments reference for your SDK version before you create anything.

Second, the Tripadvisor side returns only English reviews. Reviews in Spanish, Chinese or other languages are not in the response. Third, Google place search gave no result for both stores outside the US (refunded). A direct read with a Google Maps search URL worked, so check each new store URL once by hand. Fourth, Yelp page 1 is not in date order and the URL sort parameter has no effect. Read one more page and judge "new" by ID.

Fifth, review text is untrusted input. The memory doc warns that content in a memory store can carry prompt injection, and review text has the same risk. Someone can write "ignore your instructions" in a review. The HTTP and jq path keeps reviews as data. The environment allows only api.everyinfra.com, and the vault swaps the key only for that host. So even if the model is misled, the key cannot leave.

Sixth, use the report only to improve your own stores. The 2024 FTC rule bans fake reviews, payment for reviews with a set opinion and the suppression of negative reviews (FTC press release). Bad reviews are worth a nightly check, but the right answer is a reply and a fix, not pressure on the review. This article covers data methods only and is not legal advice.

Recent changes

These updates from the last month affect this job. All of them are in the Claude Platform release notes. On 2026-10-07, web_fetch started to fetch only URLs already seen in the session, and allowed_hosts under limited networking started to apply to web_fetch and web_search. On 2026-10-09, Managed Agents added dynamic workflows, which run many agents in phases. They can help when you have hundreds of stores, but we did not test them. On 2026-10-14, scheduled deployments became available on Claude Platform on AWS.

On 2026-10-20, organization admins got a Console switch to turn off web fetch or limit its domains, and Managed Agents sessions follow it. On 2026-10-29, the Usage and Cost Analytics API beta arrived. It splits tokens and cost by model, workspace and API key, which helps you check the monthly cost of the patrol.

FAQ

What is the difference between claude managed agents and Claude Code routines?

This question comes from the search suggestions "claude managed agents vs claude code" and "claude managed agents vs routines", and from the Reddit post "What is the point of Managed Agents" (Reddit thread). Both run in the Anthropic cloud. Claude Code routines use plan usage and run at most once per hour (Routines). Managed Agents deployments bill API tokens plus $0.08 per session-hour and run on a minute-level cron. They cap each run with a hard budget and push results by webhook (Scheduled deployments). Use the second for production jobs for a team or for clients.

How does claude managed agents pricing work, and what does one night cost?

This question comes from the suggestions "claude managed agents pricing" and "claude managed agents cost". There are two charges. Model tokens cost the list price, and session runtime costs $0.08 per hour, only in the running state (Pricing, read on 2026-11-04). With our estimate, one store on Sonnet 5.5 with the HTTP path costs about $0.077 in model fees and $0.0029 in runtime per night. Add $0.0056 for the EveryInfra API, and the total is about $0.0855 at the high 3x level.

claude managed agents vs agent sdk: which one should I pick?

This question comes from the suggestion "claude managed agents vs agent sdk". The Agent SDK is a library. The loop runs in your own process, and you handle the machine, the schedule, the secrets and the logs (Agent SDK overview). Managed Agents hosts the loop, the sandbox, the schedule, the credential swap and the session record. Pick the SDK if you already run servers and a job queue and want full control. Pick Managed Agents if you want webhooks and a budget per run without your own scheduler.

Can Managed Agents read Google Maps or Yelp reviews with web_fetch?

This question comes from the suggestion "claude managed agents web". Not reliably. web_fetch does not run JavaScript, and since 2026-10-07 it fetches only URLs that already appeared in the session (release notes). Yelp robots.txt allows Claude-User only on /article (yelp.com/robots.txt). A structured review API is more reliable.

What happens when a scheduled deployment misses a run?

This question comes from the suggestion "claude managed agents schedule". Triggers missed during a pause are not backfilled. When session creation is rate limited, that run gets a session_rate_limited_error record and no retry (Scheduled deployments). So the next run must read back to the last review ID that the last good run saved, not only the last 24 hours. On Google, limit=50 covers about two days for a busy store like Katz's, so one missed night is still covered.

Can the model see the key in the vault?

This question comes from the suggestions "claude managed agents vault" and "claude managed agents credential vault". No. An environment variable credential holds only a placeholder in the sandbox. The real value replaces it on the way out, and only for hosts in allowed_hosts (Authenticate with vaults). The Anthropic blog also says the agent never sees your key (Anthropic blog).

Get started

1. Get an EveryInfra API key. Follow the quickstart and run google_maps_reviews/search, yelp/search and tripadvisor/search once each to find the three store URLs.
2. Call google_maps_reviews/reviews, yelp/reviews and tripadvisor/reviews once with curl on your own machine. Check the fields and the response size. For the MCP path, see the MCP server page.
3. In the Claude Console, create the environment with limited networking and only api.everyinfra.com. Create the vault with one EVERYINFRA_API_KEY credential. Create the agent with web_fetch and web_search turned off.
4. Run one session by hand, or call POST /v1/deployments/{id}/run, to check the report format and the cost. Then create the deployment with cron 30 6 * * * and a budget per run. Subscribe to session.status_idled and deployment_run.failed.
5. See the Google Maps reviews page, the Yelp page and the Tripadvisor page for each review API. For a weekly report across five review sites, see the openai agents api review patrol.

References

1. Claude Managed Agents overview, Anthropic docs, read 2026-11-04.
2. Scheduled deployments, Anthropic docs, read 2026-11-04.
3. Authenticate with vaults, Anthropic docs, read 2026-11-04.
4. Cloud environment setup, Anthropic docs, read 2026-11-04.
5. Tools, Anthropic docs, read 2026-11-04.
6. MCP connector, Anthropic docs, read 2026-11-04.
7. Permission policies, Anthropic docs, read 2026-11-04.
8. Session budgets, Anthropic docs, read 2026-11-04.
9. Subscribe to webhooks, Anthropic docs, read 2026-11-04.
10. Reference, Anthropic docs, read 2026-11-04.
11. Using agent memory, Anthropic docs, read 2026-11-04.
12. Restrict web search and web fetch domains, Anthropic docs, read 2026-11-04.
13. Web fetch tool, Anthropic docs, read 2026-11-04.
14. Pricing, Anthropic docs, read 2026-11-04.
15. Claude Platform release notes, Anthropic, read 2026-11-04.
16. Define your agent, Anthropic docs, read 2026-11-04.
17. Start a session, Anthropic docs, read 2026-11-04.
18. Session event stream, Anthropic docs, read 2026-11-04.
19. Glossary, Anthropic docs, read 2026-11-04.
20. Agent SDK overview, Claude Code docs, read 2026-11-04.
21. Hosting the Agent SDK, Claude Code docs, read 2026-11-04.
22. Routines, Claude Code docs, read 2026-11-04.
23. Schedule recurring tasks in Claude Cowork, Claude Help Center, read 2026-11-04.
24. Does Anthropic crawl data from the web, Claude Help Center, read 2026-11-04.
25. New in Claude Managed Agents: run agents on a schedule, Anthropic blog, read 2026-11-04.
26. Claude Managed Agents: get to production 10x faster, Anthropic blog, read 2026-11-04.
27. MCP Transports, Model Context Protocol spec, read 2026-11-04.
28. MCP Tools, Model Context Protocol spec, read 2026-11-04.
29. Place Details (New), Google for Developers, read 2026-11-04.
30. Work with review data, Google Business Profile docs, read 2026-11-04.
31. Read and reply to reviews, Google Business Profile Help, read 2026-11-04.
32. Business Reviews, Yelp Fusion docs, read 2026-11-04.
33. How is the order of reviews determined?, Yelp Support, read 2026-11-04.
34. yelp.com/robots.txt, Yelp, read 2026-11-04.
35. Location Reviews, Tripadvisor Content API docs, read 2026-11-04.
36. tripadvisor.com/robots.txt, Tripadvisor, read 2026-11-04.
37. crontab, The Open Group Base Specifications Issue 8, read 2026-11-04.
38. Time Zones, IANA, read 2026-11-04.
39. Standard Webhooks, Standard Webhooks, read 2026-11-04.
40. FTC final rule banning fake reviews, US Federal Trade Commission, published 2024-08-14, read 2026-11-04.
41. What is the point of Managed Agents?, Reddit r/ClaudeAI, read 2026-11-04.
42. EveryInfra API catalog, EveryInfra, read 2026-11-04 at 00:13 Singapore time.