Copilot

Conversational installs, diagnostics, and fleet queries — through a closed set of eight typed tools over the same engine as the CLI and UI. The agent proposes; the platform constrains.
Agent surface: inside customer boundary

Session — install tern-aviation / staging

every tool call journaled & attributable to kai.tran
KT
Set up a new staging environment for Tern Aviation on AWS, same shape as their prod but half the capacity.
I'll interview only for what the target actually requires. Collecting the configuration state:
COLLECT_CONFIG read-only
target: aws/staging · known: {profile: tern-aviation-prod, scale: 0.5}
→ resolved: 31 · assumed: 6 · needs confirmation: 2 · missing: 2 · blocked: 1
31resolved from prod profile
6assumed (safe defaults, justified)
2need confirmation
2missing — I must ask
1blocked on an answer

Two questions, then I can plan:

1. Domain for the staging endpoints? (No default ships — this is a hard preflight gate.)
2. Region — prod is us-west-2; keep staging in the same region?

1 blocked: data_plane_cidr depends on your isolation answer — I won't assume it; unanswered dependencies block, they don't silently disappear.

KT
staging.tern.example — and yes, same region. Shared data plane is fine for staging.
All parameters resolved. Checking prerequisites before anything is created:
VALIDATE_PREREQS read-only
→ issues: 1 warning, 0 blocking
⚠ vCPU quota us-west-2 (standard family): 46 of 64 in use; plan needs 12 → 58/64. Proceedable, but the next scale-up will hit the ceiling.
Rendering the workspace and validating the bundle:
GENERATE workspace only
→ workspace_id: ws-tern-stg-01 · artifacts: terraform/, overlays/, lockfile
BUILD_VALIDATE workspace only
→ bundle_ref: cv-bundle-0.1.91-tern-stg · digest: sha256:8c1f…e2a4 · violations: none
PLAN_DEPLOY pure projection
→ plan_id: pl-4te7c2 (hash over workspace + resolved config + bundle digest)
→ 23-task DAG · cost Δ +$1,120/mo · risk: low · rollback: available · downtime: none (new env)
Plan pl-4te7c2 — requires your approval
Creates
VPC, EKS cluster (4 nodes), RDS, registry mirror, 12 Helm releases
Assumed (6)
storage class, backup window, log retention, node OS, CNI, cert issuer — each with the schema's written justification
Integrity
apply refuses if workspace, config, or bundle digest drift after this approval

I cannot mint my own approval token — a human accepts this specific plan, and the token is single-use, expiring, and bound to pl-4te7c2.

KT
Separate question — why did last night's smoke test fail on kestrel-bank prod?
DIAGNOSE local · read-only
env_ref: kestrel-bank/prod · run_id: run-6d90
→ findings: 2 · evidence_refs: journal#412, k8s-events#88, helm-values@rev41

Root cause: search pods OOMKilled during the post-upgrade ingest replay — memory limit still at the pre-upgrade value while 0.1.90's ingest batches are 2× larger. The smoke test's search probe timed out as pods restarted.

Suggested remediation (becomes a plan — I don't hot-patch): raise search.resources.limits.memory 2Gi → 4Gi via the config workflow. Want me to render that plan for approval?

Diagnostics stayed inside your boundary. If support needs the bundle, EXPORT_DIAGNOSTICS is opt-in: redacted by profile, contents previewed, and released only with a confirm token.

The tool surface

closed set · 8 tools
COLLECT_CONFIGread
VALIDATE_PREREQSread
GENERATEworkspace
BUILD_VALIDATEworkspace
PLAN_DEPLOYread
APPLY_PLANapproval
DIAGNOSEread
EXPORT_DIAGNOSTICSapproval

Why this is safe

Approval is bound to the plan. The token is an HMAC over (plan, caller, expiry) — single-use. A bare "yes" never qualifies; a drifted plan fails closed.
The engine is the guardrail, not the schema. Identity, tenancy, audit, and idempotency are enforced by the same engine that serves the CLI and UI.
Runs inside your boundary. The agent surface lives where the CLI lives — the vendor never holds your cloud credentials.
Nothing agent-exclusive. Agent surface ⊆ CLI surface, enforced by an architecture test. Anything Copilot can do, your operators can do without it.