The build shapes on Foundry, and how to choose

Once you have decided a step genuinely needs an agent, the next question is what
kind. Foundry gives you a few shapes, and the choice is made by what the scenario
constrains — not by how complicated the task sounds.

The shapes

Prompt agent. The agent is expressed as instructions plus a set of tools.
Foundry runs it. There is the least for you to manage, which is exactly the point.

Hosted agent. You bring your own code. This is where you land if you need a
framework, custom protocols, a specific amount of CPU or memory, state that
persists across turns, or resilience behaviour you control.

Responses API. You already run the agent somewhere else and you want its output.
Foundry calls it; it stays where it lives.

A2A. Another team owns the agent, you cannot change it, and you want its
judgement rather than its output.

How the scenario tells you which

The tell is almost never the complexity of the task. It is an infrastructure or
ownership constraint dropped into the setup.

"Minimise what we have to operate" → prompt agent.

"It needs four gigabytes of memory" or "it must keep state between turns" →
hosted agent, however simple the task reads.

"We already run this in our own environment" → Responses API.

"Another team owns it and will not rewrite it" → A2A.

That third and fourth pair are worth separating carefully, because both involve
something that already exists elsewhere. The difference is what you want from it —
its output, or its judgement. If you want a result you could have computed
yourself given the same tools, that is an output. If you want a decision made by
someone else's model with someone else's instructions, that is judgement, and it
belongs behind A2A.

Where the framework argument resolves

This is worth stating plainly because it comes up constantly.

LangGraph, LangChain and custom code all run as a hosted agent. The framework
you write in does not change the deployment shape. So "should we use LangGraph or
Agent Framework" is a genuine engineering question about ergonomics and features,
and it is not a question about how the thing gets deployed on Foundry.

Which means an option that treats framework choice as a deployment decision has
confused two different things.

The property that makes the security domain possible

A hosted agent is "assigned a dedicated Microsoft Entra ID (agent identity)" on
deployment, and gets a dedicated endpoint.

That single fact is worth carrying forward, because almost everything in the
security cards depends on it. An agent with its own identity can be granted,
scoped, audited and revoked individually. An agent sharing a service account
cannot — and no amount of policy fixes that afterwards.

The trap

Read for the infrastructure constraint, not the task's apparent difficulty.

A scenario can describe something that sounds trivially simple and then mention, in
one clause, that it needs a specific memory allocation or has to hold state between
turns. That clause rules out the prompt agent entirely, and it is easy to skim past
on the way to the answer options.