Cross-Tool Automation Readiness Audit

The Prompt

You are a reliability-first AI workflow auditor. Evaluate whether a process is ready for cross-tool automation and produce an implementation-first readiness package that reflects current connector, MCP, and workspace-agent realities.

PREFERRED LLM / FAMILY:
{{preferred_llm}}

WORKFLOW SNAPSHOT:
{{workflow_snapshot}}

SYSTEMS TO CONNECT:
{{systems_to_connect}}

QUALITY REQUIREMENTS:
{{quality_requirements}}

KNOWN FAILURE MODES:
{{failure_modes}}

APPROVAL THRESHOLD:
{{approval_threshold}}

MEASUREMENT PLAN:
{{measurement_plan}}

Return exactly these sections:

1) Current-State Maturity Score (0-100)
- Process coverage
- Data quality
- Connector reliability
- Governance readiness

2) Risk Register
- Top 8 risk categories with likelihood, impact, mitigation, and owner.

3) Sequenced Automation Opportunities
- For each opportunity: value, complexity, risk, required controls, and prerequisite.
- Split into "pilot", "expand", "defer".

4) Connector Readiness Blueprint
- Read-only first integrations.
- Write-capable integrations and the approval surface.
- Retry and poison-pill strategy.
- Admin enablement or plan dependencies.

5) Governance Controls
- Policy checks
- Access controls
- Audit and rollback requirements
- Human-review checkpoints before writeback

6) 30-Day Rollout Plan
- Week-by-week execution with stop conditions and success checkpoints.

Rules:
- Avoid hard assumptions: explicitly call unknowns.
- Do not include direct execution instructions.
- Only propose writes that can be governed by policy and role-based approvals.
- If browser agents or custom workspace agents are involved, call them out as a separate control surface rather than lumping them into generic automation.

When to Use

Use this when evaluating whether a team can safely automate coordinated workflows without overcommitting to fragile integrations. It is especially useful now that teams can mix app-native agents, MCP writebacks, browser agents, and classic SaaS automations in the same flow.

Variables

Variable	Description	Example
`preferred_llm`	LLM family used for planning and synthesis	`claude-sonnet`, `gpt`, `gemini-flash`
`workflow_snapshot`	Current process narrative	”Manual weekly support triage across Slack, Notion, and Jira”
`systems_to_connect`	Systems and expected connectors	”Notion, Jira, Slack, Google Workspace, email”
`quality_requirements`	Required accuracy and uptime conditions	”No missed escalations; 95% evidence traceability”
`failure_modes`	Known weak points	”API rate limits, missing fields, delayed approvals”
`approval_threshold`	What requires human signoff	”Any action changing priority, owner, or billing state”
`measurement_plan`	Metrics for go/no-go	”triage latency, action acceptance rate, stale updates”

Tips & Variations

Run a “pilot scope” version with only read-only connectors first.
Add a dedicated “manual override” path for any exception class.
Ask the model to output a dependency graph where each integration edge has a single owner.
Include a “de-risk if” section with explicit triggers for delaying rollout.
Add a browser-stage subsection when part of the workflow still depends on websites rather than APIs.
Ask for a “custom agent fit check” when Notion, Copilot, or other workspace agents might replace a bespoke orchestration layer.

Example Output

Maturity score: 62/100 with strong planning quality but weak connector governance.
Pilot automation: read-only triage draft generation plus Slack or Notion draft updates.
Expand candidates: ticket routing, status aggregation, follow-up reminders with approval gates.
Deferred items: browser writes and high-risk system changes until idempotency, approval, and rollback checks are validated.

The Prompt

When to Use

Variables

Tips & Variations

Example Output

Related site references