Examples

You: Deploy this repository to staging.

Agent: I found a Node app with a Postgres dependency. I can create a staging install,
generate the deployment config, and set up the database connection.

[Form: deployment target, domain, missing environment variables]

Agent: I prepared a repository change request with the package config and install values.

[Approval: Create staging install]

You: I need a cheap worker for Postgres. At least 64 GB RAM, NVMe preferred, under 50 EUR/month.

Agent: I’ll compare current auction servers against that workload.

Agent: Best fit right now:

1. 64 GB RAM, NVMe storage, strong single-thread score, under your budget.
   Good fit for Postgres and small multi-tenant workloads.

2. 128 GB RAM option, slightly more expensive.
   Better if you expect large indexes or want more cache headroom.

I recommend option 1 for the current workload. Want me to add it as a worker
candidate for your cluster, or save it for later review?

[Choice: Add worker candidate] [Save recommendation] [Show details]

You: Why did the customer install fail after the last update?

Agent: I’ll compare the current install, recent change request history, deployment events,
and logs.

Agent: The install started failing after the latest values change removed
DATABASE_URL from the runtime environment. There is already a stale change request that
adds it back and updates the secret reference.

[Card: Existing change request found]
[Choice: Continue change request] [Create new change request] [Only summarize]

Signal: production install failed twice in 10 minutes

Agent: I started a read-only investigation for the failed production install.

Findings:
- The new version is healthy in staging.
- Production fails only in one region.
- The failing pods cannot pull the image from the private registry.

Suggested next step:
Rotate the registry token for the affected workspace and retry the rollout.

[Approval: Create repository change request] [Open install] [Dismiss]