Skip to main content
Create an agent when a project needs AI behavior tied to tools, prompts, or conversations.

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

  1. Define the agent and its purpose.
  2. Attach prompts, tools, and skills.
  3. Connect the agent to conversation flows when it needs chat state.
  4. 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 confirm triage-agent exists. Open the agent source before connecting it to conversation flows.

Agent resources

API reference