Before anything is sourced, a platform engineer's ask, or a ticket nothing on the menu serves, is read back as a spec: which component types Archie understood, which phrase produced each one, and any word it could not read. Nothing is imported until a platform engineer confirms it.

Archie names every component the composition holds that the requester’s own sentence does not call for. Quiet over-building is the standing objection to agentic provisioning; this is the answer to it.

Does the composed path actually satisfy the ticket’s acceptance criteria? Met, unmet, or cannot tell — three answers, never two.

One plain-language ask becomes a multi-component path: the request is decomposed, each part sourced, org standards applied per environment, and the components wired from each other's real outputs.

Each component is sourced down a fixed ladder — company catalog first, then your own Terraform repo, then the public registry, and only then generated. The feed records which rung answered each component.

Name a registry module's submodule directly, in Terraform's own syntax — terraform-aws-modules/vpc/aws//modules/vpc-endpoints. An address whose submodule does not exist is refused by name with the real paths listed, rather than importing the root and quietly building the wrong thing.

An EKS ask that needs a VPC and a KMS key comes back as one composed path, not one template. Components deploy in dependency order, each reading the previous one's real outputs.

Nobody is asked for a CIDR. The organisation states its supernet and the per-tier ranges inside it, and each network is allocated its own block so two deployments cannot collide. When the pool runs dry Archie names the stacks holding the space; a network that was never allocated is refused, not guessed at.

Point a component at infrastructure you already run — the shared VPC, the platform KMS key. The deploy skips that apply, reads the real outputs, and marks the component not-owned so teardown never touches it.

Before a path builds a network, key, DNS zone, certificate, secret or cluster, Archie looks in your connected accounts — its own stacks and your latest scans — for one that already exists. One found is proposed; several become a choice; a resource found in your account is referenced read-only, never taken over.

On a path's review page, write what should change in your own words. It becomes the agent's item, Approve waits until the agent saves a new revision, and the page shows which revision addressed it. Only a signed-in person can ask; an agent's key cannot.

The review page opens the path editor directly: Edit path to change values or remove a part, and Remove on every component.

A reviewer who answered No to a path question can switch it to Yes on the review page, and the path moves on.

Six named checks over the resolved plan graph catch valid Terraform that would still fail once it runs — a security group with no egress, an execution role with nothing attached, a load balancer probing a port nothing listens on. Zero cloud calls and nothing created: it reads a dict the preview already parsed. Advisory on a live deploy, because a static rule must never cause an outage; blocking at publish, because nothing is running and that is when trust gets minted.

Archie stands the path up for real in your own non-production account, asserts it works, and tears it down. Only then does it reach the developer menu.

A smoke run invents only names. Every other field takes the module's default or an allowed value, and when there is none the run says which field needs one before it starts. It also refuses to start while the path has blocking items that would fail it, listing each with its owner.

A platform engineer can put a path on the menu without the smoke run — deliberately, with their name on it. A path that would not run at all is refused outright.

Org-level switch for whether a path may publish over components that never passed a verification run. Strict by default once a cloud account is attached.

Publishing snapshots the component versions the path was vetted against, so a later edit to a shared module cannot silently change what a published path deploys.

A path carries a “Use this for” line and a “not for” line in the author's own words — what settles a tie between two paths that both fit, written once instead of asked every time.

Declares which component runs the application and in what form, and which of that component's outputs the artifact ships to. Static files and Lambda zips complete the last hop; a container image is built and pushed but nothing rolls it out. Builds cover Node, Python and static — Go, Java, .NET and Rust are named and refused rather than half-attempted.

Point a request at a repository and Archie reads it. A Python request handler resolves to a function, a Dockerfile to a container; entrypoint, handler and runtime come from the application's own source instead of being asked of a developer who would have to go and look them up.

When a one-off request composed something worth keeping, it becomes a reusable catalog entry instead of a dead end — offered, never done silently.

Developers submit feedback against a published path; the platform engineer reads it as a list.

Export writes runnable Terraform into a connected GitHub repository, one directory per component plus a manifest of deploy order and wiring, mirroring the state layout so a plan does not propose recreating the world. With the state in your own Archie's bucket and the code in your repo, the path runs without Archie. Import brings a real root module back the other way, wired from the author's own module references rather than guessed by name.

The platform as tools at one hosted HTTPS URL — no local install. Compose, govern, deploy, operate, import, audit, from Claude, Cursor, Antigravity or any MCP client, on any model.

One request mints a key and returns paste-ready configuration for Claude Code, Claude Desktop, GitHub Copilot in VS Code, and plain HTTP — complete, not a snippet to adapt. It names which organisation the key acts as, because the MCP URL is identical for every tenant and the key is the only thing that decides.

The tool list itself is filtered on the server by role, so a developer never sees the authoring tools. An unrecognised role falls back to developer, never to platform engineer or owner.

An owner can hold the MCP surface to a lower role to see exactly what a developer is handed.

See yes, change no. A developer can read the org rules, a module's inputs and code, the smoke-test result behind a path, and the review explaining why their own request was held. Every one of them only reads — nothing a developer can change moved.

A developer describes a need; Archie matches the menu first and orders off it. Whether it deploys or stops for approval is the org's zero-touch setting — the same policy a ticket or the UI runs under.

Asking for PostgreSQL brings back what is closest and how it differs, rather than a MySQL path presented as a match, and "add a database to my app" extends the running app. Most wordings land; unusual phrasings are still being hardened against a phrasing benchmark.

A failed deploy says what failed, whose fix it is, what is running and what never started, and a next step the reader's role can take.

A step only a platform engineer can take lands on their Waiting on you list, and the developer sees it waiting.

Amend, withdraw, and poll a provisioning request; read any feed item in full detail.

The requester taking it back and the platform engineer saying no are recorded as two different acts, because they mean different things later.

whoami returns who the agent is acting as and at which tier, so a session can never quietly assume more than it holds.

A denied tool is a governance boundary, not a 500 — the refusal says which role the tool needs, and the tool was never offered to that session in the first place.

Browse your organisation's published golden paths with filters

View resources, config fields, cost estimate, deploy CTA

Configure, preview, and apply with live WebSocket logs

Auto-generated forms from the module schema with grouped fields

Pre-deploy validation — 27 rules: AWS 10, Azure 7, GCP 5, Kubernetes 5. Critical findings block; a PE or owner may override, a developer may not.

Org-level limits on resources, regions, types, and cost

Cost estimation vs monthly budget, auto-block at limit — evaluated before approval, with an audit entry

Two things can hold a deploy, and either is enough: where the code came from, and what it can reach. A path published from your own catalog carries its trust and is not re-gated on provenance; anything unvetted is reviewed first. Independently, any deploy into a prod-tier account is held regardless of source.

Saved Cloud Accounts with tier badges (Dev/Staging/Prod) + manual override option. KMS-encrypted, shared with team.

When more than one cloud account matches, Archie refuses to guess and names the candidates — the account is the blast radius

Estimated monthly cost visible in the config selector + preview step before confirming. Recalculates when switching Non-prod / Prod profile. AWS only — other clouds report the estimate as unavailable rather than showing $0.

On AccessDenied during preview, shows failing IAM actions as pill badges + copyable inline-policy JSON + Retry button

Real-time streaming via WebSocket during deploy

Anything fronting traffic carries a serving badge separate from its deploy status, and says when that answer was last checked — “serving” is a present-tense claim about a moment that can be days old. Load balancers and CDNs warm up, so Archie retries inside a window before calling it.

Animated resource cards with creating/created transitions grouped by service

Minimize modal while deploying — floating status bar shows progress, click to restore

Deploy into existing VPC/VNet. Auto-detect existing infrastructure, skip network creation

Red banner + checkbox confirm for deletions and replacements

A deploy refused partway removes the account binding it wrote. A binding to an account that was removed is skipped, and production waits for a person.

Show +create ~update -delete counts before applying

Cloud keys live in Archie and are resolved server-side. The developer deploys under their own name and never holds one.

Failed and cancelled deploys auto-clean state — stack name reusable immediately

Schedule a deployment for a future maintenance window. The API is live and permission-gated; there is no UI or agent tool for it yet.

Put one field on rails for the whole organisation, per environment — every module declaring it is surfaced and locked to those values on the next import or resync. A list is a choice, not a mistake.

A path written with production sizes still deploys in dev: a size the platform engineer did not lock takes the environment's approved default, and the deploy says what it swapped. Locked values, profile values and anything a developer chose are never rewritten. The review shows what each environment will run before publish.

A path value its pinned module does not declare — volume_size where the module says size — is refused at save with the rename to make, held at publish and refused at deploy: one rule at every door.

Readiness never asks the agent to set what your org rules refuse. Multi-zone in dev, when your rule only gives it to prod, shows as answered by the rule. Readiness refreshes itself when Archie or your rules change.

Every org rule shows what it actually reaches in your catalog, and before saving you can preview the impact — which fields move, which become governed, which stop being, and which components need a new version. It writes nothing. Saving never reaches back into what is already running.

An org-standards apply is a recorded run — listable, and revertible — rather than an untracked sweep across the catalog.

Governance keys off what a module creates — encryption is enforced because the resource stores data, not because someone remembered to tick a box

Which of your two VPC modules is the one. Nominate it once and stale choices are flagged rather than quietly followed.

Read the organisation's standing rules — mandatory tags, retention, regions — as one surface

Before saving a rule, preview which fields it moves and which components it reaches. Saving never reaches back into what's already running.

Every refusal is recorded with who, which role and why. The third identical one files a card for the platform team, and later ones raise its count: agents keep asking for this, so widen the rule or explain it.

Every new organisation starts with a default set — encryption, mandatory tags, retention, never-public — that a platform engineer edits rather than invents. The first composition has something to govern it.

An agent proposes a policy change; a human decides it

Lock config fields globally or per-environment, enforced server-side

Critical violations block deploy — PE/Owner can override

Prevent deploy if stack has unresolved drift

Accept drift with category, reason, and expiry date

Draft → In Review → Approved → Published workflow

Non-prod / Production toggle in the editor — different defaults, locked fields, required fields, and values per profile. The deploy form auto-loads the matching profile.

Each Cloud Account gets a tier (Dev/Staging/Prod) with color-coded badges. Deploying, upgrading, or destroying against a Prod-tier account automatically requires approval.

An approver sees the full picture — path, config, cost, compliance, and which rung of the sourcing ladder produced each component — then approves with a comment

Outside code is held with its upstream module, the pinned version, what it creates, your existing locks, whether any plan ever passed, and the HCL itself. A name and two buttons is the failure this exists to prevent.

A platform engineer writes “the DNS zone lives in account X” once, and the agent reads it as fact before planning rather than rediscovering or guessing it.

Catalog cards show a Non-prod / Production toggle — switching updates the locked / required / editable fields and values visible on the card

Pull a module from the public Terraform registry into your own catalog, where it is governed like anything else you own

Point Archie at your existing repo and the sourcing ladder reaches your own modules before the public registry

A module is verified by a real run, and the publish gate can refuse paths built over unverified components

Read what a module declares — the inputs, their types, and which the org has already governed

Re-pull a module's source and re-apply the org's vetted sizes over it

Copy any module in your catalog into a governed variant of your own, with its locks and profiles carried over

Modify config, lock fields, update version

Make an approved module available to paths and developers

Semantic versioning with snapshots for rollback

Remove unpublished company modules and paths

Golden paths are the storefront, modules are the stockroom. A developer sees the menu; a platform engineer sees both, with modules collapsed once at least one path exists. Modules are badged with the paths built on them, so you can see what depends on one before you change it.

Edit on a card opens Governance (variables, locks, profiles) or Code (Pulumi/Terraform source) — two clear entry points

Generate a Pulumi or Terraform module from a natural-language prompt

Your Terraform executes natively — no conversion, no wrapper, one engine. A registry module is governed on import rather than translated first, and state lives in your own S3 bucket with locking.

Edit module code with AI in a chat-style UI. After each edit, a summary panel shows what changed — new resources, modified resources, new config fields.

Write and edit module code with syntax highlighting

Read the source of any module in your catalog, whichever rung of the ladder it came from

Paste Terraform code and convert it into the Archie framework

Import from GitHub, Azure DevOps, or GitLab repos. Browse the file tree, select a path.

Review generated code for compliance and best practices

A multi-component deploy is one app — described, advanced, upgraded, rolled back, remediated, and destroyed as a unit rather than as loose stacks

Bind an app to an environment and resolve which cloud account and standards apply

A read replica beside a live database, a cache in front of a running service. New components are planned against the whole app so their wiring binds to what is already up, then deployed in order while everything settled is skipped. Nothing running is touched.

Each stack shows who owns its state — Archie-managed, or governed in place with your existing state still the source of truth. The foundation for bring-your-own-infrastructure: hand a stack over when you are ready, with no migration.

Abandon an app’s record in one call instead of stack by stack. Owner-only, because force-remove leaves the real resources running and still billing — a different act from destroying them.

Clearing the record for a dead account requires the account to actually be dead. Archie checks before it lets you abandon something it can still reach.

Publish v1.1 and every stack still on v1.0 shows outdated — listed as a set, not hunted for

Propose governed upgrades for every outdated stack at once — one approval row per stack. Upgrades never auto-run; prod is always gated. Idempotent and capped.

One read of what the organisation is running, across accounts and clouds

What stands on what — derived from published outputs against consumed config, not declared by hand — across apps and cloud accounts. Flags a stack still pointing at a destroyed stack’s resource.

A one-line module error costs a redeploy of that component, not a teardown of the whole app.

Read-only sweep for infrastructure Archie built and lost track of — a SIGKILLed apply, a failed teardown. Only resources carrying Archie's own tags are ever candidates.

Acknowledge an orphaned workload or remove it once a human has decided

Each client is its own organisation with its own rules, approvals and sizes, set when it is created. Your platform engineers reach in with platform-engineer rights, marked on the client's audit trail.

Build and publish offerings once in your MSP organisation, and see which clients hold each one and whether their copy is current.

Send a published path or module to chosen clients. It arrives as a read-only copy, bringing its modules with it, and the client's people deploy it under the client's own rules.

Push a master's newer version to clients that hold a copy. Their running apps then show as behind, and upgrading them is the client's own governed deploy.

Move every client app onto a new version wave by wave: a canary, then one client per wave. Nonprod waves advance after a soak, a production wave waits for a signed-in platform engineer's go, and the rollout stops at the first failure with that app's rollback offered. It is refused unless a passed upgrade smoke test covers the versions the clients run.

Deploy an offering into a client yourself, recorded as managed by the MSP, under the client's rules.

One read across every client: apps, drift, versions behind the master, outdated copies and what waits on a person, with links.

Connect a Jira project and Archie picks up tickets, reads the ask in your own words, decomposes it and provisions through the same governed loop every other door uses. The ticket is the interface: an ambiguous request is asked about in a comment and resumes when answered, and every governed deploy and destroy files a receipt back. Built and wired; end-to-end runs on live tickets are still being proven.

Set your Terraform or Pulumi repo once. Archie reads it through the provider's API — GitHub, GitLab or Azure DevOps, no clone — and reuses what you already wrote before reaching for anything public. If more than one directory could be the answer, it declines to choose and says so.

An opt-in toggle on the IaC Repository card: every governed action writes itself back to your repository as a file and a commit, so the record lives where your engineers already look.

Click remediate in the channel — HMAC-verified, tenant cross-checked, idempotent, and the message is replaced in place rather than answered with a second one.

A push rematches stacks by repo and branch and rebuilds only the application. The infrastructure underneath is left untouched.

Show when a stack is behind its path's latest version

Side-by-side resource changes between versions

Upgrade with outputs re-injection — no resource replacement

Revert a stack or a whole app to any previous deployment version

Editing, resyncing, applying a standard or rolling back a deployed module keeps the version it leaves behind. Pins and upgrades from older versions keep working.

Quick rollback card on the stack Actions tab — one click to previous version

Upgrade, rollback, drift, and destroy modals pre-select the Cloud Account used at deploy time

List all deployments with status, timestamp, deployer

Store config and outputs at each deployment for rollback

Scan cloud infrastructure for deviations from code

An empty result reports what was read separately from what was found — a throttle, a missing permission and a genuinely clean account all produce an empty list, and Archie will not let them look alike.

Manual check with cloud-specific credential picker

An EventBridge rule can run drift detection across every stack with a saved Cloud Account. Defined in the stack, but currently switched off in the live environment as a cost decision — on-demand drift checks are unaffected.

Timeline of detections, acknowledgments, resolutions

Show current vs desired state per drifted resource

Archie fixes drift on its own only where an org has it switched on, and only when criticality is low, severity is low and the environment is not production. Everything else — a security-group change included — is reported and escalated, never quietly reverted.

Re-deploy the governed code to correct drift, with live progress — per stack or across a whole app

Classify drift into critical/high/medium per org policy — what matters is fixed first, not whatever is noisiest

Full support — deploy, drift, remediate, destroy, with computed cost estimates

Deploy, governance, compliance, brownfield, destroy

Deploy, governance, destroy

Enroll a cluster with namespace-scoped permissions, deploy workloads to it, and redeploy a workload to another cluster. No in-cluster discovery, and native Kubernetes drift is not enabled — a check says so rather than reporting in-sync.

Filter catalog and stacks by cloud provider

Cloud-specific region dropdown in credential picker

OAuth setup, channel selection, test connection

deploy.started, deploy.success, deploy.failed

destroy.started, destroy.success, destroy.failed

drift.detected, drift.remediated

Held for approval, approved, refused — with the reason

drift.acknowledged with category and reason

Custom webhook URLs for infrastructure events

Invite team members and assign roles — viewer, developer, platform engineer, owner

Org name, plan, member limits

One org-level answer decides whether a matched request deploys or stops for approval — the same policy across MCP, a Jira ticket, and the UI

Create/revoke keys with scopes for CI/CD integration

View and revoke active sessions across devices

Monthly usage tracking (deploys, AI, stacks)

Download stacks, deployments, audit as JSON/CSV

Test any Cloud Account → account ID, role ARN, attached and inline policies, action-prefix summary. Surfaces the actual cloud error if creds are bad.

Viewer, developer, platform engineer, owner — enforced on the REST door and the MCP door alike, not in the client

Cloud keys live in Archie, KMS-encrypted and resolved server-side. The developer deploys under their own name and never holds one.

A pre-commit AST scanner fails the commit when a sensitive field reaches a write without a sanitiser — the rule is enforced by the build, not by review

A cluster is enrolled with namespace-scoped Edit, never cluster-admin — with a copy-paste CLI fallback for when Archie’s own role cannot do it

Imported outside code cannot read Archie’s own secrets

Who did what and when — including the refusals, which are the entries that matter under scrutiny

Six tiles open straight to what needs you: golden paths, running, waiting for approval, behind the path, drifting and failed, coloured only when there is something to see. Two trends show deploys per week and how many go through a golden path; with too little history, it says so instead of drawing a line. An MSP also sees its clients.

A read-only inventory of a connected account, doing two jobs: orientation on day one, when your Archie is still empty, and the ongoing proof that it is working.

One card per app — health, drift, cost, compliance and owner at a glance. A client-side rollup of the stack list rather than its own backend surface.

Every request as it moves — what was asked, what Archie composed, which rung sourced each component, and why anything was held

Tag stacks with an app group — VPC + DB + Compute layers grouped together

Status badges — healthy, degraded, failed, deploying, destroyed

Stack detail shows AWS Account ID, Azure Subscription, or GCP Project

Monthly costs by stack, cloud, environment, team

Priced from the deploy's actual resource manifest and your chosen config, with a per-kind breakdown — not a flat author-provided string. AWS only; other clouds report the estimate as unavailable.

Monthly budget, thresholds, auto-block

Active/destroyed stacks per env, build hash sync

Discover and classify what is already running in a connected account

Bring what is already running under governance, so a reused component points at a stack Archie manages

Read an existing Terraform state from your bucket — what it manages, by type and address. Read-only: nothing is adopted or changed

Adopt a multi-resource Terraform deployment as one governed app

Configure and read the repo Archie imports your own modules from

Enumerate an Azure subscription through Resource Graph and a GCP project through Cloud Asset Inventory — one call each, with the properties the risk rules read