What is an Agent Host?
An Agent Host is a Universal A2A Agent Runtime that:- Hosts AI agents developed with Google ADK
- Configures agent capabilities through YAML files
- Communicates via the A2A protocol over Solace Event Mesh
- Manages sessions, artifacts, and tool execution
- Discovers and delegates to peer agents dynamically
Agent Hosts are configured through the
solace_agent_mesh.agent.sac.app module and use the SamAgentApp class.Architecture
Configuration Structure
Agent hosts are configured through YAML files with the following structure:Key Configuration Sections
Agent Identity
The unique identifier for the agent within the namespace. Used in A2A topic routing.
Human-readable name shown in UI and logs. Defaults to
agent_name.The A2A topic namespace (e.g., “myorg/production”). All components in the same namespace can communicate.
LLM Configuration
LLM model configuration. Typically references a shared model definition:
System instructions that define the agent’s behavior, capabilities, and response style.
Tool Configuration
Agents can access three types of tools:- Built-in Tools
- Custom Python Tools
- MCP Tools
Session Management
Session storage backend:
sql, memory, or custom implementation.Database connection string for SQL-based sessions (PostgreSQL, MySQL, SQLite).
Session behavior:
PERSISTENT (maintain history) or RUN_BASED (clear between runs).Artifact Management
Artifact storage backend:
filesystem, s3, or custom implementation.Base directory for filesystem artifacts.
Artifact visibility:
namespace (shared across namespace), agent (private to agent), or session (private to session).How artifacts are transmitted:
reference (send URI), embed (send base64 content), or inline (send text content).Agent Card (Discovery)
The agent card advertises capabilities to other agents:Skill descriptions are used by other agents (especially orchestrators) to decide when to delegate tasks.
Discovery and Communication
How often to broadcast the agent card. Set to
0 to disable periodic publishing.Whether to discover and communicate with peer agents.
List of agent names this agent can delegate to. Use
["*"] to allow all agents.Maximum time to wait for responses from peer agents.
Example Configurations
Simple Web Agent
View Configuration
View Configuration
Orchestrator Agent
View Configuration
View Configuration
MCP Integration Agent
View Configuration
View Configuration
Running Agent Hosts
Start an agent host using the SAM CLI:Agent Lifecycle
-
Startup
- Load configuration from YAML
- Connect to Solace broker
- Initialize session and artifact services
- Set up ADK runtime with LLM and tools
-
Discovery
- Publish agent card to discovery topic
- Subscribe to peer agent cards (if discovery enabled)
- Inject peer agent information into system instructions
-
Active Processing
- Listen on
{namespace}/a2a/v1/agent/request/{agent_name} - Receive task requests via A2A protocol
- Execute LLM calls with tool access
- Publish status updates and responses
- Listen on
-
Shutdown
- Complete in-flight tasks
- Clean up sessions (if configured)
- Disconnect from broker
Advanced Features
Auto-Summarization
Automatically summarize conversation history to manage context length:OAuth2 Authentication for LLMs
S3 Artifact Storage
Stream Batching
Control streaming response chunk size:Best Practices
Agent Naming
Agent Naming
- Use descriptive, unique names within your namespace
- Follow a consistent naming convention (e.g.,
CamelCase) - Avoid special characters that might conflict with topic routing
Tool Selection
Tool Selection
- Only include tools the agent actually needs
- Use tool groups for common patterns (artifact_management, data_analysis)
- Document custom tools with clear descriptions
Instructions
Instructions
- Be specific about the agent’s role and capabilities
- Include artifact handling guidelines
- Mention when to use status_update embeds
- Describe delegation patterns for orchestrators
Session Management
Session Management
- Use SQL-based sessions for production (persistence across restarts)
- Use memory sessions for development/testing
- Set appropriate default_behavior (PERSISTENT vs RUN_BASED)
Discovery Configuration
Discovery Configuration
- Enable discovery for orchestrators and coordinating agents
- Disable discovery for isolated/specialized agents
- Use allow_list to restrict delegation patterns
Troubleshooting
Agent not receiving tasks
Agent not receiving tasks
Check:
- Namespace matches gateway/client configuration
- Agent name is correctly specified in requests
- Broker connection is established (check logs)
- Queue subscriptions are active
Tool execution failures
Tool execution failures
Check:
- Tool is correctly configured in YAML
- Required environment variables are set
- Custom tool modules are importable
- MCP server is running and accessible
Session data lost
Session data lost
Check:
- session_service.type is “sql” (not “memory”)
- Database file/connection is persistent
- default_behavior is “PERSISTENT” (not “RUN_BASED”)
Artifacts not shared
Artifacts not shared
Next Steps
Built-in Tools
Explore available tools for agents
Creating Agents
Learn to build custom agents
Python Tools
Develop custom tools for agents
MCP Integration
Integrate MCP servers