Agent catalog identity
The public agent catalog returns discoverable agents. A catalog item is not runnable by itself. It becomes a runnable project agent when you install it into a project or fork a template project into project source. Use these fields for catalog behavior:
Catalog responses also include a normalized
card for rendering discovery surfaces. Treat the card as metadata only: provider, version, availability, runtime mode, runtime service key, modes, skills, and tools.
Project agent lists return runnable project agents. Use kind: "source_project_agent" or kind: "installed_project_agent" plus can_run for behavior. Project agent lists also include runtime_readiness so clients can show whether an installed runtime-backed agent is ready, offline, unknown, or not applicable.
Runtime readiness does not replace authorization. Installed catalog agents still run through project access grants and run-scoped service-account tokens.
Agent run responses include run_snapshot, a durable projection of the selected project-agent identity, source/catalog provenance, runtime target, and requester.
Steps
- Define the agent and its purpose.
- Attach prompts, tools, and skills.
- Connect the agent to conversation flows when it needs chat state.
- Expose project actions through MCP when assistants need tool access.
Try it with REST
Create a minimal agent:POST /projects/{project_reference}/agents
Terminal
API surfaces
Verify
List agents for the project and confirmtriage-agent exists.
Open the agent source before connecting it to conversation flows.