Worked example: Otto

Repo shape

Otto is the first real agent moving onto the platform contract. Its consolidated repo lives at:

/mnt/disks/data-disk/code/atrium/agent-otto

The staged shape is:

agent-otto/
  atrium.yaml
  frontend/
  backend/
  hasura/

The older live pieces still exist in:

atrium/web/packages/apps/otto
atrium/main/otto-backend
atrium/main/otto-hasura

Manifest

apiVersion: atrium.dev/v1
kind: Agent

metadata:
  name: otto
  displayName: Otto
  description: Resume tailoring and job-application agent
  owner: dev@example.com

services:
  frontend:
    type: nextjs
    path: frontend
    buildCommand: bun run build
    dockerfile: frontend/Dockerfile
    cloudRun:
      minInstances: 0
      maxInstances: 10

  backend:
    type: python-fastapi
    path: backend
    dockerfile: backend/Dockerfile
    cloudRun:
      minInstances: 0
      maxInstances: 5

  database:
    type: hasura
    path: hasura

hosting:
  embedded: false

ci:
  triggerPaths:
    - frontend/**
    - backend/**
    - hasura/**
    - atrium.yaml
  deploy:
    main: production
    deploy/*: staging

What is intentionally absent

Otto's manifest does not contain:

• NEXT_PUBLIC_API_BASE_URL
• database URLs
• ui.version
• status
• resolved
• cloudRun.service
• cloudRun.region

Those values are resolved by the platform.

AgentCase implementation

The existing Otto app exposes:

GET  /api/cases
POST /api/cases
PATCH /api/cases/{id}

lib/agent-case.ts adapts Otto Application and Job records into the generic host-facing shape. The adapter direction is one-way; the Hasura data layer does not import the generic AgentCase type.

Otto also exposes case schema and status actions so the host can show simple case controls without owning Otto's full application workflow.

What is verified

The CLI validator successfully validates agent-otto/atrium.yaml.

Production platform calls now reach the control plane for Otto. Dry-run deploy previews work against the real manifest, but the persisted Otto control-plane manifest is still a placeholder with no services until a confirmed deploy is run deliberately by the Otto owner.

That means atrium status can succeed while atrium env backend returns Service not found. The service data is not persisted yet. Avoid using atrium init --force --directory agent-otto as a registration shortcut; that would register a generated starter manifest instead of Otto's real frontend, backend, and Hasura service manifest.

The current standalone Otto deployment still comes from the old web app path. No CI or Cloud Run service points at agent-otto as the source of deployment yet.