Core Concepts

Four ideas that show up across every Foundry baseline. Understanding them up front makes the rest of the docs easier to navigate.

A2A Protocol (Agent-to-Agent)

A2A is a standardized HTTP interface that lets agents discover, call, and stream from one another regardless of who built them.

Foundry agents implement A2A as JSON-RPC 2.0 over HTTP, plus a discovery document:

Surface	Location	Purpose
Agent card	GET /.well-known/agent-card.json	Discovery — name, capabilities, endpoints
JSON-RPC endpoint	POST /	All A2A methods: message/send, message/stream, tasks/get, tasks/cancel

A2A provides:

• Interoperability — any framework can implement A2A
• Discoverability — agents publish what they can do
• Orchestration — workflow engines can coordinate multiple agents
• Standardization — consistent patterns across all agents

See the Strands Base Agent A2A guide for the wire format and an implementation walkthrough.

MCP (Model Context Protocol)

MCP is an industry-standard protocol for connecting agents to tools — file systems, databases, APIs, anything the agent needs to reach beyond its own process.

Why MCP matters:

• Standardized tools — consistent interface across every tool
• Reusability — share MCP servers across agents
• Isolation — tools live behind their own service boundary, separate from the agent
• Extensibility — drop in new capabilities without changing the agent

In the Strands Base Agent, MCP servers are reached over HTTP (streamablehttp_client) and wired in via YAML — no code changes to add or remove a server. See the Strands Base Agent MCP guide for a working setup.

Sessions

Sessions persist conversation state across calls so an agent remembers what was said earlier. Without sessions, every request is a cold start.

In Foundry, sessions are addressed by ID:

• REST — pass session_id in the request body
• A2A JSON-RPC — pass contextId on the message

The session backend is pluggable per baseline. The Strands Base Agent supports file, s3, and dynamodb session types out of the box.

See the foundry-strands-agent package for session backend options.

Configuration-First Architecture

Agent behavior is defined in declarative YAML, not code. The same configuration file runs in dev, staging, and prod — per-environment differences are applied through environment variables that override individual YAML keys.

# config.yaml — Strands Base Agent
agent_name: my-agent

model:
  provider: bedrock
  model_id: us.anthropic.claude-haiku-4-5-20251001-v1:0

tools_modules:
  - strands_base_agent.tools

Any key in the file can be overridden at runtime with a STRANDS__-prefixed environment variable that mirrors the YAML key path (double-underscores for nesting):

YAML key path	Env var override
agent_name	STRANDS__AGENT_NAME
model.provider	STRANDS__MODEL__PROVIDER
model.model_id	STRANDS__MODEL__MODEL_ID

This pays off in four ways:

• No code changes to update model, tools, or prompts
• Environment parity — one config, many environments
• Version controlled — every change tracked in git
• Reviewable by non-engineers — analysts and PMs can adjust behavior

See the Strands Base Agent Configuration guide for the full field list.

Next Steps

• Security & STIG Posture — how baselines are hardened for ATO inheritance
• Choose Your Path — find the right starting point
• Strands Base Agent Quickstart — hands-on tutorial
• Strands Base Agent A2A guide — A2A wire format and walkthrough