Agentic AI platform in the EU: build it on Claude
What an internal agentic platform on Claude needs in the EU: the harness choice, the gateway requirements, residency limits, and which parts you should not build.
TL;DR
An internal agentic platform on Claude is four components: a harness that runs agent loops, a gateway that carries identity and residency, a tool layer over your systems, and observability. Anthropic now ships the first two, which changes the build decision. The part worth building yourself is the tool layer, because only you know your systems.
What does an agentic platform actually have to provide?
An agentic platform provides four things an application team cannot build repeatedly: a place for long-running agent loops to execute, an identity and routing layer that enforces who may call which model where, a governed tool and connector layer, and per-user observability. Everything else is application code.
The reason to centralise is not elegance. It is that each of the four has a compliance consequence, and letting ten teams solve them separately produces ten different answers to the question of where prompts are processed. Centralise the compliance surface and let teams own their agents.
| Component | What it owns | Build, buy or configure |
|---|---|---|
| Harness | Agent loop, tool execution, sandboxes, session state | Buy or configure. Anthropic ships one |
| Gateway | Identity, model access per group, routing, residency | Configure. A supported component exists |
| Tool layer | Access to your systems through MCP and APIs | Build. Nobody else can |
| Observability | Per-user tokens, cost, traces, evaluation | Configure. Use your existing stack |
Harness: build the agent loop or use Claude Managed Agents?
Use the managed harness unless you need control over the loop itself or a data protection posture it cannot meet. Anthropic’s Claude Managed Agents provides the harness and the runtime, so the choice is no longer “build a loop or use the Messages API directly”.
The managed harness is built on four concepts: an agent (model, system prompt, tools, MCP servers and skills), an environment (where sessions run), a session (a running instance doing a task) and events (messages between your application and the agent). Sessions are stateful by design, resume after pauses, and persist conversation history and sandbox state server-side. Built-in tools cover Bash, file operations, web search and fetch with domain allowlists or blocklists, and MCP servers. Scheduled deployments run agents on a cron schedule.
Two facts decide whether it fits a European deployment. First, the environment can be a self-hosted sandbox on infrastructure you control, which is the option Anthropic names for compliance and data residency requirements: tool execution and the sandbox filesystem stay on your infrastructure, while attached memory stores remain stored by Anthropic and are copied into your sandbox for the session. Second, because sessions are stateful, Managed Agents is not currently eligible for Zero Data Retention or for HIPAA Business Associate Agreement coverage. You can delete sessions and uploaded files through the API, but the eligibility gap is structural rather than a configuration you can change.
Our recommendation:
| Your constraint | Harness choice |
|---|---|
| Long-running tasks, no ZDR requirement | Claude Managed Agents with a cloud sandbox |
| Tool execution must stay on your infrastructure | Claude Managed Agents with a self-hosted sandbox |
| Zero Data Retention is contractually required | Build on the Messages API, keep state yourself |
| You need to control the loop, the retries and the tool dispatch | Build on the Messages API or the Agent SDK |
| Agents are developer-facing, inside the IDE and CLI | Claude Code with subagents, not a separate harness |
It is still in beta behind the managed-agents-2026-04-01 header, enabled by default for API accounts, with MCP tunnels and dreaming in a narrower research preview. Plan for the interface to move. Our Claude Agent SDK guide for the EU covers the build-it-yourself route on Bedrock and Google Cloud.
Gateway: what does the identity and residency layer require?
The gateway is where residency and identity stop being a policy and become a configuration. For organisations that must route inference through their own cloud provider, the Claude apps gateway is the supported pattern, and its requirements are specific enough that they belong in your platform design before anything else.
What it is: a self-hosted single Linux binary that sits in front of Amazon Bedrock, Claude Platform on AWS, Google Cloud or Microsoft Foundry, signs developers in against your identity provider, enforces per-group model access, and emits OpenTelemetry metrics carrying token counts, model, user identity and latency by default, with logs and traces as per-destination opt-ins.
What it requires, each of which has blocked a rollout somewhere:
- Claude Code v2.1.195 or later on the gateway server and on every developer machine. The Claude Platform on AWS upstream needs v2.1.198 or later on the server, and the Claude Desktop connection needs v2.1.203 or later.
- An OIDC identity provider. Okta, Microsoft Entra ID, Google Workspace, Keycloak, Dex or any other OIDC-compliant provider. SAML and LDAP are not supported, which rules out a surprising number of enterprise identity estates without a bridge.
- PostgreSQL 11 or later, backing the device sign-in flow and rate-limit counters, and holding durable spend, audit and identity tables once spend limits are on. Back it up.
- A private-network address. At sign-in, Claude Code requires the gateway hostname to resolve only to private addresses: RFC 1918, link-local, CGNAT
100.64.0.0/10, IPv6 ULAfc00::/7or loopback. Organisations numbering internal networks from public space they own must declare those blocks explicitly.
Two design consequences follow immediately. Boot is fail-closed for the config, the Postgres connection, OIDC discovery and upstream client construction, so the gateway exits rather than serving traffic in a degraded state. That is the right behaviour and it means the gateway is a production dependency with the availability requirements of one. And there is no service-token flow for unattended pipelines: gateway sign-in always runs the browser device flow, so CI jobs authenticate against the cloud provider directly and the gateway settings stay off CI runners.
The data-plane property worth quoting to a works council or a DPO: the gateway’s own data plane sends nothing to Anthropic infrastructure unless the Anthropic API is a configured upstream. Telemetry, audit logs, managed settings and developer identity stay where you put them.
One trade-off to decide consciously: gateway sessions do not fetch the server-managed settings configured in the claude.ai admin console, so policy has to be delivered from the gateway’s own managed block instead. You get residency and provider control, and you give up some of the Enterprise-plane features. Our LiteLLM EU gateway guide covers the multi-vendor proxy alternative.
Where does residency actually get decided?
Residency is decided by the route, not by a setting on the platform. On the first-party Claude API, inference_geo accepts only "global" and "us", and workspace geo offers only "us" and cannot be changed after creation. On Amazon Bedrock and Claude models on Google Cloud (Google managed), inference_geo does not apply at all: the endpoint URL or the inference profile determines the region.
That single asymmetry drives most EU platform architectures. If the requirement is EU-region processing, the platform routes through a regional endpoint on a partner platform, and the gateway or the application selects it. The data residency page sets out the rest: US-only inference costs 1.1x the standard rate on Claude 4.6 and later models, workspace-level allowed_inference_geos and default_inference_geo can enforce a policy across every key in a workspace, and rate limits are shared across geos.
Four verification steps belong in the platform’s own runbook, not in a document:
- Assert the configured geo per workspace after every change, because a new workspace does not inherit the old one’s setting.
- Assert the endpoint or inference profile per region on the cloud routes, because that is what actually decides where inference runs.
- Record the response
usage.inference_geofield in your telemetry, so you can prove after the fact where a request ran. - Re-check after every model generation change, since
inference_geois supported only on Claude 4.6 and later and older models return a 400 error.
What does the platform cost to run?
Three cost lines: tokens, the parallelism multiplier, and the platform’s own infrastructure. Tokens follow published rates. Parallelism is the line that surprises people. The infrastructure is small by comparison and often the only line in the plan.
Token rates from the pricing page: Sonnet 5.5 at 2 USD input and 10 USD output per million with cache hits at 0.10 USD, Opus 5.5 at 4 USD and 20 USD with cache hits at 0.20 USD, and a 10 percent premium for regional or multi-region endpoints. Agentic workloads are cache-heavy by nature, since the system prompt, tool definitions and skill content repeat, so the cache rate matters more here than in a chat workload.
Parallelism is where agentic platforms differ from everything else. Agent teams in Claude Code use approximately 7 times more tokens than standard sessions when teammates run in plan mode, because each teammate carries its own context window. The same arithmetic applies to any fan-out pattern you build: concurrency multiplies context, and context is the cost. Design the fan-out with a budget rather than discovering it.
| Cost line | Driver | Control |
|---|---|---|
| Tokens, steady state | Context size per step, number of steps | Prompt caching, smaller models for sub-steps |
| Tokens, fan-out | Number of parallel agents | Cap concurrency, use Haiku or Sonnet for workers |
| Residency premium | Regional endpoints | Route only the workloads that need it |
| Gateway infrastructure | One Linux host plus managed PostgreSQL | Smallest tier works for the database |
| Observability | OTLP volume | Sample traces, keep metrics complete |
Our Claude API pricing guide for the EU holds the current per-route rate tables, and our Langfuse self-hosting guide covers the observability layer in the EU.
Run it yourself or outsource?
Build the tool layer yourself and configure the rest. The harness and the gateway are now products with documented requirements, so the engineering value sits in the MCP servers and APIs that expose your own systems safely. That is also the part an external party cannot do well, because it depends on knowing which fields in your systems are dangerous.
| Workstream | Effort | Build or buy |
|---|---|---|
| Harness selection and first agent | 10 to 15 days | Configure |
| Gateway deployment with identity provider | 10 to 20 days | Good outsourcing candidate |
| MCP servers over internal systems | 15 to 30 days per system | Build in house |
| Observability pipeline and evaluation harness | 15 to 25 days | Mixed |
| Residency verification runbook | 5 days | Build in house |
| Model migration and regression testing | 5 days per generation | Build in house, run regularly |
Our view: the gateway is the best outsourcing candidate on this list, because the requirements are precise, the failure modes are fail-closed, and identity provider configuration eats a fortnight for a first-time team. The MCP tool layer is the worst, because an external party will expose the API that is easy to call rather than the one that is safe to call. Our Claude MCP guide for the enterprise covers the approval and security model for that layer. A platform for staff chat rather than agents is a different build: our internal AI platform guide covers LibreChat and Open WebUI on Bedrock, and our LLMOps guide the operating model around both.
What to demand from anyone building an agentic platform for you:
- A harness decision with the Zero Data Retention consequence stated, not deferred.
- The residency route named, with the verification step automated rather than documented.
- A concurrency budget for every fan-out pattern, with the multiplier shown.
- Per-user attribution working, including on the cloud routes where Anthropic’s dashboards see nothing.
- The tool layer delivered as code in your repository, with the dangerous operations explicitly out of scope.
An agent that reaches customers under your brand raises a question an internal platform does not: whether you have become the provider of that system under the AI Act. Our AI disclosure guide covers the three reclassification triggers and the disclosure duties that apply from the first interaction.
FAQ
What is an agentic AI platform?
An agentic AI platform is the shared layer that lets several teams run Claude-based agents without each solving the same problems: a harness for long-running agent loops, a gateway for identity and model routing, a governed tool layer over internal systems, and per-user observability. Teams own their agents; the platform owns the compliance surface.
Should we use Claude Managed Agents or build our own loop?
Use Claude Managed Agents for long-running and asynchronous work unless you need Zero Data Retention or control over the loop itself. It supplies the harness, sandboxes, session state and scheduled deployments, and supports self-hosted sandboxes where tool execution must stay on your infrastructure. It is in beta and not eligible for ZDR or HIPAA BAA coverage.
What does the Claude apps gateway require?
Claude Code v2.1.195 or later on the server and every client, an OIDC identity provider (SAML and LDAP are not supported), PostgreSQL 11 or later, and a hostname resolving only to private addresses. Boot is fail-closed, and there is no service-token flow, so CI authenticates against the cloud provider directly.
Can an agentic platform keep inference in the EU?
Yes, through regional endpoints on Amazon Bedrock, Google Cloud or Microsoft Foundry, where the endpoint or inference profile determines the region. The first-party Claude API offers only "global" and "us" for inference and only "us" for workspace geo, so EU-region processing comes from the partner platforms.
What does an agentic platform cost to run?
Tokens dominate: Sonnet 5.5 at 2 USD input and 10 USD output per million, Opus 5.5 at 4 USD and 20 USD, plus 10 percent for regional endpoints. The parallelism multiplier is the line to plan for, since fan-out patterns multiply context, and agent teams in Claude Code use around 7 times more tokens than standard sessions in plan mode.
Managed harness vs self-built: which is cheaper?
The managed harness is cheaper to start and cheaper to operate, because the sandbox, session state and tool execution come with it. Self-building wins when you need Zero Data Retention, when the loop has requirements the harness does not meet, or when you already run the infrastructure for other workloads and the marginal cost is low.
Sources
- Anthropic: Claude Managed Agents overview (28 October 2026)
- Claude Code: Claude apps gateway (28 October 2026)
- Anthropic: Data residency (28 October 2026)
- Anthropic: Model and feature pricing (28 October 2026)
- Claude Code: Manage costs effectively (28 October 2026)
- Anthropic Support: What is the Enterprise plan (28 October 2026)