/microsoft-foundry

Declarative Routines

The routines extension registers a service target so routines can live in source control and be upserted by azd up / azd deploy. Declare each routine as a service with host: azure.ai.routine: the service key is the routine name, and the keys under it bind directly to the routine model.

# azure.yaml
services:
  my-agent:
    host: azure.ai.agent
    # ... agent service block ...

  daily-digest:                 # service key = routine name
    host: azure.ai.routine
    uses:
      - my-agent                # order the agent ahead of the routine that invokes it
    description: Daily 8am digest
    enabled: true
    triggers:
      default:
        type: schedule          # recurring cron; see type table below
        cron_expression: "0 8 * * *"
        time_zone: America/New_York
    action:
      type: invoke_agent_responses_api   # see type table below
      agent_name: my-agent      # target agent (distinct from the routine name)
      input: "Summarize activity for ${AZURE_ENV_NAME}"

Then:

azd deploy daily-digest --no-prompt
azd up

Trigger and action type values

azure.yaml (like a --file manifest) uses the raw wire type: value, not the CLI alias:

• Trigger type: schedule (recurring cron), timer (one-shot), github_issue, or custom.
• Action type: invoke_agent_responses_api (resume with conversation) or invoke_agent_invocations_api (resume with session_id).

The azd ai routine CLI accepts friendlier aliases (recurring, github-issue, agent-response, agent-invoke) for the same values. See the full alias-to-wire mapping and per-trigger key fields in CLI CRUD and Operations.

action.input

Put the prompt or payload sent to the agent in action.input:

• invoke_agent_responses_api (agent-response): a string prompt.
• invoke_agent_invocations_api (agent-invoke): an object/array/scalar matching the target agent's expected input.

Behavior notes

• azd deploy PUTs the routine idempotently; package and publish are no-ops (a routine has no build artifact).
• The routine name always comes from the service key; any name: inside the block is ignored.
• Put the target agent service in uses: so azd orders the agent before the routine that invokes it.
• String values resolve ${VAR} against the active azd env at deploy time; Foundry server-side ${{...}} expressions are left untouched.
• Removing the service block stops azd managing the routine but does not delete it from Foundry. Delete explicitly with azd ai routine delete <name>.