Which set of things must you define when building a Foundry agent?
Why D is the answer
The agent's role, its goals, how it tracks conversation, and its tool schemas
An agent is defined by its role, goals, conversation tracking and tool schemas. Infrastructure choices are a separate concern.
In detail
- You define the agent's role, goals, conversation handling and tool schemas.
- Clear tool schemas help the model call them correctly.
Use case
An illustrative scenario, not a real incident.
A team defines its agent: a support role, the goal of resolving tickets, how it tracks the conversation, and schemas for two tools.
See it in different ways
flowchart LR A["Model"] --> D["Agent"] B["Instructions"] --> D C["Tools: file search, web search, code interpreter, MCP, functions"] --> D D --> E["Conversation and actions"]
mindmap
root((Foundry agent))
Definition
Role
Goals
Conversation state
Tools
Code interpreter
Custom functions
Tool schemas
Hosting
Prompt agent
Hosted agent
Control
Human approval
Monitoringmindmap
root(("Foundry agent"))
n1["Role"]
n2["Who it is"]
n3["Goals"]
n4["What it achieves"]
n5["Conversation"]
n6["How it tracks state"]
n7["Tools"]
n8["Schemas"]Key point: Define role, goals, state and tool schemas.
Why the other options are wrong
- A. The GPU model, the driver version and the CUDA runtime the agent needs
- The platform manages the GPU stack.
- B. The hash of the training data and the fine-tuning parameters
- Those are details of fine-tuning.
- C. The virtual network's subnet size and its peering configuration
- Network sizing is not part of defining an agent.