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

​
Goal

Understand when to use Stackie or a specialist and how durable runs, tool evidence, and approval-bound actions work.

​
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
Open Stackie for product questions or cross-domain work, or enter Deploy, Database, Debug, Ops, or WordPress directly.
2
Describe what you want in plain language, including the repo, project, database, or site name.
3
The agent resolves tenant-scoped resources and gathers documentation or live operational evidence through typed tools.
4
Follow the persisted plan, specialist handoffs, tool progress, and artifacts as the durable run advances.
5
Approve an exact action immediately before execution when it is destructive, costly, external, secret-bearing, or production-impacting.

​
The agent fleet

  • Stackie — answers grounded product questions, identifies the objective, coordinates specialists, tracks dependencies, and synthesizes results.
  • Deploy — investigates repositories, build plans, deployment configuration, releases, and rollback options.
  • Debug — investigates logs, build and runtime failures, code, bounded patches, and verification evidence.
  • Database — investigates provisioning, connectivity, pooling, migrations, backups, sizing, and database health.
  • Ops — investigates infrastructure health, incidents, resource pressure, and safe recovery options.
  • WordPress — investigates runtimes, plugins, themes, backups, staging, migrations, and site health.

​
Durable runs and handoffs

Threads, runs, items, events, checkpoints, handoffs, approvals, and tool executions are persisted by StackShift. A reconnect or worker restart resumes from the latest committed checkpoint without repeating an already committed tool action. Stackie can delegate to specialists, and specialists can hand work back to Stackie or request another specialist. The interface exposes those handoffs and reconnectable run events.
  • Read-only inspection and safe reversible preparation can run automatically.
  • Approvals bind the actor, tenant, canonical arguments, target version, action hash, and expiry.
  • Changing the target or arguments invalidates the approval.
  • A successful message is not proof of success; the tool execution or operation must reach a successful terminal state.

​
Product knowledge and live state

Product answers use the release-owned platform corpus and verified Mintlify snapshot. Project, deployment, build, database, incident, and usage answers use tenant-scoped operational tools. Agents must not infer current resource state from documentation.
  • Citations identify whether evidence came from canonical platform docs or Mintlify.
  • Canonical platform documentation wins when the sources overlap.
  • If documentation does not support a product claim, the agent should say so instead of guessing.
Example prompts

​
Build diagnosis and code fixes

Deploy and Debug share build diagnosis and autofix capabilities. They can inspect build history, logs, persisted diagnoses, and deployment context, then prepare bounded patches and verification artifacts in an isolated workspace.
  • The code workspace has no production credentials and network access is denied unless explicitly allowlisted.
  • A pull request requires approval; agents do not automatically merge or deploy it to production.
  • Patch, test, and build evidence is attached to the run.

​
Privacy and provider routing

  • Direct OpenAI Responses is the primary inference route; AgentRouter is the governed fallback.
  • StackShift does not store or expose raw chain-of-thought.
  • Tool results are untrusted input, and secret-bearing fields are redacted from agent-visible results and audit events.
  • Customer and operator experiences share the runtime but never permissions or resource scope.

​
Expected result

You can choose the right entry agent, distinguish documentation from live resource evidence, and understand when an approval is required.

​
Common failures

  • A resource name matches several tenant-scoped candidates — provide a more specific name or ID.
  • A target or argument changes after approval — review the newly generated approval instead of replaying the old one.
  • A provider is unavailable — the run can fall back only between checkpointed steps and never weakens privacy policy to gain capacity.

AI build diagnosis

Failed builds combine deterministic pattern evidence with governed model analysis and can hand bounded repair work to Deploy or Debug.

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

The durable agent fleet is live with explicit evidence, approval, provider, and execution boundaries.