Skip to main content
Live. This area is documented as current, user-reliable behavior.

​
Goal

Understand what each StackShift AI agent can do and how the propose-then-confirm model keeps you in control.

​
Prerequisites

  • A StackShift account
  • Something for an agent to act on: a connected GitHub account, a project, a database, an open incident, or a WordPress site

​
Workflow

1
Pick the agent that matches your task: deploy, database, debug, ops, or WordPress.
2
Describe what you want in plain language, including the repo, project, database, or site name.
3
The agent resolves the target and pulls the relevant context (project status, build logs, database state, open incidents).
4
If a change is involved, the agent returns a confirmable action card with a title, reason, and risk level instead of acting immediately.
5
Confirm the card to execute, or keep talking to refine it. Read-only questions are answered without a card.

​
The agent fleet

  • Deploy agent — create a project from a GitHub repo, redeploy, rebuild, roll back a deployment, or open a code-fix pull request.
  • Debug agent — analyze a failed build, explain the root cause, and propose a fix as a code-fix PR or a redeploy/rebuild.
  • Database agent — report database status and context, and propose restart or upgrade actions.
  • Ops agent — pull your open operations incidents and help you triage and remediate them.
  • WordPress agent — create sites (including multisite), import, back up and restore, update core, activate themes, and run maintenance tasks.

​
How agents act: propose, then confirm

Agents do not change your infrastructure on their own. When an agent decides an action is warranted, it calls a propose tool that returns an action card. The card states what will happen, why the agent chose it, and a risk level so you can judge it before confirming. For project creation you can ask the deploy agent to run autonomously (for example, “deploy this all the way without asking”), and it will carry the plan through after the initial confirmation. Everything else stays one confirmation per action.
  • Action cards carry a risk level (low, medium, high) — for example restoring a backup or updating WordPress core is high risk.
  • Agents never modify environment files, secrets, GitHub workflow files, or credentials.
  • If a request is ambiguous (for example a repo name that matches several repositories), the agent shows candidates instead of guessing.

​
Deploy agent

The deploy agent turns a natural-language request into a deployment. It can resolve a GitHub repo from a URL or a name in your connected account, infer the runtime and branch from your message, and detect whether you want a managed database alongside it.
  • Create a new project from a GitHub repository.
  • Redeploy or rebuild an existing project.
  • Roll back to a previous deployment.
  • Open a code-fix pull request when a defect is the cause.
Example prompts
Deploy github.com/acme/store on the main branch with postgres
Redeploy my storefront project
Roll back the last deployment of api-gateway

​
Debug agent

The debug agent loads your latest (or a specific) failed build with its log tail, explains the root cause, and then proposes a concrete remediation. When the evidence points to a code defect it can author a code-fix PR with full file replacements on a branch it generates; when the failure is transient or stale it proposes a redeploy or rebuild instead.
  • Reads the failing build and trimmed, redacted logs.
  • Proposes a code-fix PR with concrete file changes, or a redeploy/rebuild.
  • Will not patch env files, secrets, workflow files, or credentials — if the safe fix is unclear it tells you what is missing instead of guessing.

​
Database, Ops, and WordPress agents

  • Database agent: pulls database status and context and proposes restart or upgrade actions you confirm.
  • Ops agent: pulls your open operations incidents so you can triage and remediate them in context.
  • WordPress agent: create a site (single or multisite, subdomain or subdirectory), import an existing site, create and restore backups, update core, activate a theme, and run maintenance (reset admin password, update site URL, flush permalinks, toggle maintenance mode, database upgrade, cache flush).

​
Expected result

You know which agent to reach for, and you understand that nothing is created, changed, or deleted until you confirm an action card.

​
Common failures

  • GitHub is not linked or the StackShift GitHub App is not installed for the repo owner — the deploy agent cannot resolve the repository until you connect it.
  • A repo or resource name matches several candidates — the agent asks you to choose instead of acting.
  • Asking an agent to change secrets, env files, or workflow files — these are intentionally off-limits.

AI build diagnosis

Automatic root-cause analysis for failed builds: a known-pattern matcher backed by Claude LLM analysis produces a categorized diagnosis with confidence and concrete fix steps.

Deploy from GitHub

Use the repository-backed project flow when you want StackShift to detect the app, build from source, and let you override runtime behavior before the first deploy.

Project troubleshooting

Common project-side failure modes, especially when the app built successfully but does not come up healthy.

Current status and limitations

Exactly what the AI agents and diagnosis can and cannot do today, and the guardrails that constrain them.