When Managed Agents are not enough: a platform for running agents

What does such a platform give you?

Mental model:

company infrastructure
-> agent runtime
-> agent
-> Claude
-> tools / data / services

The platform takes responsibility for things such as:

• hosting agents,
• sessions,
• scaling,
• identity and IAM,
• networking,
• secrets,
• observability,
• governance,
• integration with the rest of the infrastructure.

Claude still handles reasoning.

What changes is mostly where the agent lives and how the organization manages it.

Examples of this class of tools

This category includes:

• Google Vertex AI Agent Engine,
• Amazon Bedrock AgentCore,
• Microsoft Foundry Agent Service,
• platforms built internally on Kubernetes / serverless runtimes.

You do not have to choose one immediately.

The more important thing is recognizing the moment when Claude-native Managed Agents stop matching organizational requirements.

When are Managed Agents enough?

If your world looks roughly like this:

Claude
-> repository
-> tools
-> MCP
-> skills

and you simply need a remote, managed environment for Claude, Managed Agents are a natural choice.

You have few layers.

You can quickly move from:

local Claude Code

to:

managed execution

without building your own platform.

When do you start looking further?

1. The organization has its own platform standards

For example:

every workload must use our IAM
all logs go to one system
secrets must be managed centrally
network access must go through our policies

The agent becomes another infrastructure workload.

You do not want exceptions only because it is an agent.

2. You want to support more than one model or framework

Today you can be Claude-first.

But the organization's platform may need:

Claude
another model
custom agent framework
agent written by another team

Then a more neutral runtime starts making sense.

3. You need central governance

With a few agents, everything can be managed manually.

With dozens, questions appear:

who can run which agent?
what data does it access?
which tools can it execute?
how much does it cost?
where are the logs?
how do we turn it off?

This stops being one developer's problem.

It becomes a platform engineering problem.

4. The agent must strongly integrate with the existing cloud

If the agent needs to use:

internal services
private networking
service accounts
cloud databases
event bus
secret manager
central observability

running it directly on the same platform can be simpler than building bridges to a separate runtime.

Example architecture

Claude-first:

SDLC event
-> Claude Managed Agent
-> Claude
-> repository / tools

Platform-first:

SDLC event
-> company agent platform
-> agent runtime
-> Claude-powered agent
-> company services / data / tools

Claude does not disappear.

The layer around it changes.

This is still not an orchestrator

Do not mix this with the previous article.

Tools such as:

Trigger.dev
Hatchet
Temporal
Inngest
Restate

mainly handle:

workflow
state
retry
wait
event
approval

An agent runtime handles:

where the agent runs
how it is started
how it receives identity
how it scales
how it is observed

So you can have both:

GitHub event
-> Trigger.dev
-> Agent Runtime
-> Claude agent
-> result
-> Trigger.dev
-> next step

These are different layers.

Implement this today

Do not migrate anything.

Do a simple evaluation of your setup.

If Managed Agents meet the requirements:

stay with them

If you start having requirements such as:

central IAM
private networking
multi-model
enterprise governance
shared observability stack
custom deployment policies

start looking at agent runtime platforms.

Not because Claude stopped being enough.

But because the agent runtime became part of the infrastructure problem.

Level complete

The level is complete when you can separate three layers:

Claude
= reasoning

orchestrator
= supervises workflow

agent runtime
= hosts and manages the agent

And you can recognize the moment when Claude Managed Agents are enough, and the moment when you need a more platform-oriented approach.

Materials

• Vertex AI Agent Engine overview
• Amazon Bedrock AgentCore documentation
• Microsoft Foundry Agent Service overview