1. Read the platform constitution. Check for

   Platform-Engineering-Constitution.md

   in the repository root. Note approved cloud providers, compute platforms, and IaC tooling.
2. Check current Radius state. Run

   rad workspace show

   ,

   rad environment list

   ,

   rad recipe list

   , and

   rad resource-type list

   .
3. If asked to create an application definition, inspect the workspace first. Look for environment definitions, existing shared resources, container artifacts, and application code that implies required connections.
4. Prompt only for missing values. Ask for OCI registry details, boolean choices without a safe default, and long free-text inputs such as AI prompts.
5. Author or update the application Bicep, resource types, and/or environment configuration as needed.
6. Validate against the constitution and test with

   rad run

   .

1. Inspect environment-definition files first. Treat files such as

   env.bicep

   ,

   environment.bicep

   ,

   shared-resources.bicep

   , and similar workspace Bicep files as the primary source of truth for shared resources and environment names.
2. Model shared resources from workspace files as

   existing

   in

   app.bicep

   . If PostgreSQL, blob storage, or other shared resources are declared in files like

   env.bicep

   or

   shared-resources.bicep

   , reference them with

   existing

   in the generated app definition even if they might not be deployed yet.
3. Inspect the repository for container artifacts. Look for

   Dockerfile

   ,

   Containerfile

   , OCI build configs, or application folders that clearly map to a container workload.
4. Choose the container resource type deliberately. Use

   Applications.Core/containers

   for straightforward single-container application workloads unless the repository explicitly needs recipe-based container features from

   Radius.Compute/containers

   .
5. Infer container ports from workload files, not base-image defaults. Prefer explicit signals such as

   EXPOSE

   in

   Dockerfile

   ,

   listen

   directives in

   nginx.conf

   , or app server startup arguments over assumptions like nginx using port 80.
6. Inspect the code for required connections. Search for connection names, SDK usage, or environment variables that imply dependencies such as PostgreSQL, blob storage, or AI agent endpoints.
7. Inspect for AI-agent expectations. If the code expects an agent endpoint or agent-style integration, add a

   Radius.AI/agents

   resource.
8. Wire connections by responsibility. Connect the AI agent to the data and knowledge resources it needs. Connect the application container only to the AI agent unless the code clearly shows the container itself must talk to other resources directly.

1. OCI registry host for the container image.
2. Enable observability? Ask explicitly for

   Radius.AI/agents.enableObservability

   because it is boolean and should not be guessed.
3. Prompt value for the AI agent.

• Always create

  app.bicep

  when it does not already exist.
• Always ensure

  bicepconfig.json

  includes the needed Radius extensions for every resource type used in the generated app.
• Use

  existing

  resources for shared infrastructure already defined by the environment, especially PostgreSQL and blob storage when those are pre-provisioned.
• Treat workspace Bicep files as authoritative for shared resources even when those resources are not deployed yet.
• Add a container resource when the repository clearly contains a deployable application container.
• Prefer

  Applications.Core/containers

  for simple frontend or service containers and only switch to

  Radius.Compute/containers

  when the repo clearly depends on recipe-based container behavior.
• Do not connect the frontend container directly to shared data resources when an AI agent resource already encapsulates those integrations.
• Infer the image repository name from the workload folder or existing repo conventions. If the repo contains

  src/web/Dockerfile

  , default the image repository to

  frontend-ui

  rather than a generic repository name.
• Infer the container port from explicit workload configuration. Prefer

  EXPOSE

  , web-server config, or application startup args over generic defaults from the base image.
• Prompt for the OCI registry instead of hardcoding one.
• Prompt for AI observability instead of assuming

  true

  or

  false

  .
• If the AI prompt is long or multi-line, do not inline it in the resource. Model it as

  param agentPrompt string

  and set

  prompt: agentPrompt

  .
• If the AI prompt is short and single-line, it may be inlined unless the user prefers parameterization.
• Prefer minimal app scaffolds that connect to existing shared resources rather than duplicating them.

app.bicep

• An application resource.
• Existing shared resources such as PostgreSQL and blob storage, when discovered from the environment definition.
• A new application container resource, usually

  Applications.Core/containers

  for simple app workloads.
• A new

  Radius.AI/agents

  resource when the code expects an AI agent.
• Connections from the AI agent to PostgreSQL and blob storage when those resources are required.
• A connection from the application container to the AI agent when the container is only a frontend or thin client.
• Parameters for registry details and long free-text values.

Reshrahim/customer-agent

• Environment file:

  radius/env.bicep

  defines the environment and registered recipes.
• Shared resources file:

  radius/shared-resources.bicep

  defines PostgreSQL and blob storage that should be referenced with

  existing

  in the generated

  radius/app.bicep

  .
• Frontend container:

  src/web/Dockerfile

  indicates a user-facing container workload; generate an

  Applications.Core/containers

  resource such as

  frontend-ui

  for it.
• Agent runtime code:

  src/agent-runtime/app.py

  indicates the repo expects an AI agent plus PostgreSQL and blob storage connections.
• Agent connections: the generated

  Radius.AI/agents

  resource must connect to

  contoso-db

  and

  contoso-knowledge-base

  so the runtime receives both database and knowledge-base/search inputs through the recipe.
• Frontend connections: the generated

  frontend-ui

  container should connect only to the AI agent.
• Frontend image name: the generated container image should use

  frontend-ui

  as the repository name unless the user overrides it.
• Frontend port: infer the frontend port from

  src/web/Dockerfile

  and related config files. For customer-agent, use

  3000

  because the Dockerfile exposes

  3000

  and

  src/web/nginx.conf

  listens on

  3000

  .
• Do not create a second app-level container for

  src/agent-runtime/Dockerfile

  when the

  Radius.AI/agents

  recipe already encapsulates the agent runtime container.
• Default model: use

  gpt-4.1-mini

  unless the user asks otherwise.
• Prompt handling: when the user pastes a long or multi-line system prompt, always model it as a

  param

  rather than inlining it.

Radius.Compute/containers

Radius.Compute/containers

Radius.Compute/persistentVolumes

Radius.Compute/routes

Radius.Data/mySqlDatabases

Radius.Data/postgreSqlDatabases

Radius.Storage/blobStorages

Radius.Security/secrets

Radius.AI/agents

Radius.Data/redisCaches

radius-resource-types

Critical difference:

Applications.Core/containers

is directly managed by Radius.

Radius.Compute/containers

is recipe-based — it needs a registered recipe to deploy.

extension radius
extension radiusCompute
extension radiusData

param environment string
param application string

resource frontend 'Radius.Compute/containers@2025-08-01-preview' = {
  name: 'frontend'
  properties: {
    environment: environment
    application: application
    containers: {                   // plural "containers" — a map!
      frontend: {
        image: 'myregistry/frontend:latest'
        ports: {
          web: { containerPort: 3000 }
        }
      }
    }
    connections: {
      database: { source: db.id }
    }
  }
}

resource db 'Radius.Data/postgreSqlDatabases@2025-08-01-preview' = {
  name: 'database'
  properties: {
    environment: environment
    application: application
    size: 'S'                       // Required if recipe expects it
  }
}

Schema difference:

Applications.Core/containers

uses

container

(singular object).

Radius.Compute/containers

uses

containers

(plural map where each key is a container name).

• Cloud registry (ACR, ECR, GHCR): Works if cluster has credentials configured
• Local dev with kind: Push to a local OCI registry and use

  host.docker.internal:<port>

  as the image host

• imagePullPolicy

  : The

  Radius.Compute/containers

  recipe may set

  Always

  — images must be pullable, not just loaded with

  kind load

Critical: Recipes registered from local file paths (

/tmp/recipe.bicep

) will NOT work. The Radius control plane runs inside Kubernetes and cannot access the host filesystem. Always publish to an OCI registry.

undefined

namespace: Radius.Data
types:
  postgreSqlDatabases:
    description: |
      A portable PostgreSQL database resource.
    apiVersions:
      '2025-08-01-preview':
        schema:
          type: object
          properties:
            environment:
              type: string
              description: "(Required) The Radius Environment ID."
            application:
              type: string
              description: "(Optional) The Radius Application ID."
            size:
              type: string
              enum: ['S', 'M', 'L']
              description: "(Optional) The size of the database."
            host:
              type: string
              description: The hostname.
              readOnly: true
            port:
              type: string
              description: The port.
              readOnly: true
            database:
              type: string
              description: The database name.
              readOnly: true
            username:
              type: string
              description: The username.
              readOnly: true
            password:
              type: string
              description: The password.
              readOnly: true
          required: [environment]

• environment

  is always required
• Input properties are cloud-agnostic, minimal
• Output properties are marked

  readOnly: true

  — they become connection env vars
• Combine multiple types in one YAML under the same namespace

context.resource.id            // Full resource ID
context.resource.name          // Resource name
context.resource.type          // e.g., "Radius.Data/postgreSqlDatabases"
context.resource.properties    // Developer-set properties from app.bicep
context.runtime.kubernetes.namespace  // Target namespace

Important: Use

context.resource.properties.*

(not

context.properties.*

).

• Always check the platform constitution before suggesting resource types, recipes, or cloud-specific patterns.
• Use portable resource types (

  Radius.*

  ) instead of cloud-specific resources unless explicitly needed.
• Never hardcode infrastructure details in application definitions — let recipes handle it.
• Always include

  environment

  — required for all Radius resources.
• Handle both connection env var formats (

  _PROPERTIES

  JSON and individual vars) for portability.
• Set all recipe-expected properties in Bicep (e.g.,

  size

  ), or use safe defaults in recipes.
• Always configure

  bicepconfig.json

  — the Radius Bicep extension won't resolve without it.
• When scaffolding

  app.bicep

  , inspect before asking. Infer shared resources and container workloads from the workspace whenever possible.
• When shared resources already exist in the environment, declare them with

  existing

  instead of provisioning duplicates.
• When shared resources are declared in workspace files such as

  env.bicep

  or

  shared-resources.bicep

  , declare them with

  existing

  in the generated

  app.bicep

  instead of duplicating them there.
• Always ask for the OCI registry host when it cannot be inferred from the repository.
• Always ask before setting boolean AI options such as

  enableObservability

  when there is no clear project default.
• Move long or multi-line prompt text into a parameter instead of embedding it directly in the AI agent resource.
• When an app uses an AI agent plus shared data resources, prefer agent-to-resource connections over container-to-resource connections.
• Never register recipes from local file paths — publish to an OCI registry first.
• Use

  host.docker.internal

  instead of

  localhost

  for in-cluster access to host services.
• Use

  --plain-http

  when working with insecure (HTTP) registries.
• Generate Bicep extensions after registering resource types for IDE validation.
• Keep resource type interfaces cloud-agnostic — cloud details belong in recipes, not schemas.
• Always handle missing optional properties in recipes with safe defaults.
• Use

  containers

  (plural map) for

  Radius.Compute

  and

  container

  (singular) for

  Applications.Core

  .
• Test with

  rad run

  before deploying to production.