Generated banner for Agent Advisor
Generated logo for Agent Advisor

Agent Advisor

AWSOfficialPublished by AWS

  • Skill
  • Workflow
  • Cloud and DevOps
  • Apache-2.0
  • Low risk
  • Has scripts

From the author

Entry point for AI-agent work on AWS: pick a runtime, plan a migration for existing workloads, and build an executable POC — one phased flow. Triggers on: which runtime for my agent, AgentCore vs ECS vs EKS vs Lambda, AgentCore vs Lambda MicroVMs, deploy an AI agent on AWS, agent architecture on AWS, I have an agent idea what do I build, move/migrate my agents to AWS, agent migration plan, add AgentCore services (memory, gateway, identity, policy, observability) to an agent already on AWS, Temporal on AWS (migrate/run Temporal workers on AWS, a service orchestrated by Temporal, Temporal Cloud vs self-hosted). Temporal Workflow code is never rewritten into Step Functions. Requires at least one agentic component — a purely non-agent system (plain services, batch jobs, HTTP endpoints, non-agent Temporal Activities) is out of scope, redirected to gcp-to-aws / heroku-to-aws / llm-to-bedrock. Not for: compute/data migration with no AI agent; pure LLM SDK rewrite (use llm-to-bedrock); per-model pricing.
— the description by AWS

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

Agent Advisor provides a structured, multi-phase workflow to help users determine the optimal AWS runtime for their AI agents. It uses a deterministic scoring engine to evaluate requirements and guides users through a process that includes discovery, architectural design, cost estimation, and the creation of an executable proof-of-concept. The skill supports various AWS compute options, including AgentCore, ECS, EKS, and Lambda, and integrates with migration engines for existing workloads.

What it does

  • Recommends AWS runtimes for AI agents based on technical requirements.
  • Generates migration plans for existing AI workloads moving to AWS.
  • Provides architectural guidance for agentic systems.
  • Assembles executable proof-of-concept scaffolding.
  • Estimates coarse cost magnitudes for proposed agent deployments.
  • Integrates with external migration engines for workload transitions.

When to use it

  • When you need to decide which AWS runtime is best for a new AI agent.
  • When migrating an existing AI agent workload to AWS.
  • When you need to add services like memory, identity, or observability to an existing AWS agent.
  • When you require a structured plan and POC for deploying agents on AWS.

Advantages

  • Provides a deterministic, repeatable recommendation process.
  • Supports a wide range of AWS compute environments.
  • Offers a unified flow from initial idea to executable POC.
  • Adapts to both technical and business-focused user backgrounds.

Usage examples

“I have an agent idea, what do I build?”
The agent initiates the intake process to clarify your requirements and recommend an appropriate AWS architecture.
“Move my agents to AWS.”
The agent triggers the migration workflow to assess your existing workload and plan the transition to an AWS runtime.
“Which runtime for my agent, AgentCore vs ECS vs EKS vs Lambda?”
The agent runs a scoring analysis to compare these runtimes against your specific agentic needs.
“Add AgentCore services to an agent already on AWS.”
The agent enters the add-capabilities branch to guide you through integrating memory, gateway, and observability services.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/aws/agent-advisor/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip agent-advisor.zip -d .agents/skills

Documentation by AWS

AWS Agent Advisor

Helps startups decide how and where to run AI agents on AWS. Deterministic scoring recommends a runtime; the conversation adapts to the user's technical background.

Definitions

  • "Load" = Read the file with the Read tool and follow it. Do not summarize or skip.

  • $RUN_DIR = the run directory under .agent-advisor/ (e.g. .agent-advisor/0630-1430/), created in Intake.

  • $PLUGIN = ${CLAUDE_PLUGIN_ROOT} (the installed plugin root). On Claude Code this token substitutes inline. If ${CLAUDE_PLUGIN_ROOT} does not resolve (some Cursor/Codex builds, or a literal ${CLAUDE_PLUGIN_ROOT} string showing up in a path error), fall back to the skill's own directory: this SKILL.md lives at <plugin>/skills/agent-advisor/SKILL.md, so the engine and its data are all inside this skill — scripts at ./scripts/..., runtime profiles at ./references/runtimes/..., and decision refs at ./references/decision-refs/... relative to it. Prefer ${CLAUDE_PLUGIN_ROOT}/skills/agent-advisor/...; use the relative fallback only when it fails to resolve.

Prerequisites

Phase Structure (frontmatter)

Phase, fragment, and assembler files carry a YAML frontmatter block that declares how each phase is composed — its inputs, triggers, fragments, assembler, artifacts, gates, and ordering. The execution contract is the vendored references/vendored/dsl/INTERPRETER.md: it defines every frontmatter key, the fragment/assembler model, the gate protocol (HANDOFF_OK / GATE_FAIL), and the interpreter loop. Load it first (once, at the start of a run), then execute each phase file's prose body. Elsewhere in this skill, INTERPRETER.md (without a path) refers to this loaded contract.

Execution

This skill is driven by the interpreter loop in INTERPRETER.md (§ The interpreter loop): it reads .phase-status.json, determines the current phase, runs each phase's _preconditions / fragments / _assemble / _postconditions, advances on HANDOFF_OK via _advances_to, and validates state. The backbone (intake → discover → clarify → confirm → design → estimate → generate → migration-plan → poc → complete) and the one sidebar branch (add-capabilities) are derived from the phase files' frontmatter — they are not restated here.

Cold start (entry phase). With no run under .agent-advisor/ carrying a .phase-status.json, begin at references/phases/intake/intake.md — this skill's entry phase (the one carrying _init: true). On a warm start, current_phase in .phase-status.json is authoritative (INTERPRETER.md § The interpreter loop).

Skill bindings (INTERPRETER.md § Skill bindings). This skill declares:

  • Run root: .agent-advisor/ — $RUN_DIR is this skill's name for the run directory (.agent-advisor/[MMDD-HHMM]/). Intake's own prose performs the _init bootstrap.

  • State shape: § State file below (advisor-specific keys such as entry_point, audience, recommendation_reviewed, migration_plan_ctx, migration_plan_unavailable); the shared state schema is not vendored.

  • Run seed (optional): $RUN_DIR/seed.json, else .agent-advisor/seed.json at the run root (schema scripts/schemas/seed.json) supplies machine-readable answers for a non-interactive run — the Clarify dimensions, the two gate answers, the POC mode, the live-probe answer, and a co_recommend tie-break. It is the HIGHEST-precedence source for every value it carries (clarify.md Step 2.5), which is what makes a repeated run's score comparable: the deterministic engine gets byte-identical input. A gate the seed omits is declined; a dimension the seed omits falls through to detection, then prose, then an assumed value that MUST be recorded in $RUN_DIR/UNANSWERED.md. With no seed, the interactive flow is unchanged.

  • Resolved statuses: skipped (routing resolved the phase without running it), plus not_applicable for migration_plan only.

  • Conditional backbone routing: the entry-point routing below. When a routing rule marks a phase not-applicable, set it skipped and advance through its _advances_to in the same state write.

Routing & gates (orchestration)

Sidebar placement and conditional backbone routing are orchestration prose owned by this file (INTERPRETER.md § Skill bindings, § Backbone vs sidebar).

Entry-point routing:

  • build_scratch → skip Discover; Clarify → Confirm → Design → Estimate → Generate → Gate 2 → POC (any winning runtime). No migration plan (nothing existing to migrate).

  • build_deploy → Discover (if code) → Clarify → Confirm → Design → Estimate → Generate → Gate 1 → Migration Plan (if existing non-AWS AI workload detected and user confirms) → Gate 2 → POC (any winning runtime).

  • migrate → Discover (if code) → Clarify → Confirm → Design → Estimate (target-state run cost; migration TCO comparison stays with the Migration Plan engine) → Generate → Gate 1 → Migration Plan (in-skill, reusing the sibling gcp-to-aws skill) → Gate 2 → POC (any winning runtime, when the plan was produced). Declining Gate 1 keeps the classic handoff: pointer to /aws-startup-advisor:llm-to-bedrock with handoff-summary.md.

  • add_capabilities → load references/phases/add-capabilities/add-capabilities.md and follow it (no runtime scoring; writes capabilities-recommendation.md). This is a self-contained branch — it does NOT pass through Clarify / Confirm / Design / Estimate / Generate, so the phase gate below never applies to it.

  • Temporal detection routes into migrate with temporal units pre-seeded (see discover).

Gate semantics (backbone tail):

  • Gate 1 → migration_plan runs only when generate is done AND recommendation_reviewed == true (generate.md Step 5.5) AND entry point ∈ {migrate, build_deploy} AND the run is migration-eligible (generate.md Step 6) AND the user confirmed Gate 1. Otherwise resolve it: not_applicable (build_scratch / no migratable workload) or skipped (declined) — and advance.

  • Gate 2 → poc runs only when phases.poc == "in_progress" (set when the user answers Gate 2 "yes" — asked in generate.md Step 7 or migration-plan.md Step 6) AND recommendation_reviewed == true. Any winning runtime (agentcore / ecs / eks / lambda / lambda_microvms) — the POC shape follows the verdict (poc.md Step 3 dispatch on references/decision-refs/poc-shapes.md). Gate 2 is only offered when migration_plan ∈ {completed, skipped, not_applicable} — or in_progress on build_deploy only (Stage 2 failed/aborted; fallback POC from design.json per migration-plan.md failure handling); for entry point migrate, only when migration_plan == "completed" (the POC implements the plan) OR when the stage resolved not_applicable with migration_plan_unavailable == "engine_absent" — a standalone deployment that does not bundle the migration engine, where Gate 2 is offered by migration-plan.md Step -1 and the POC is design-backed. A migrate-POC with no plan for any OTHER reason (the user declined) has nothing to implement.

  • Persisting Gate 2 as phases.poc = "in_progress" BEFORE poc.md loads makes the confirmation resumable: if the session breaks between the "yes" and the load, the interpreter re-enters poc without re-asking. (A declared deviation from INTERPRETER.md § The interpreter loop step 5's gate-then-in_progress ordering — the user's confirmation is the entry event worth persisting.)

Phase gate: Do NOT load design.md / estimate.md / generate.md unless $RUN_DIR/.phase-status.json exists and BOTH phases.clarify == "completed" AND phases.confirm == "completed". Confirm confirms the deployment model, the service set, and (for a co_recommend tie) the user's chosen_runtime — Design and the diagram depend on its confirm.json output, so it must not be skipped. If the user asks to skip Clarify or Pass 2, refuse briefly and run it.

State file (.phase-status.json)

{
  "run_id": "0630-1430",
  "entry_point": "build_scratch",
  "audience": "technical",
  "current_phase": "clarify",
  "phases": {
    "intake": "completed",
    "discover": "skipped",
    "clarify": "in_progress",
    "confirm": "pending",
    "design": "pending",
    "estimate": "pending",
    "generate": "pending",
    "migration_plan": "pending",
    "poc": "pending"
  }
}

Status values: pending → in_progress → completed, plus skipped. Use read-merge-write: read before each update, change only the advancing keys, keep prior phases.

recommendation_reviewed (top level, boolean) is set to true by generate.md Step 5.5 when the user explicitly confirms they have seen the recommendation. Gate 1, Gate 2, and the migration_plan / poc states all require it — no gate may be asked while it is absent.

migration_plan additionally uses not_applicable (build_scratch, or no migratable workload detected). When Stage 2 runs, migration_plan_ctx is added at the top level: {"repo": "<abs path to target repo>", "migration_dir": "<abs path to .migration/<id>/>"} — Stage 3 reads gcp-to-aws artifacts ONLY via this recorded path, never by re-globbing.

Files

FilePurpose
references/vendored/dsl/INTERPRETER.mdVendored DSL execution contract (interpreter loop + gate protocol)
references/phases/intake/intake.mdEntry point + technical background + open context
references/phases/discover/discover.mdLightweight code detection
references/phases/clarify/clarify.mdClarify orchestrator + answer mapping to scoring keys
references/phases/clarify/clarify-technical.mdTechnical-background question wording
references/phases/clarify/clarify-business.mdBusiness-background question wording
references/phases/confirm/confirm.mdWinner-specific follow-ups
references/phases/design/design.mdAssemble recommendation; Migrate handoff branch
references/phases/estimate/estimate.mdCoarse cost magnitude
references/phases/generate/generate.mdLayered recommendation doc + scaffolding
references/phases/migration-plan/migration-plan.mdStage 2: full migration plan via the sibling gcp-to-aws engine
references/decision-refs/temporal.mdTemporal rules: Tier 1/2 tables, adapter, runbooks, commercials (consumed by discover/clarify/design/generate)
references/decision-refs/poc-shapes.mdPer-runtime POC deploy shapes (ECS/EKS/Lambda/MicroVMs/Temporal)
references/decision-refs/*.mdRuntime service cards, model defaults, freshness
references/decision-refs/workload-classes.mdDeterministic verdicts for non-agent workload units (batch/service/io)
references/runtimes/*.jsonRuntime registry (read by scoring.py)
scripts/scoring.pyDeterministic scoring engine
scripts/test_temporal_decision_refs.pyContent lock for the Temporal decision reference
scripts/test_poc_shapes.pyContent lock for the POC deploy shapes
scripts/test_workload_classes.pyContent lock for workload-classes.md (verdicts table)
scripts/test_unit_grouping.pyUnit grouping + pattern matching (workload-class assignment)
scripts/test_collapse_invariant.pyCollapse-invariant ordering enforcement (A→B implies [B] ⊆ [A] outputs)

Maturity and readiness contract

Intake persists target_maturity (prototype, private_beta, or production) in run state. Clarify carries it and the readable readiness record into answers.json. Current-run verification evidence remains exclusively in the sibling $RUN_DIR/current-run-verifications.json artifact: never copy it into seed.json or answers.json. Design and Generate may consume that artifact only after validating its schema and matching run_id, and may carry forward verified outcomes but not the raw evidence records. Load references/decision-refs/maturity-readiness.md whenever target maturity is selected. A cached volatile fact may inform discovery, but only a record verified in this run can make a verification-required constraint final; otherwise the score remains provisional with deferred verification requirements.

Contextual offers (final step)

Before you finish: your answer is not complete until you have run the Contextual offers (final step) below.

This is a mandatory closing step of every final recommendation — complete it before you consider your answer done. Run this offer check inline yourself; do not depend on loading another skill. The recommendation is decided on merit first; this step never changes, re-ranks, or re-opens it, and the offer is looked up only after the advice is final.

  1. Read ../knowledge-base-for-startups/references/offers.md — the offer index (Offer · Summary · Keywords), one row per offer.

  2. Judge relevance against what the founder actually surfaced this session. Surface an offer only if one holds: a named-product match (you recommended a specific partner product by name and it has a row); a direct intent/component match (an offer's Keywords directly serve a concrete workload, a component in the final recommendation, or a need the founder raised). Keep a high bar — if the match is weak, or you would be inferring an unstated need, append nothing. Never surface an offer that competes with a product or provider the founder already uses or decided to keep (e.g. existing auth provider → no Auth0 unless they are already on Auth0, and then only as a credit on it; existing vector DB such as Pinecone → no Qdrant).

  3. If (and only if) one offer clears the bar, open only its detail file ../knowledge-base-for-startups/references/offers/<slug>.md and append exactly one quiet, dismissible italic line — stating the value and condensing eligibility faithfully from that file (drop no qualifying criterion; never fabricate), with the redeem link built from the canonical source_url plus a source attribution param — append ?source=ide-startupAdvisor-<host> (or &source=... if the url already has a query string), filling <host> from your execution environment (Claude Code → claude; AWS Startup Advisor IDE extension / VS Code → vscode; Cursor → cursor; Kiro → kiro; Codex → codex), or the generic ide-startupAdvisor when you cannot tell. Only append the query param; never change the destination. When an offer clears the bar you MUST append that single offer line as the last step; do not omit it. The offer is never the pick — only a line under the AWS pick — and stage gates in the references apply (e.g. no Datadog line for an early-stage founder; see ../architect-for-startups/references/observability.md). For a single-service pick (auth, payments, vector DB, observability, etc.) where missing budget/team/traffic inputs would not change the pick, assume an early-stage (pre-PMF) startup unless the founder says otherwise and answer in one turn without a stage-only question; this only removes a stage-only question and never skips the Intake/Clarify/Confirm gates before final advice or the POC. Show exactly one, never a list. If none clears the bar, append nothing and do not mention offers, partner alternatives, or why none appeared.

Standard line:

***<Offer>** has an exclusive offer via AWS Activate — <value>, <eligibility>. [Redeem →](<source_url>?source=ide-startupAdvisor-<host>)*

Caps and control: at most one offer per response and often none; no more than one per five messages and two per session; show a given offer at most once per session and never one already shown, claimed, or dismissed; if the founder has muted offers, skip this step entirely. These per-five-messages, per-session, and already-shown caps are session-state limits; in a fresh session with no prior offers they are non-binding, so do not withhold an otherwise-qualifying offer merely because you cannot verify session history. See ../contextual-offers-for-startups/SKILL.md for the full rules — but perform the check inline; it must not depend on that skill being loaded.

Files

scripts/build_diagram.py

"""Deterministic architecture-diagram composer for agent-advisor.

Pure: (scoring-result, confirm) dicts -> {"mermaid": str, "ascii": str}.
Same input -> byte-identical output. No timestamps, no randomness.
"""
import json
import pathlib

RUNTIME_LABELS = {
    "agentcore": "AgentCore Runtime",
    "lambda_microvms": "Lambda MicroVMs",
    "ecs": "Amazon ECS (Fargate)",
    "eks": "Amazon EKS",
    "lambda": "AWS Lambda",
    "batch": "AWS Batch",
    "fargate": "AWS Fargate",
    "serverless_workers": "Temporal Serverless Workers (Public Preview)",
    "none": "No viable runtime",
}

SERVICE_LABELS = {
    "identity": "Identity",
    "observability": "Observability",
    "evaluations": "Evaluations",
    "optimization": "Optimization",
    "memory": "Memory",
    "gateway": "Gateway",
    "policy": "Policy",
    "managed_kb": "Managed KB",
    "code_interpreter": "Code Interpreter",
    "browser": "Browser",
    "web_search": "Web Search",
    "sandbox": "Sandbox",
    "payments": "Payments",
    "registry": "Registry",
}

# Runtimes whose compute layer needs heavy infrastructure execution (clusters,
# Terraform) handed off to the migration skill. AgentCore, Lambda MicroVMs, and
# standard Lambda are self-contained deliverables from this advisor — not handoffs.
# Runtimes that hand the compute layer to the migration skill (their service cards say so):
# ECS, EKS, Fargate (= ECS), and AWS Batch. AgentCore, standard Lambda, and Lambda MicroVMs
# are self-contained. Keep in sync with design.md's handoff_required definition.
HANDOFF_RUNTIMES = {"ecs", "eks", "fargate", "batch"}


def unit_runtime(unit):
    """The runtime a unit ACTUALLY deploys on — effective_runtime under a consolidated
    platform, falling back to verdict for split runs (or older design.json without the
    field). The diagram must render where the unit really runs, not its best-fit verdict."""
    return unit.get("effective_runtime") or unit.get("verdict", "unknown")


def units_on_interconnect(units, modes):
    """Units coupled via any coupling.mode in `modes`, PLUS the target ends of their one-way
    interacts_with couplings (e.g. a producer mode:queue interacts_with a consumer mode:none —
    the consumer is on the queue too). A system can MIX couplings (some units on a queue, others
    via a gateway); each interconnect is computed independently from per-unit coupling.mode, not
    from the single dominant platform.interconnect value. Returns [] when no unit uses `modes`."""
    by_id = {u["id"]: u for u in units}
    on = set()
    for u in units:
        coup = u.get("coupling", {})
        if coup.get("mode") in modes:
            on.add(u["id"])
            for tgt in coup.get("interacts_with", []):
                if tgt in by_id:
                    on.add(tgt)
    return [u for u in units if u["id"] in on]


def units_needing_handoff(units):
    """Units whose ACTUAL runtime (effective_runtime||verdict) hands the compute layer to
    the migration skill — i.e. is in HANDOFF_RUNTIMES. Mirrors the single-unit path's handoff node so
    a multi-unit ECS/EKS/Fargate/Batch system shows the same 'configured by the migration skill'
    indicator instead of silently dropping it. Returns [] when no unit needs a handoff."""
    return [u for u in units if unit_runtime(u) in HANDOFF_RUNTIMES]


def resolve_runtime(result, confirm):
    verdict = result.get("verdict")
    if verdict == "co_recommend":
        return confirm.get("chosen_runtime") or result.get("co_recommend", ["none"])[0]
    if verdict == "no_viable_runtime":
        return "none"
    return verdict


def resolve_services(result, confirm):
    services = confirm.get("agentcore_services") or result.get("agentcore_services", [])
    seen, out = set(), []
    for sid in services:
        if sid in SERVICE_LABELS and sid not in seen:
            seen.add(sid)
            out.append(sid)
    return out


def render_mermaid(runtime, services, model, deployment_model):
    label = RUNTIME_LABELS.get(runtime, runtime)
    if runtime == "agentcore" and deployment_model:
        label = f"{label}<br/>({deployment_model})"
    lines = ["flowchart TD"]
    # Primary request/data flow (solid): user invokes the runtime, runtime calls the model.
    lines.append(f'    user["User / Client"]')
    lines.append(f'    rt["{label}"]')
    lines.append("    user -->|request| rt")
    # A model-less unit (non-agent: batch/service/light_io that calls no Bedrock model) has no
    # model node or invoke edge — do not render "Bedrock model: unknown".
    if model and model != "unknown":
        lines.append(f'    model["Bedrock model:<br/>{model}"]')
        lines.append("    rt -->|invoke| model")
    # AgentCore services are cross-cutting capabilities attached to the runtime, NOT
    # downstream call targets — group them in a subgraph and attach with dotted edges.
    if services:
        lines.append('    subgraph svcs["AgentCore services"]')
        lines.append("        direction LR")
        for sid in services:
            lines.append(f'        svc_{sid}["{SERVICE_LABELS[sid]}"]')
        lines.append("    end")
        lines.append("    rt -.-> svcs")
    if runtime in HANDOFF_RUNTIMES:
        lines.append('    handoff["Compute configured by the migration skill"]')
        lines.append("    rt -.-> handoff")
    return "\n".join(lines)


def render_ascii(runtime, services, model, deployment_model):
    label = RUNTIME_LABELS.get(runtime, runtime)
    if runtime == "agentcore" and deployment_model:
        label = f"{label} ({deployment_model})"
    # Primary flow: user -> runtime (-> Bedrock model, only if the unit calls one).
    lines = [
        "User / Client",
        "    |  request",
        "    v",
        f"[ {label} ]",
    ]
    if model and model != "unknown":
        lines += [f"    |  invoke", "    v", f"Bedrock model: {model}"]
    # Services are attached capabilities, shown separately (not as call targets).
    if services:
        lines.append("")
        lines.append(f"[ {label} ] .. attached AgentCore services:")
        for sid in services:
            lines.append(f"  - {SERVICE_LABELS[sid]}")
    if runtime in HANDOFF_RUNTIMES:
        lines.append("")
        lines.append("Note: compute configured by the migration skill")
    return "\n".join(lines)


def render_multi_unit_mermaid(design):
    lines = ["flowchart TD"]
    units = design.get("units", [])
    platform = design.get("platform", {})
    interconnect = platform.get("interconnect", "none")
    temporal_block = design.get("temporal", {})

    # Sanitize unit id for mermaid node id (replace hyphens with underscores)
    def sanitize_id(uid):
        return uid.replace("-", "_")

    # Check if this is a Temporal system
    worker_poll_units = [u for u in units if u.get("workload_class") == "temporal_worker_poll"]
    is_temporal = bool(worker_poll_units or temporal_block)

    if is_temporal:
        # Temporal topology: Temporal Server → worker_poll unit → Activity units.
        # The orchestrator label reflects the chosen Way (self-hosted stays self-hosted).
        way = temporal_block.get("way", "unknown")
        if way == "self_hosted":
            orch_label = "Temporal Server<br/>(self-hosted, orchestrator)"
        elif way == "cloud":
            orch_label = "Temporal Cloud<br/>(orchestrator)"
        else:
            orch_label = "Temporal Server<br/>(orchestrator)"
        lines.append(f'    temporal_cloud["{orch_label}"]')

        # Render each unit as a subgraph
        for unit in units:
            uid = unit["id"]
            sanitized_id = sanitize_id(uid)
            verdict = unit_runtime(unit)
            model_rec = unit.get("model_recommendation")

            # Build node label with runtime and model
            label_parts = [RUNTIME_LABELS.get(verdict, verdict)]
            if model_rec and model_rec.get("model"):
                label_parts.append(model_rec["model"])
            node_label = "<br/>".join(label_parts)

            lines.append(f'    subgraph {sanitized_id}["{uid}"]')
            lines.append(f'        {sanitized_id}_node["{node_label}"]')
            lines.append('    end')

        # Connect Temporal Cloud to worker_poll units
        for unit in worker_poll_units:
            sanitized_id = sanitize_id(unit["id"])
            lines.append(f"    temporal_cloud --> {sanitized_id}")

        # Connect each worker fleet ONLY to the Activity units it actually executes —
        # matched by queue membership (fleet.queues[] contains the Activity's task_queue),
        # never a cartesian product across all fleets. Fall back to a single-fleet
        # connect-all only when the fleet/queue data can't disambiguate.
        non_worker_units = [u for u in units if u.get("workload_class") != "temporal_worker_poll"]
        single_fleet = len(worker_poll_units) == 1
        for worker in worker_poll_units:
            worker_id = sanitize_id(worker["id"])
            fleet_queues = set(worker.get("queues", []))
            for activity_unit in non_worker_units:
                activity_id = sanitize_id(activity_unit["id"])
                task_queue = activity_unit.get("task_queue", "")
                if task_queue and fleet_queues:
                    # Only connect when this Activity runs on a queue this fleet polls.
                    if task_queue not in fleet_queues:
                        continue
                    lines.append(f"    {worker_id} -->|{task_queue}| {activity_id}")
                elif single_fleet:
                    # One fleet, no queue metadata to split on: it runs every Activity.
                    if task_queue:
                        lines.append(f"    {worker_id} -->|{task_queue}| {activity_id}")
                    else:
                        lines.append(f"    {worker_id} --> {activity_id}")
                # Multiple fleets without queue data: cannot attribute — leave unconnected
                # rather than draw a false cartesian-product edge.
    else:
        # Generic multi-unit topology
        lines.append('    user["User / Client"]')

        # NOTE: unlike the single-unit path, the multi-unit diagram does NOT draw a per-unit
        # AgentCore-services subgraph — with N units it would clutter the topology, and the
        # Generate report already lists each unit's agentcore_services in its per-unit table.
        # The handoff indicator (below) IS mirrored because it reflects a topology fact.

        # Render each unit as a subgraph
        agent_session_units = []
        for unit in units:
            uid = unit["id"]
            sanitized_id = sanitize_id(uid)
            verdict = unit_runtime(unit)
            model_rec = unit.get("model_recommendation")

            # Build node label with runtime and model
            label_parts = [RUNTIME_LABELS.get(verdict, verdict)]
            if model_rec and model_rec.get("model"):
                label_parts.append(model_rec["model"])
            node_label = "<br/>".join(label_parts)

            lines.append(f'    subgraph {sanitized_id}["{uid}"]')
            lines.append(f'        {sanitized_id}_node["{node_label}"]')
            lines.append('    end')

            # Track agent_session units for user entry edge
            if unit.get("workload_class") == "agent_session":
                agent_session_units.append(sanitized_id)

        # Connect user to agent_session units
        for uid in agent_session_units:
            lines.append(f"    user -->|request| {uid}")

        # Add interconnect nodes/edges. A system can MIX couplings — some units on a queue,
        # others via a gateway (Design records only the dominant `platform.interconnect`, but the
        # per-unit coupling.mode holds the real picture). So draw EACH interconnect that any unit
        # actually uses, independently — not one exclusive branch keyed on platform.interconnect.
        if len(units) > 1:
            has_any_coupling = any("coupling" in u for u in units)
            queue_units = units_on_interconnect(units, {"queue"})
            gw_units = units_on_interconnect(units, {"api", "a2a"})

            # No per-unit coupling data at all → fall back to the single platform.interconnect
            # over all units (legacy behavior for designs that predate per-unit coupling).
            if not has_any_coupling:
                if interconnect == "queue":
                    queue_units = units
                elif interconnect == "gateway":
                    gw_units = units

            if len(queue_units) > 1:
                lines.append('    queue["Queue"]')
                # Producer/consumer direction isn't in the data model, so show each coupled
                # unit's participation with an undirected-style dotted edge (as with gateway).
                for unit in queue_units:
                    lines.append(f"    {sanitize_id(unit['id'])} -.-> queue")
            if len(gw_units) > 1:
                lines.append('    gateway["Gateway"]')
                for unit in gw_units:
                    lines.append(f"    {sanitize_id(unit['id'])} -.-> gateway")
        # single unit, or interconnect none/in_process with no couplings: no edges

    # Handoff indicator — same as the single-unit path, but per unit: any unit on a
    # HANDOFF_RUNTIME (ecs/eks/fargate/batch) has its compute configured by the migration skill.
    handoff_units = units_needing_handoff(units)
    if handoff_units:
        lines.append('    handoff["Compute configured by the migration skill"]')
        for unit in handoff_units:
            lines.append(f"    {sanitize_id(unit['id'])} -.-> handoff")

    return "\n".join(lines)


def render_multi_unit_ascii(design):
    lines = ["Multi-unit Architecture:", ""]
    units = design.get("units", [])
    platform = design.get("platform", {})
    interconnect = platform.get("interconnect", "none")
    temporal_block = design.get("temporal", {})

    # Check if this is a Temporal system
    worker_poll_units = [u for u in units if u.get("workload_class") == "temporal_worker_poll"]
    is_temporal = bool(worker_poll_units or temporal_block)

    if is_temporal:
        # Temporal topology — orchestrator label reflects the chosen Way.
        way = temporal_block.get("way", "unknown")
        if way == "self_hosted":
            lines.append("Temporal Server (self-hosted, orchestrator)")
        elif way == "cloud":
            lines.append("Temporal Cloud (orchestrator)")
        else:
            lines.append("Temporal Server (orchestrator)")
        lines.append("    |")
        lines.append("    v")

        for unit in units:
            uid = unit["id"]
            verdict = unit_runtime(unit)
            model_rec = unit.get("model_recommendation")

            label = RUNTIME_LABELS.get(verdict, verdict)
            if model_rec and model_rec.get("model"):
                label += f" ({model_rec['model']})"

            if unit.get("workload_class") == "temporal_worker_poll":
                lines.append(f"  [ {uid}: {label} ] <-- long-polls task queues")
            else:
                task_queue = unit.get("task_queue", "")
                queue_info = f" (task queue: {task_queue})" if task_queue else ""
                lines.append(f"    --> [ {uid}: {label} ]{queue_info}")
    else:
        # Generic multi-unit topology
        lines.append("User / Client")
        lines.append("    |")
        lines.append("    v")

        for unit in units:
            uid = unit["id"]
            verdict = unit_runtime(unit)
            model_rec = unit.get("model_recommendation")

            label = RUNTIME_LABELS.get(verdict, verdict)
            if model_rec and model_rec.get("model"):
                label += f" ({model_rec['model']})"

            lines.append(f"  [ {uid}: {label} ]")

        # A system can mix couplings — draw EACH interconnect any unit actually uses (from
        # per-unit coupling.mode), not just the single dominant platform.interconnect value.
        # This mirrors the Mermaid path so a queue+gateway mix doesn't lose the queue here.
        has_any_coupling = any("coupling" in u for u in units)
        queue_units = units_on_interconnect(units, {"queue"})
        gw_units = units_on_interconnect(units, {"api", "a2a"})
        if not has_any_coupling:
            if interconnect == "queue":
                queue_units = units
            elif interconnect == "gateway":
                gw_units = units
        if len(queue_units) > 1:
            lines.append("")
            lines.append("Interconnect: Queue — " +
                         ", ".join(u["id"] for u in queue_units))
        if len(gw_units) > 1:
            lines.append("")
            lines.append("Interconnect: Gateway — " +
                         ", ".join(u["id"] for u in gw_units))

    # Handoff indicator (mirrors the Mermaid multi-unit path and the single-unit ASCII note):
    # any unit on a HANDOFF_RUNTIME has its compute configured by the migration skill.
    handoff_units = units_needing_handoff(units)
    if handoff_units:
        lines.append("")
        lines.append("Note: compute configured by the migration skill — " +
                     ", ".join(u["id"] for u in handoff_units))

    return "\n".join(lines)


def build_diagram(result, confirm, design=None):
    # If design has multiple units, render multi-unit topology
    if design is not None:
        units = design.get("units", [])
        if len(units) > 1:
            return {
                "mermaid": render_multi_unit_mermaid(design),
                "ascii": render_multi_unit_ascii(design),
            }
        if len(units) == 1:
            # Single-unit design: render from the design UNIT (which carries the resolved
            # effective_runtime, model_recommendation, deployment_model, agentcore_services),
            # falling back to the legacy `result`/`confirm` for any field the unit omits. This
            # fixes the case where `result` is the wrapped scoring-result.json ({"units": {...}})
            # whose top-level verdict/model are absent (which rendered "runtime None / model
            # unknown"), while preserving the collapse invariant: given consistent single-unit
            # data, this path and the legacy path below produce identical output.
            unit = units[0]
            runtime = unit_runtime(unit)
            if runtime in ("none", "no_viable_runtime", "unknown"):
                runtime = resolve_runtime(result, confirm)
            if runtime == "none":
                msg = "No viable runtime — see blocking constraints"
                return {
                    "mermaid": f'flowchart TD\n    n["{msg}"]',
                    "ascii": f"[ {RUNTIME_LABELS['none']} ]\n{msg}",
                }
            # Fall back to result/confirm ONLY when the unit OMITS the key — an explicit empty
            # list is authoritative (the user declined all AgentCore add-ons) and must be kept,
            # not replaced by scoring defaults like Identity/Observability.
            if "agentcore_services" in unit:
                services = unit["agentcore_services"] or []
            else:
                services = resolve_services(result, confirm)
            services = [s for s in services if s in SERVICE_LABELS]
            model = (unit.get("model_recommendation") or {}).get("model") \
                or result.get("model_recommendation", {}).get("model", "unknown")
            deployment_model = unit.get("deployment_model") or result.get("deployment_model")
            return {
                "mermaid": render_mermaid(runtime, services, model, deployment_model),
                "ascii": render_ascii(runtime, services, model, deployment_model),
            }

    # Legacy single-unit path (no design supplied — e.g. pre-design diagram)
    runtime = resolve_runtime(result, confirm)
    if runtime == "none":
        msg = "No viable runtime — see blocking constraints"
        return {
            "mermaid": f'flowchart TD\n    n["{msg}"]',
            "ascii": f"[ {RUNTIME_LABELS['none']} ]\n{msg}",
        }
    services = resolve_services(result, confirm)
    model = result.get("model_recommendation", {}).get("model", "unknown")
    deployment_model = result.get("deployment_model")
    return {
        "mermaid": render_mermaid(runtime, services, model, deployment_model),
        "ascii": render_ascii(runtime, services, model, deployment_model),
    }


def main(argv=None):
    import argparse
    parser = argparse.ArgumentParser(description="agent-advisor diagram composer")
    parser.add_argument("result", type=pathlib.Path)
    parser.add_argument("confirm", type=pathlib.Path)
    parser.add_argument("design", type=pathlib.Path, nargs="?", default=None,
                        help="Optional design.json path for multi-unit topology")
    args = parser.parse_args(argv)
    result = json.loads(args.result.read_text())
    confirm = json.loads(args.confirm.read_text()) if args.confirm.exists() else {}
    design = json.loads(args.design.read_text()) if args.design and args.design.exists() else None
    diagram = build_diagram(result, confirm, design=design)
    out = (
        "```mermaid\n" + diagram["mermaid"] + "\n```\n\n"
        "<details><summary>ASCII (plain-text fallback)</summary>\n\n"
        "```\n" + diagram["ascii"] + "\n```\n\n</details>\n"
    )
    out_path = args.result.parent / "diagram.md"
    out_path.write_text(out)
    runtime = resolve_runtime(result, confirm) if not design else "multi-unit"
    print(f"RESULT=ok RUNTIME={runtime}")
    return 0


if __name__ == "__main__":
    raise SystemExit(main())

Requirements and compatibility

Written for: Claude Code

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Names Claude Code tools, Needs Python

Security

What our scanner noticed· Low risk

  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
AWS
Publisher
AWS (Official)
Source
aws/agent-toolkit-for-aws · plugins/aws-startup-advisor/skills/agent-advisor · commit 0a218f8
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • NOTICE (added by AutoGineer from NOTICE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by AWS or AWS.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download agent-advisor.zip