Claude Managed Agents: як запустити AI-агента в хмарі Anthropic

Більшість розмов про AI-агентів зводиться до одного питання: як змусити модель працювати не кілька хвилин у чаті, а годинами й днями, з доступом до коду, файлів і зовнішніх сервісів, і щоб це було безпечно. Можна зібрати все самому: цикл виклику інструментів, контейнери, керування контекстом, зберігання історії, токени доступу, масштабування. А можна віддати цю інфраструктуру Anthropic. Саме для цього існує Claude Managed Agents.

Цей гайд побудовано на воркшопі Anthropic для розробників (запис на YouTube), де інженери компанії Bianca і Gabe показали, як влаштований сервіс зсередини і як зібрати на ньому мультиагентну систему. Ми доповнили його офіційною документацією Claude Platform, бо частина можливостей з воркшопу з того часу змінилася або вийшла з preview. Для збирання джерел використали NotebookLM. Код наводимо на Python з офіційним SDK anthropic. Якщо ви ще не знайомі з субагентами в Claude Code, почніть із нашого гайда по субагентах: багато ідей звідти тут повторюються, тільки в хмарі.

Managed Agents зараз у статусі beta. Назви полів і ендпоінтів у прикладах актуальні на листопад 2026 року (beta-заголовок managed-agents-2026-04-01, SDK додає його сам). Перед продакшн-запуском звіряйтеся з документацією.

Що таке агент, harness і пісочниця

На воркшопі Bianca почала з трьох понять, без яких решта не має сенсу.

Агент — це модель у циклі з інструментами. Модель вирішує, що робити далі, викликає інструмент, дивиться на результат і знову вирішує. Так триває, доки задача не виконана.

Harness (буквально «упряж») — шар навколо моделі, який крутить цей цикл: виконує виклики інструментів, керує контекстом, зберігає стан. Головне в harness — він закладає припущення про те, чого модель не вміє, і закриває ці прогалини. Приклад із воркшопу: у Sonnet 4.5 була «контекстна тривога» — коли модель відчувала, що вікно контексту закінчується, вона поспіхом згортала задачу. Тому harness для Sonnet 4.5 мав механізм скидання контексту. В Opus 4.5 цієї проблеми вже не було, і такий механізм став зайвим. Висновок інженерів Anthropic: припущення harness застарівають з кожною новою моделлю, і підтримувати добрий harness — окрема постійна робота.

Пісочниця — ізольоване середовище, де агент виконує написаний ним код: редагує файли, ставить пакети, запускає скрипти. Claude Code — добрий приклад harness, що працює локально на вашому комп’ютері з доступом до файлів. Але в продакшені код агента — це недовірений код: він може бути з помилками, тому його виконують у контейнері, ізольовано, з обмеженим «радіусом ураження». В ідеалі — окремий контейнер на кожну задачу.

Managed Agents бере на себе все три: Anthropic запускає harness на своїй інфраструктурі й створює окремий контейнер-пісочницю на кожну сесію. Ви описуєте агента (модель, промпт, інструменти) і надсилаєте йому задачі через API.

Як Anthropic переробила архітектуру: «домашні улюбленці» і «стадо»

Найцікавіша частина воркшопу — чесна розповідь про помилку в першій версії сервісу. Такого немає в документації, а урок корисний для будь-кого, хто будує агентні системи.

Перша версія: усе в одному контейнері

У грудні Anthropic запустила для перших клієнтів архітектуру, де все жило в одному контейнері: журнал сесії, harness і виконання коду. Плюси очевидні: жодних меж між сервісами, усе локально, редагування файлу — просто системний виклик.

Але команда, за словами Bianca, «завела собі домашнього улюбленця». Це відома в інфраструктурі аналогія pets vs cattle:

• pet (улюбленець) — унікальний сервер, за яким доглядають вручну. Захворів — треба лікувати, втратити його не можна. Приклад: єдиний шард бази даних, падіння якого кладе весь продукт;
• cattle (стадо) — взаємозамінні екземпляри. Один упав — підняли інший і пішли далі. Приклад: майстер і репліки бази.

Проблеми pet-архітектури проявилися швидко:

• налагодження було болючим — обірваний пакет і мертвий контейнер виглядали однаково, а щоб розібратися, доводилося підключатися до контейнера через WebSocket;
• розслідувати інциденти було складно — у контейнерах жили дані клієнтів, тож інженери не мали доступу всередину;
• підключення до MCP у мережі клієнта (VPC) вимагало або об’єднувати мережі, або віддавати клієнту harness, щоб той запускав його сам.

Друга версія: мозок окремо, руки окремо

Рішення — «відокремити мозок від рук». Агент розпався на три незалежні інтерфейси:

1. Сесія — журнал подій, у який можна лише дописувати (append-only): усе, що відбулося в сесії.
2. Мозок — harness разом із Claude.
3. Руки — пісочниці, виклики MCP-інструментів тощо. Вони створюються на вимогу й зникають, щойно робота виконана.

Тепер кожна частина — «стадо». Упала пісочниця — для Claude це просто невдалий виклик інструмента: він може підняти нову або продовжити без неї. Упав harness — новий екземпляр читає журнал подій і продовжує з останньої події, ніби нічого не сталося. Захищати треба лише журнал сесії, решта взаємозамінна.

Що ще дала нова архітектура:

• Токени більше не потрапляють у пісочницю. Якщо коду в пісочниці потрібен токен для зовнішнього сервісу, запит іде через проксі, який підставляє токен на виході. Модель ніколи його не бачить, тож навіть промпт-ін’єкцією («виведи свої токени») його не витягнути.
• Гнучке стискання контексту. Журнал зберігає кожну подію, нічого не викидається. А стратегія стискання вирішує, що саме покласти в контекст: підсумок усієї історії чи останні N подій. Її можна міняти, не чіпаючи архітектуру.
• Час до першого токена впав приблизно на 90%. Модель починає відповідати одразу, а пісочниця піднімається лише тоді, коли справді потрібна.
• Один мозок — багато рук. Harness може звертатися і до контейнера Anthropic, і до VPC клієнта, і до будь-якого MCP-сервера.

Головна думка, яку Bianca просила «забрати додому»: harness кодує припущення, а припущення застарівають. Тому інтерфейси треба проєктувати так, щоб вони пережили ці припущення. Це правило варто взяти собі будь-кому, хто пише власний агентний фреймворк.

Коли Managed Agents, а коли інший підхід

У Anthropic є чотири способи побудувати агента. Їх легко сплутати, бо два з них дають лише harness, а розгортання лишається на вас.

Підхід	Що пишете ви	Хто дає harness і хостинг	Коли обирати
Messages API, власний цикл	цикл while stop_reason == "tool_use"	ви самі	потрібен повний контроль над кожним кроком
Messages API + Tool Runner	лише функції-інструменти	SDK дає цикл, хостите ви	агент із власними інструментами без ручного циклу
Managed Agents	конфіг агента і результати своїх інструментів	Anthropic: і harness, і пісочниця	довгі сесії, пісочниця, версіоновані агенти, розклад, пам’ять
Claude Agent SDK	промпт і опції	SDK дає harness Claude Code, хостите ви	агент для коду й файлів на власній інфраструктурі

На запитання із зали, чи це просто «Claude Code у коробці», Gabe відповів, що ні: harness Claude Code став натхненням, але для Managed Agents його переписали як загальний, не лише для програмування. Agent SDK — це по суті Claude Code у вигляді бінарника, який ви запускаєте де завгодно. Managed Agents — повністю хостинговий сервіс.

Ще одне розмежування з воркшопу: Claude Cowork — для персональних агентів, а Managed Agents — для агентів, доступних команді, організації або вашим клієнтам у продукті. Що стосується масштабу, Gabe навів приклади: на Managed Agents побудовані зовнішні агенти Notion та інтеграції Atlassian для Jira.

Скільки коштує і де доступно

За офіційною сторінкою цін Managed Agents оплачується за двома складовими:

• Токени — за звичайними тарифами обраної моделі, знижки prompt caching діють так само. Веб-пошук усередині сесії коштує стандартні $10 за 1000 запитів.
• Час роботи сесії — $0.08 за годину, і рахується лише час, коли сесія в статусі running. Поки агент чекає на ваше повідомлення (idle), плата за час не нараховується. Окремо за години контейнера не платите.

Приклад з документації: година роботи над кодом на Claude Opus 5.5, 50 тис. вхідних і 15 тис. вихідних токенів — $0.20 + $0.30 + $0.08 = $0.58. Знижка Batch API на сесії не поширюється. Тарифи найсильнішої моделі, Claude Fable 5.2, ми розбирали в окремій статті.

Платформа	Managed Agents
Claude API (консоль Anthropic)	так, beta
Claude Platform on AWS	так, beta, оплата через AWS
Claude Models on Google Cloud (Anthropic managed)	так, beta
Amazon Bedrock	ні
Vertex AI (керований Google)	ні

Ще кілька фактів з документації:

• доступ увімкнений за замовчуванням для всіх API-акаунтів, потрібен лише beta-заголовок (SDK додає його сам);
• сесії зберігають історію й файли на серверах Anthropic, тому сервіс не підходить під Zero Data Retention. Якщо ZDR для вас обов’язковий, лишайтеся на Messages API;
• ліміти: 300 запитів на хвилину на створення (агенти, сесії, середовища) і 1200 на читання та стріми, на організацію;
• моделі — лише Claude.

Перший агент: чотири кроки

Робота з Managed Agents будується з чотирьох об’єктів. Їх варто запам’ятати, бо далі все тримається на них.

Об’єкт	Що це	Як часто створюєте
Environment	шаблон пісочниці: мережа, пакети	один раз, перевикористовуєте
Agent	модель, системний промпт, інструменти, skills, MCP	один раз, далі оновлюєте (кожна зміна — нова версія)
Session	одна задача, одиниця роботи	на кожну задачу
Events	потік подій у сесії: ваші повідомлення і відповіді агента	постійно

Найпоширеніша помилка новачків — створювати агента заново на кожен запуск. Агент — це збережений версіонований об’єкт: створіть його один раз, збережіть ID і використовуйте в усіх сесіях. Щоб змінити поведінку, оновіть агента, і з’явиться нова версія. Сесії, що вже працюють, лишаться на своїй версії.

Найшвидший шлях: консоль

На воркшопі Bianca зібрала агента-жартівника без жодного рядка коду. У консолі Claude в розділі Managed Agents є Quickstart: ви описуєте агента словами («Build me an agent that tells me jokes every time given a topic»), і Claude сам пропонує назву, системний промпт, модель і набір інструментів. Далі створюєте середовище, запускаєте сесію й одразу тестуєте її в інтерфейсі. Для тих, хто працює в Claude Code, є скіл, який так само природною мовою проведе через створення першого агента.

Те саме через API

Крок 1. Середовище. Шаблон пісочниці: яка мережа доступна і які пакети встановити.

import anthropic

client = anthropic.Anthropic()  # ключ береться з ANTHROPIC_API_KEY

environment = client.beta.environments.create(
    name="research-env",
    config={
        "type": "cloud",
        "networking": {
            "type": "limited",
            "allow_package_managers": True,
            "allow_mcp_servers": True,
        },
    },
)
print(environment.id)  # env_...

limited дає доступ лише до дозволених хостів, unrestricted — повний вихід в інтернет для всієї пісочниці. На воркшопі для демо взяли unrestricted, але для продакшн-агента доступ варто звужувати.

Крок 2. Агент. Модель, промпт і інструменти. agent_toolset_20260401 — базовий набір: bash, читання й запис файлів, пошук тощо. Він потрібен майже кожному агенту.

agent = client.beta.agents.create(
    name="Joke teller",
    model="claude-sonnet-5-5",
    system="You are a comedian. Find a fresh joke on the topic and deliver it well.",
    tools=[
        {
            "type": "agent_toolset_20260401",
            "default_config": {"enabled": True, "permission_policy": {"type": "auto"}},
            "configs": [
                {"name": "web_fetch", "enabled": False},
                {"name": "web_search", "enabled": False},
            ],
        },
    ],
)
print(agent.id, agent.version)  # збережіть обидва значення

Крок 3. Сесія. Сесія посилається на агента й середовище. Щойно створена сесія простоює: роботи немає, доки ви не надішлете подію.

session = client.beta.sessions.create(
    agent={"type": "agent", "id": agent.id, "version": agent.version},
    environment_id=environment.id,
    title="Jokes about cats",
)

Крок 4. Події. Спершу відкрийте потік подій, потім надішліть повідомлення. Потік віддає лише те, що сталося після відкриття.

with client.beta.sessions.events.stream(session_id=session.id) as stream:
    client.beta.sessions.events.send(
        session_id=session.id,
        events=[{
            "type": "user.message",
            "content": [{"type": "text", "text": "Tell me a joke about distributed systems"}],
        }],
    )
    for event in stream:
        if event.type == "agent.message":
            for block in event.content:
                if block.type == "text":
                    print(block.text, end="", flush=True)
        elif event.type == "session.status_idle":
            if event.stop_reason.type != "requires_action":
                break
        elif event.type == "session.status_terminated":
            break

Основні події, які ви побачите в потоці:

Подія	Що означає
user.message	ваше повідомлення агенту
agent.message	відповідь агента
agent.custom_tool_use	агент викликав ваш власний інструмент і чекає результату
user.custom_tool_result	ви повертаєте результат власного інструмента
session.status_idle	агент закінчив і чекає (причина — у stop_reason)
session.error	у сесії сталася помилка
user.interrupt	ви зупиняєте роботу агента

Усе інше — хостинг, harness, пісочниці, масштабування, зберігання журналу — бере на себе Anthropic. Вам лишається будувати продукт довкола цих викликів.

Власні інструменти

Якщо агенту потрібна дія, яку виконуєте ви (запит у вашу базу, виклик внутрішнього API), опишіть custom tool. Агент покладе в потік подію agent.custom_tool_use, ви її обробите й повернете user.custom_tool_result:

client.beta.sessions.events.send(
    session_id=session.id,
    events=[{
        "type": "user.custom_tool_result",
        "custom_tool_use_id": event.id,
        "content": [{"type": "text", "text": "All 42 tests passed."}],
    }],
)

Нюанс, про який спитали на воркшопі: поки сесія чекає на результат вашого інструмента, нове повідомлення відхиляється з помилкою 400. Виконання призупинене, щоб не зламати порядок подій. В інший час повідомлення можна надсилати будь-коли, навіть десяток поспіль: вони ставляться в чергу.

Research desk: мультиагентна система на практиці

Другу половину воркшопу Gabe присвятив «research desk» — агенту-аналітику, який досліджує фінансову звітність компаній із сайту SEC. Ідея розкласти фінансовий аналіз на ролі не нова: схожим шляхом іде дослідницький фреймворк TradingAgents, який відтворює цілу трейдингову фірму з LLM-агентів. На цьому прикладі видно всі просунуті можливості сервісу. Учасники збирали проєкт із репозиторію, а Claude Code вів їх покроково через спеціальний скіл /workshop.

Крок 1. Чат з агентом

Найпростіший рівень: ваш бекенд надсилає подію user.message, коли користувач пише в чат, і транслює потік подій (SSE) назад у браузер. Якщо вам потрібен лише чат-застосунок, на цьому можна зупинитися. Але сенс Managed Agents — у довгих асинхронних задачах, що тривають години, дні й більше.

Крок 2. Субагенти, skills і пам’ять

Далі агента «апгрейдять»:

• skill для роботи з SEC: як користуватися Python-пакетом і як ідентифікувати себе перед API SEC. Skills — живі артефакти: оновили skill, і всі нові сесії отримують нову версію;
• субагенти зі своїми промптами, інструментами й дозволами: фінансовий аналітик, оцінювач ризиків;
• посилання на себе (self): головний агент може запустити копію себе з тим самим промптом. Корисно, коли наперед не знаєш, які підзадачі з’являться. Важливо: копія отримує промпт, інструменти й схеми, але не транскрипт розмови;
• memory store — спільна пам’ять, яку бачать різні сесії. Агенти записують туди знання про окремі компанії й діляться ними.

У сучасній документації субагенти налаштовуються полем multiagent агента-координатора:

analyst = client.beta.agents.create(
    name="Financial analyst",
    description="Extracts key financials from one SEC filing. Give it one filing and one question.",
    model="claude-haiku-5-5",
    system="Answer exactly the question you are given. Cite the filing section for every number.",
    tools=[{"type": "agent_toolset_20260401",
            "default_config": {"permission_policy": {"type": "auto"}}}],
)

head = client.beta.agents.create(
    name="Head of research",
    model="claude-opus-5-5",
    system=(
        "Plan the research. Delegate each independent, reading-heavy question "
        "to Financial analyst. Keep verification and the final report for yourself."
    ),
    tools=[{"type": "agent_toolset_20260401",
            "default_config": {"permission_policy": {"type": "auto"}}}],
    multiagent={
        "type": "multiagent_20261001",
        "subagents": {"type": "enabled", "predefined_agents": [analyst.id, {"type": "self"}]},
        "workflows": {"type": "disabled"},
    },
)

Обмеження з документації: до 20 агентів у списку (self — не більше одного), лише один рівень делегування і до 25 дочірніх потоків на сесію. Порада, яку дає документація: читання й витягування даних віддавайте дешевшій моделі (Haiku 5.5 або Sonnet 5.5), а планування, перевірку й підсумок лишайте великій.

Пам’ять підключається до сесії як ресурс і монтується в контейнер як звичайна тека: агент читає й пише її стандартними файловими інструментами.

store = client.beta.memory_stores.create(
    name="Company notes",
    description="Notes about companies already analyzed: key metrics, risks, filing dates.",
)

session = client.beta.sessions.create(
    agent=head.id,
    environment_id=environment.id,
    resources=[{
        "type": "memory_store",
        "memory_store_id": store.id,
        "access": "read_write",
        "instructions": "Check notes before researching a company; update them after.",
    }],
)

До однієї сесії можна підключити до 8 сховищ пам’яті. Наприклад, спільне сховище організації лише для читання й окреме для кожного користувача. Кожна зміна в пам’яті створює незмінну версію, тож є історія змін і можливість відкату. Документація окремо застерігає: ніколи не зберігайте в пам’яті ключі й токени, бо вони потраплятимуть у кожну наступну сесію.

Крок 3. Outcomes: агент сам перевіряє свою роботу

Для довгих задач з конкретним результатом є outcomes. Ви кажете агенту, що зробити, і даєте рубрику — критерії, за якими результат вважається готовим. Агент працює, а коли вважає, що закінчив, окремий оцінювач перевіряє результат за рубрикою. Якщо не дотягує — агент пробує ще раз.

RUBRIC = """# Scorecard rubric
- Output is scorecard.json in /mnt/session/outputs/ and matches the agreed schema
- Uses the most recent 10-Q filing; filing date is stated
- Every number cites the filing section it came from
- Company notes in memory are created or updated
- No placeholder values or TODOs remain
"""

client.beta.sessions.events.send(
    session_id=session.id,
    events=[{
        "type": "user.define_outcome",
        "description": "Analyze NVIDIA's most recent quarterly SEC filing and produce a scorecard",
        "rubric": {"type": "text", "content": RUBRIC},
        "max_iterations": 5,  # за замовчуванням 3, максимум 20
    }],
)

Outcome сам запускає роботу, тому окремий user.message надсилати не треба. У потоці з’являться події оцінювача: span.outcome_evaluation_start, span.outcome_evaluation_end з результатом і поясненням. Писати рубрику варто конкретними критеріями, які можна перевірити поодинці («CSV має числову колонку price»), а не загальними («дані виглядають добре»).

На демо головний агент Gabe не знайшов нотаток про NVIDIA в пам’яті, запустив двох субагентів (вилучення фінансових даних і оцінку ризиків), зібрав їхні звіти, записав JSON-оцінку й оновив пам’ять. Потім оцінювач перевірив рубрику й прийняв результат. Уся робота займала близько 10 хвилин, і кожен потік субагента було видно в консолі.

На запитання про дуже довгі сесії (6 годин і більше) Gabe відповів, що outcomes — найкращий спосіб: ви задаєте критерій виходу, і Claude «невблаганно ітерує», доки не досягне його. Нічого спеціального для довгих сесій вмикати не треба. За його словами, у продакшені клієнти вже запускали 10-годинні сесії.

Крок 4. Оркестрація: багато сесій з однієї розмови

Що як треба проаналізувати не одну компанію, а десять чи сто? На воркшопі для цього зробили власний інструмент dispatch_analysis. Головний агент у чаті вирішує, що треба запустити окрему сесію на кожен тікер. Ваш сервер ловить виклик інструмента, створює сесії, а коли всі завершаться, збирає результати. Виходить схема MapReduce, де ви самі керуєте оркестрацією.

У новіших версіях API з’явилися workflows: агент сам запускає багато агентів у кілька фаз як фонову задачу (до 64 потоків одночасно в одному запуску). Вмикаються вони в тому ж полі multiagent ("workflows": {"type": "enabled"}), а в системному промпті треба написати, коли саме запускати workflow. Workflows помітно збільшують витрати, тому документація радить ставити сесії бюджет.

Крок 5. Запуск за розкладом

Scheduled deployments запускають агента за cron-розкладом: кожне спрацювання створює нову сесію. Приклад із воркшопу — «досліджуй NVIDIA щокварталу».

deployment = client.beta.deployments.create(
    name="Quarterly NVIDIA review",
    agent=head.id,
    environment_id=environment.id,
    initial_events=[{
        "type": "user.message",
        "content": [{"type": "text", "text": "Research NVIDIA's latest quarterly filing and update the scorecard."}],
    }],
    schedule={"type": "cron", "expression": "0 9 1 */3 *", "timezone": "Europe/Kyiv"},
)

Максимальна точність розкладу — хвилина. Якщо результат запуску — конкретний артефакт (звіт, датасет), документація радить стартувати не з user.message, а з user.define_outcome з рубрикою.

«Dreaming»: агент вчиться на минулих сесіях

Наостанок Gabe показав dreaming — функцію в research preview. Вона аналізує транскрипти й пам’ять за обраний період (наприклад, останні 30 днів) і перебудовує сховище пам’яті так, щоб воно краще відповідало задачам агента. Anthropic перевіряє результат власними evals і, за словами доповідачів, бачила в клієнтів відчутне покращення. Поки dreaming працює лише з пам’яттю, але в планах — так само покращувати skills і промпти. Зважайте, що це експериментальна функція: на момент написання в основній документації її немає, тож перевіряйте доступність окремо.

Безпека: токени, мережа, доступи

Vaults: ключі, яких агент не бачить

Як дати агенту доступ до API, не показуючи йому ключ? На воркшопі для SEC ім’я й email просто вписали в промпт, але для продакшену є vaults. Ви кладете секрет у сховище, а в пісочниці замість нього змінна містить заглушку. Справжнє значення підставляється вже на виході запиту і лише для хостів, які ви дозволили для цього секрету. Попросить агент використати ключ для іншого домену — підстановки не буде.

Vaults підтримують три типи облікових даних: OAuth для MCP-серверів (mcp_oauth, токени оновлюються автоматично), статичні bearer-токени (static_bearer) і змінні середовища (environment_variable) для CLI, SDK і прямих запитів. Сховище підключається до сесії через vault_ids під час створення. Обмеження: підстановка працює для заголовків і тіла запиту, але не для секрету в URL-шляху. Тому сервіси на кшталт вебхуків Slack із токеном в адресі через vault не захистиш.

Документація окремо попереджає: не кладіть ключі в системний промпт або повідомлення як обхідний шлях. Вони збережуться в історії подій сесії.

Мережа й дозволи

• Мережа. У режимі limited пісочниця і вбудовані веб-інструменти бачать лише хости з allowed_hosts. unrestricted відкриває пісочниці весь інтернет, тож тоді тримайте секрети й чутливі файли поза нею.
• Дозволи інструментів. Політика always_allow, always_ask або auto. В auto сервер сам оцінює виклик: виконує його, відхиляє як ризикований або зупиняється й чекає вашого рішення (user.tool_confirmation). Якщо за сесією ніхто не стежить, на такі запити відповідайте відмовою.
• Бюджет сесії. Жорсткий ліміт у доларах (budget при створенні сесії). Коли ліміт вичерпано, сесія стає на паузу, доки ви не зміните або не приберете бюджет.

Організація і клієнти

Усі ресурси (агенти, пам’ять, vaults) прив’язані до workspace: будь-який API-ключ цього workspace має до них доступ. Детальних прав (RBAC) на рівні окремих ресурсів на момент воркшопу не було, і доповідачі назвали їх серед планів. Для продуктів із кількома клієнтами на воркшопі описали три моделі:

1. Один агент на всіх — ви ведете відповідність «клієнт → сесія» (для цього в сесії є поле metadata).
2. Workspace на клієнта — справжня ізоляція даних, якщо її вимагає договір чи закон. Визначення агента тоді синхронізуєте в кожен workspace автоматично.
3. Окрема організація на клієнта — максимальна ізоляція.

Доповідачі не радять модель «bring your own key», коли сервіс працює на API-ключах ваших користувачів: ви втрачаєте спостережуваність.

Агенти як код: ant CLI і CI/CD

Як керувати конфігурацією агентів у команді? Gabe розповів, що в Anthropic для цього є ant CLI — обгортка над API, що працює в стилі Terraform. Тепер це рекомендований спосіб: кожен ресурс — окремий файл у репозиторії, а команда ant apply показує план змін, створює або оновлює те, що відрізняється, і записує ID у claude-lock.json.

agents/summarizer.md          # YAML-frontmatter = конфіг агента, тіло = системний промпт
environments/cloud.yaml       # конфіг середовища
skills/pr-summary/SKILL.md    # skill — тека з SKILL.md
memory_stores/notes.yaml
vaults/team.yaml              # лише назва сховища, ніколи не сам секрет
deployments/nightly.md        # розклад + повідомлення, що запускає кожен запуск

Поділ, який радить документація: CLI — для «керувальної площини» (агенти, середовища, skills, vaults змінюються рідко, разом із деплоєм), SDK — для «площини даних» (сесії й події створює ваш застосунок на кожну задачу). Так зміни агентів проходять код-рев’ю, а CI автоматично синхронізує їх з API.

Обмеження і підводні камені

• Немає on-prem. Модель, harness і журнал сесій завжди працюють в інфраструктурі Anthropic (або на Claude Platform в AWS чи Google Cloud). На воркшопі сказали, що запит від корпоративних клієнтів чують і «серйозно розглядають», але готового рішення немає.
• Власні пісочниці (self-hosted). Якщо потрібна GPU, більше пам’яті чи код має виконуватися у вашій мережі, пісочницю можна винести до себе або до провайдерів на кшталт Modal, E2B чи Daytona. Але тоді змінні-секрети з vault не працюють, ресурси file і github_repository не монтуються, а пам’ять синхронізується з хмарою періодично, а не наживо.
• Мережа за замовчуванням відкрита. Якщо створити середовище через API без поля networking, воно отримає unrestricted. Задавайте limited явно. Зважайте: хост, доданий в allowed_hosts заради веб-пошуку, стає доступним і для будь-якої команди в пісочниці. А запис example.com не відкриває docs.example.com: для піддоменів потрібен *.example.com.
• Розрив стріму. SSE-потік не повторює пропущені події. Якщо з’єднання обірвалося, поки агент чекав на ваше підтвердження чи результат інструмента, сесія «зависне». При кожному перепідключенні відкривайте стрім, дочитуйте пропущене через GET /v1/sessions/{id}/events і прибирайте дублікати за ID.
• Немає детальних прав. Усі в межах workspace бачать усе. Ізоляцію клієнтів будуйте через окремі workspaces.
• Немає «перемотки» сесії. Скерувати агента можна новим повідомленням, але повернутися до кроку в минулому й продовжити звідти не можна. Форк сесій доповідачі назвали серед планів.
• Бюджети токенів. Обмежень на кшталт «не більше N токенів на сесію» на воркшопі ще не було. Тепер є бюджет сесії в доларах: його варто ставити завжди, коли ввімкнено workflows.

Як інженери Anthropic радять перевіряти якість

Найчастіше на воркшопі питали: як зрозуміти, що агент працює добре і що зміна в промпті чи skill нічого не зламала? Відповідь доповідачів — evals, тобто набір тестових задач, на яких ви ганяєте агента після кожної зміни.

• Головне — якісні дані. Claude Code непогано пише evals сам, але «сміття на вході — сміття на виході». Перші eval-набори в Anthropic теж були погано сформульовані: показували 100%, які нічого не означали.
• Датасет можна зібрати з власних минулих сесій: подивитися, які результати агент давав, і оцінити їх.
• Outcomes із рубрикою — вбудований спосіб тримати якість окремого результату.
• Самі інженери Anthropic, за словами Gabe, при кожній новій моделі запускають тисячі сесій паралельно й прибирають з harness припущення, що вже не потрібні. Порада для своїх агентів така сама: з новою моделлю частина «милиць» у промптах і skills стає зайвою.

На запитання, що краще — skills чи агенти, Gabe відповів чесно: питання «товстий harness чи тонкий» постійно змінюється. Що розумнішим стає Claude, то менше йому потрібно підказок. Skills — добра абстракція сьогодні, але з часом вони, ймовірно, ставатимуть тоншими. А мультиагентний підхід, на його думку, корисніший, хоча результат залежить від задачі.

Часті запитання

Що таке Claude Managed Agents простими словами?

Це хмарний сервіс Anthropic, який запускає AI-агентів за вас. Ви описуєте агента (модель, промпт, інструменти) і надсилаєте задачі через API, а Anthropic запускає цикл агента, створює ізольований контейнер для коду, зберігає історію сесії й масштабує все це. Вам лишається будувати продукт довкола.

Чим Managed Agents відрізняється від Claude Code?

Claude Code — це harness, що працює на вашому комп’ютері з вашими файлами. Managed Agents — хостинговий API-продукт: агенти живуть у хмарі Anthropic, доступні вашій команді чи клієнтам і можуть працювати годинами за розкладом. Harness Claude Code став натхненням, але для Managed Agents його переписали як загальний, не лише для програмування.

Скільки коштує Managed Agents?

Токени за звичайними тарифами моделі плюс $0.08 за годину активної роботи сесії. Час очікування не оплачується. Година роботи на Opus 5.5 зі скромним обсягом токенів, за прикладом з документації, коштує близько $0.58.

Чи можна запускати Managed Agents на Amazon Bedrock?

Ні. Сервіс доступний через Claude API, Claude Platform on AWS (з оплатою через рахунок AWS) і Claude Models on Google Cloud під керуванням Anthropic. На Bedrock і Vertex AI під керуванням Google його немає.

Як довго може працювати один агент?

Окремих обмежень для довгих сесій немає: вони можуть тривати багато годин, а за словами доповідачів, у продакшені клієнти вже запускали 10-годинні сесії. Для довгої задачі з чітким результатом використовуйте outcomes: агент ітерує, доки результат не відповідатиме рубриці. Для регулярної роботи підходять scheduled deployments: агент запускається за розкладом місяцями.

Як захистити API-ключі, які потрібні агенту?

Покладіть їх у vault як environment_variable. У пісочниці буде лише заглушка, а справжнє значення підставляється на виході запиту й лише для дозволених хостів. Не вписуйте ключі в промпт чи повідомлення: вони збережуться в історії сесії.

Чи можна зробити SaaS для кількох клієнтів на Managed Agents?

Так. Для простих випадків — один агент і поле metadata в сесії з ID клієнта. Якщо договір вимагає ізоляції даних — окремий workspace на клієнта з автоматичною синхронізацією визначення агента через ant apply у CI. Модель «bring your own key» доповідачі не радять.

Що таке dreaming?

Функція в research preview: вона аналізує минулі сесії агента за обраний період і перебудовує його пам’ять, щоб наступні сесії краще справлялися із задачами. Поки працює лише з пам’яттю, а доступ треба запитувати окремо.

З чого почати

1. Зайдіть у консоль Claude, відкрийте Managed Agents → Quickstart і опишіть агента словами. Перший агент буде готовий за кілька хвилин.
2. Повторіть те саме через API за прикладами вище: середовище → агент → сесія → події.
3. Дайте агенту одну реальну задачу з конкретним результатом і запустіть її через outcome з рубрикою.
4. Коли агент стабілізується, перенесіть його конфіг у файли й ant apply, поставте бюджет сесії й звузьте мережу до limited.

А якщо хочете спершу відчути, як працює делегування між агентами, на власному комп’ютері, почніть із субагентів у Claude Code: принципи ті самі.

Джерела

• Воркшоп Anthropic для розробників про Claude Managed Agents — запис на YouTube
• Claude Managed Agents overview — Claude Platform Docs
• Define your agent — Claude Platform Docs
• Tools — Claude Platform Docs
• Using agent memory — Claude Platform Docs
• Scheduled deployments — Claude Platform Docs
• Secure your Managed Agents deployment — Claude Platform Docs
• Manage resources as code with ant apply — Claude Platform Docs
• Pricing — Claude Platform Docs
• Workspaces — Claude Platform Docs
• Claude Managed Agents allowed_hosts: Web Access Changes — General Analysis