Skills vs Standard Agents vs Workflow Agents in SitecoreAI: What Should You Build?

Most SitecoreAI design mistakes begin one level too high. A team sees an automation opportunity and immediately decides to build an agent. The real question is smaller: does the organization need reusable guidance, an adaptive worker, or an explicit process? Those map to a skill, a standard agent, and a workflow agent. They overlap, but they are not interchangeable.

The wrong choice creates a maintenance tax. A workflow built for a simple writing method becomes a maze of variables and steps. A standard agent used for an irreversible process becomes hard to resume safely. A skill treated as an autonomous worker produces inconsistent invocation and no durable execution state. Each option is useful when its control model matches the work.

This guide compares the three choices using trade-offs, limits, maintenance cost, and concrete SitecoreAI cases. “Cost” means design effort, testing surface, change coordination, operating failures, and ownership. It does not claim a Sitecore price. Licensing requirements are stated only where current Sitecore documentation is explicit.

1. Start With the Control Model, Not the Feature Name

A skill is reusable instruction. It tells an agent how to perform a task, which sources or framework to use, what process to follow, and what output to produce. Sitecore documents custom skills as shared guidance that can be used in chat, selected for a standard agent, or applied through an invoked agent inside a workflow. A skill does not independently own a run, select its own tools, or persist checkpoints.

A standard agent is an adaptive execution boundary. Sitecore describes it as conversational and flexible. It determines how to perform tasks based on its instructions, tools, context, and skills. It is appropriate when the goal is stable but the path may vary. The agent may search, retrieve context, create an artifact, ask for clarification, or choose among enabled capabilities.

A workflow agent is an explicit process. It connects actions in a defined sequence and can include variables, schemas, templates, invoked agents, tools, storage, and human approval. Sitecore recommends it for structured, repeatable, multi-step work with consistent outcomes. Its value is not that it is “more advanced.” Its value is control over path, checkpoints, and side effects.

The fastest decision test uses three questions. Is the main asset a method that should be reused? Start with a skill. Is the main asset a flexible worker that decides how to reach a goal? Start with a standard agent. Is the main asset a business process whose order, resume behavior, or approval must be controlled? Start with a workflow agent.

Do not choose based on output format. A standard agent can return text, structured output, images, or widgets. A workflow can also generate structured artifacts. Schemas and templates are shared building blocks, not proof that a workflow is required. The deciding issue is who controls execution: reusable instructions, the agent, or the workflow designer.

Risk of repetition is a strong boundary. Sitecore’s comparison says standard agents suit focused executions where a failed run is repeated from the beginning and where repeated operation is safe or low impact. Workflow agents suit processes with checkpoints and actions that should not be repeated on retry, such as writing back to Sitecore at scale or calling external systems.

Human intervention is another boundary. A person can review any artifact, but a workflow can represent approval as an execution step that pauses the process. If approval must occur before publishing, sending, charging, or bulk mutation, model it in the process. Do not rely on a sentence in an agent instruction saying “ask first” when the consequence requires an enforceable checkpoint.

My default is the least stateful option that safely meets the requirement. Skills are cheapest to create and easiest to reuse. Standard agents add a configured execution surface. Workflow agents add state, mappings, failure paths, and operational ownership. Starting small preserves the option to evolve without paying the full process cost on day one.

2. Build a Skill When the Product Is a Reusable Method

A good skill captures durable procedural knowledge. Examples include a campaign-planning framework, a competitive-analysis method, editorial review rules, accessibility guidance, or a localization checklist. Sitecore recommends defining clear use cases, triggers, steps, and expected outcomes. The content can be written in Markdown or rich text and should be specific, actionable, and unambiguous.

The central advantage is reuse. One approved competitive-research skill can support chat, several standard agents, and an invoked agent in a workflow. The organization maintains the method once instead of copying it into every system prompt. Updates to required sources, scoring criteria, or output expectations can propagate to all consumers.

That same reuse is the main risk. A shared skill has a wide blast radius. An innocent wording change can alter several agents and workflows. Treat skills as versioned dependencies even if the interface presents a single editable object. Keep a consumer inventory, regression examples, an owner, a change log, and a review policy. A reusable asset without dependency management becomes hidden coupling.

A skill cannot guarantee invocation by itself. Sitecore’s standard-agent documentation says that selecting a skill does not necessarily guarantee use; if it must be used, the agent instructions should say so explicitly. This is an important limit. A skill is guidance available to an execution context. It is not an orchestration engine and does not enforce a fixed sequence.

A skill also does not own capabilities. It can describe how to research competitors, but the chat or agent must have web search, context retrieval, or other tools enabled. It can specify an output structure, but the consuming agent may need a schema to enforce that structure. It can say “request approval,” but it cannot create a resumable approval checkpoint by itself.

Maintenance cost is mostly editorial and governance work. Someone must curate instructions, examples, sources, terminology, and boundaries. The test surface is smaller than an agent because there is no standalone tool configuration or run state. Yet validation must cover multiple consumers. A skill that behaves well in chat may interact differently with an agent system prompt or a workflow message template.

Use skills for horizontal concerns. Brand voice is the classic example, but avoid one enormous “company policy” skill. Separate concerns that change at different rates: brand writing, legal claim handling, localization rules, SEO review, and campaign planning. Smaller skills reduce conflict and make ownership clearer. Combine them in an agent only when the task needs them.

Do not use a skill as a disguised application. If the instructions contain dozens of conditional branches, retry rules, API actions, and state transitions, the design wants an agent or workflow. Markdown is a poor state machine. The skill becomes hard to test because the execution path is implicit and depends on the model interpreting procedural prose.

Concrete case: editorial quality method

Suppose content teams want every agent to review drafts for unsupported claims, audience fit, tone, accessibility, and call-to-action clarity. Build one editorial-review skill with a rubric, prohibited patterns, examples, and a required report shape. Apply it in chat for ad hoc review, attach it to a content-optimization standard agent, and invoke that agent from a publishing workflow before approval. The method remains one governed asset while execution changes by context.

3. Build a Standard Agent When the Goal Is Stable but the Path Varies

A standard agent packages a role, instructions, inputs, tools, context, skills, and output. Sitecore positions it for chat-style, task-driven work that can adapt to different requests. The agent decides which enabled capabilities to use. That makes it a strong fit for research, analysis, content optimization, ideation, and focused content generation where the user may refine the request interactively.

The main advantage is adaptability. A content optimization agent can accept an email, landing page, social post, or ad. It may retrieve brand context for one request, analyze plain text for another, and ask for the target audience when missing. A workflow would need explicit branches and mappings for each variation. A skill alone would not provide the configured tools or primary output.

The main limit is control. The agent may choose a different sequence between runs. It may use an enabled skill only when it judges it relevant unless instructions require it. It may call tools in an unexpected order or avoid a tool when it believes existing context is enough. This behavior is useful for open tasks and uncomfortable for regulated or irreversible processes.

Tool breadth affects quality and maintenance. Sitecore standard agents can be configured with standard tools such as context retrieval, artifact saving, web search, and image generation, plus Agent API capabilities for sites, pages, content, components, assets, personalization, jobs, and briefs. Enabling every capability increases both risk and selection ambiguity. Give the agent the smallest useful toolset.

Output choice changes the contract. Text is easy for conversation but hard for downstream automation. Structured output backed by a schema is easier to validate. Images and widgets add their own review and rendering concerns. Choose the primary output based on the consumer. If another system needs fields, do not depend on parsing prose because it looked readable during a demo.

Standard-agent maintenance has four surfaces: instructions, selected skills, tool permissions, and output contract. Context sources add a fifth. A change in any one can alter behavior. Keep a small golden suite of representative prompts, missing-input cases, tool failures, brand conflicts, and prohibited actions. Export the agent JSON for review and rollback where supported.

Failure recovery is coarse. Sitecore’s decision guidance notes that skill-based executions in a standard-agent run are completed as one run; if the operation fails, the entire operation must be rerun. This is acceptable for low-impact analysis. It becomes expensive when the agent generated a large artifact or called external systems. It becomes dangerous when a retry can repeat a mutation.

Use a standard agent as a reusable specialist inside workflows. Sitecore’s Invoke Agent action can call an existing standard agent and pass its result to the next step. This avoids rebuilding expertise in every workflow. The workflow controls ordering and checkpoints, while the standard agent owns a focused adaptive task such as sentiment analysis, research, or content review.

Concrete case: content optimization specialist

A content optimization agent accepts a draft, audience, channel, and optional campaign context. It uses context retrieval and an editorial skill. It returns a structured diagnosis and improved draft. The user may ask follow-up questions or reject suggestions. No external system is updated automatically. This is a standard-agent problem because the goal is stable, the inputs vary, and adaptation is more valuable than a fixed sequence.

Concrete case that should not remain standard

A “launch campaign” agent researches, generates five assets, creates pages, uploads media, sends an email, and updates a CRM. A failed final step forces uncertainty about earlier side effects. Instructions cannot create reliable checkpoints. Move orchestration into a workflow and keep adaptive subproblems as invoked standard agents.

4. Build a Workflow Agent When Sequence and Recovery Are Product Requirements

A workflow agent makes execution visible. The designer defines actions, connections, variables, prompts, schemas, templates, tool calls, artifacts, and approvals. Sitecore recommends workflows for structured, repeatable, multi-step processes with consistent outcomes. The workflow is valuable when business logic needs to be inspected separately from model reasoning.

Control is the primary benefit. A process can require research before generation, schema validation before rendering, legal approval before a write-back, and a saved artifact before a notification. The model can still work inside generation or invoked-agent steps, but it does not decide whether a mandatory approval exists or which step follows a rejected result.

Resilience is the second benefit. Sitecore describes checkpoints that permit a workflow to pause and restart from the last successful step. This matters when rerunning the full process is costly or unsafe. A localization workflow may translate thirty items, pause for review, and continue publishing only approved variants. A failure on item twenty-nine should not regenerate or duplicate the first twenty-eight.

The cost is explicit complexity. Every step introduces inputs, outputs, variable names, mappings, failure behavior, and test cases. Schemas and templates add dependencies. External calls add authentication and rate limits. Approval adds roles and waiting states. Artifact storage adds naming and lifecycle rules. A workflow with ten steps is not merely twice as hard to maintain as one with five because connections and recovery paths multiply.

Workflow agents can invoke SitecoreAI tools directly. Sitecore documents an Invoke Tool action for page search, content retrieval, page creation or update, validation, assets, and other capabilities. Tool responses may contain nested data, validation messages, warnings, or failures. Normalize outputs before downstream steps. Do not bind a later step to an incidental upstream property without a schema or adapter.

Workflows can also invoke standard agents. This is the best composition pattern for many teams. The workflow owns process state, approval, and side effects. The standard agent owns an adaptive domain task. The skill owns reusable method. Each layer has one reason to change. Copying the standard agent’s prompt into three workflow nodes removes that separation and raises maintenance cost.

Testing must cover paths, not only outputs. Test successful execution, rejected approval, missing input, tool failure, timeout, retry, resume, duplicate trigger, and partial completion. Verify that side effects are not repeated. Inspect the Runs tab during development, but maintain external acceptance evidence for critical processes. A green final artifact does not prove the path followed required controls.

Workflow agents are poor fits for exploratory conversation. A rigid process frustrates users when they want to ask follow-up questions, change direction, or provide information in an unexpected order. Do not model every possible conversation branch. Use a standard agent to clarify and prepare a structured request, then hand the accepted request to a workflow.

Concrete case: governed campaign launch

A practical workflow receives an approved brief, invokes a research agent, generates structured channel assets, validates brand and legal requirements, pauses for campaign-owner approval, creates draft pages through an Agent API tool, saves artifact links, and notifies stakeholders. Rejection returns to the generation step with reviewer notes. Publishing remains a separate approved action. The workflow cost is justified because order and non-repetition are business requirements.

5. Compare Maintenance Economics, Not Just Build Effort

Initial build time is a weak decision metric. The larger cost arrives through change. Marketing rules evolve. Sitecore tools and schemas change. Brand guidance is revised. External APIs fail. Owners move teams. A design is economical when the most common change affects the fewest assets and the system reveals which consumers need retesting.

Skills have low construction cost and potentially high dependency cost. Editing a shared instruction is easy. Proving it still works across five agents and three workflows is not. Maintain a consumer graph. If the platform does not expose one automatically, keep a simple registry with owner and criticality. Require broader testing when a shared skill changes.

Standard agents have medium configuration cost and behavioral uncertainty. Their maintenance burden comes from interaction among instructions, skills, tools, and context. A new tool may improve one case and create surprising selection in another. Measure correction rate, tool-call patterns, failure categories, and artifact acceptance. Prompt length is not a meaningful maintenance metric by itself.

Workflow agents have the highest visible maintenance cost. Variables and mappings break when a step changes output. Human approvals create operational queues. External systems add credentials and contracts. Checkpoints require state retention. Yet workflows can reduce hidden operating cost by preventing duplicate actions, making failure location visible, and allowing restart from a safe point.

Ownership structure should match the artifact. A domain owner maintains skill content. An agent owner maintains role, instructions, tools, and outputs. A process owner maintains workflow sequencing, approval policy, and operational success. Platform owners maintain connections and shared schemas. When one person informally owns everything, the system becomes fragile when that person is unavailable.

Apply a maintenance budget before building. Count expected skills, consumers, agent tools, workflow steps, external integrations, approval roles, schemas, and failure paths. The count is not a price, but it reveals shape. A design with two agents, fourteen steps, four external systems, and three approvals deserves an operating plan, not just a launch date.

Track change frequency. A volatile method embedded directly into seven agents creates repeated editing. Extract it into a skill. A volatile workflow step copied across several processes may deserve a standard-agent specialist or shared tool. A stable one-off rule may be cheaper left local. Reuse is valuable only when the reused concept actually changes together.

My contestable opinion is that many teams build workflows too early because diagrams feel controlled. The diagram hides semantic uncertainty inside generation steps and creates mapping debt around it. Start with a skill and a standard agent until the process boundary is understood. Promote to a workflow when failures, approvals, or side effects prove that orchestration has real value.

6. Route Concrete Use Cases With Risk and Variability

Brand voice guidance

Build a skill when the need is a reusable method for tone, terminology, examples, and prohibited patterns. Use it from chat and several agents. Add a schema only when outputs need structured validation. Do not create a brand agent merely to hold static instructions unless it must retrieve context, analyze varied inputs, or produce a dedicated artifact experience.

Competitive research

Use a skill for the research methodology: approved sources, comparison dimensions, evidence rules, and output framework. Use a standard agent when users provide different competitors and questions, and the agent must decide how to search and synthesize. Use a workflow when research feeds a governed sequence such as strategy review, executive approval, brief creation, and downstream campaign actions.

Content optimization

A standard agent is usually best. Inputs vary, judgment is adaptive, and users benefit from conversation. Attach editorial and brand skills. Enable context retrieval and artifact saving. If optimized content must automatically update a Sitecore item, move the mutation into a separate workflow step with review. Keep the creative specialist unchanged.

Bulk localization

Use a skill for terminology and localization rules. Use a standard agent for one-off translation or review of a single item. Use a workflow for many items or locales, especially when each output needs schema validation, reviewer approval, status tracking, retry, and write-back. Repeating the whole run after item forty-eight fails is an avoidable operating cost.

Campaign brief generation

A standard agent works when a marketer explores objectives, audience, channels, and messaging through conversation. A workflow works when the brief must collect required fields, call research, generate a schema-bound artifact, route to stakeholders, and create approved downstream tasks. The same campaign-planning skill can support both.

Page creation

Use a standard agent for guided exploration of page concept and content. Use a workflow when the system resolves a site, selects a template, generates content, validates fields, requests approval, creates the page, adds components, assigns datasources, and records links. Sitecore writes and component changes are side effects. Make their order and retry policy explicit.

Ad hoc CSV analysis

A system or custom CSV skill in chat may be enough when the user wants a quick analysis. A standard agent makes sense when the organization wants consistent domain interpretation, context, and a named artifact. A workflow makes sense only when analysis is one step in a repeatable process, such as enriching accounts, validating results, obtaining approval, and updating a system.

External notification

A skill can define message style. A standard agent can draft the message. A workflow should send it when sending is part of the requirement. External actions should not be buried inside a flexible run that may be retried. Separate composition from delivery and place approval immediately before the irreversible step.

Across these cases, one pattern repeats: knowledge belongs in skills, adaptive judgment belongs in standard agents, and consequence management belongs in workflows. A solution may use all three. The choice is not a winner-takes-all comparison. It is an allocation of responsibility.

7. Evolve Deliberately and Know When to Migrate

Start with evidence of the task. Run it manually in chat. Identify repeated guidance and extract a skill. When users need a stable specialist with selected tools, context, and output, create a standard agent. When the run accumulates checkpoints, approvals, costly retries, or side effects, wrap the relevant work in a workflow. This progression keeps complexity tied to observed needs.

Migrate from copied prompts to a skill when the same method appears in three or more places, when policy owners need one update point, or when inconsistent examples cause drift. Do not extract generic filler. The shared skill should represent one coherent method with clear triggers and outputs. Keep consumer-specific instructions local.

Migrate from chat plus skill to a standard agent when the task needs a named role, repeatable inputs, a controlled toolset, selected context, a consistent artifact, or a reusable specialist for workflows. The agent should have a focused domain. If its description contains several unrelated jobs joined by “and,” split it before adding more tools.

Migrate from a standard agent to a workflow when users report costly reruns, duplicated actions, missed approvals, uncertain partial completion, or inconsistent sequencing. These are orchestration signals. Do not migrate merely because a task has several conceptual steps; an adaptive agent can manage several reasoning steps safely when they remain one low-impact run.

Sometimes move in the other direction. A workflow whose steps are mostly prompt fragments and whose users constantly request exceptions may be over-modeled. Collapse adaptive steps into a standard agent and keep only the real control points. A standard agent that merely applies one fixed rubric without tools may be a skill consumed by chat. Removing architecture is a valid maintenance improvement.

Use interfaces between layers. Skills define expected methods and output guidance. Standard agents expose documented inputs and structured outputs. Workflows consume those outputs through schemas and own state transitions. Avoid references to hidden wording or incidental artifact layout. A clean interface allows the skill to improve without breaking workflow mappings.

Version and test migrations. Export existing agent configuration. Capture representative artifacts and tool traces. Run the candidate design against the same cases. Verify quality, latency, retry behavior, permissions, and approval. Keep the old path available until users accept the new artifacts and operators can recover failures. A visually correct workflow can still be worse if it doubles review time.

Set portfolio guardrails. Require an owner, purpose, consumers, risk class, review date, and success measure for every custom skill or agent. Require an operating owner and recovery plan for workflows with side effects. Archive unused assets. Duplicate agents and near-identical skills create selection confusion and maintenance work even when they never run.

Sitecore currently requires a Builder license to create custom skills and custom agents, according to its creation documentation. Treat access as governance, not just enablement. Limit editing rights to accountable owners while keeping review collaborative. Export configurations and record important changes so rollback does not depend on memory.

The practical decision is straightforward. Build a skill when the reusable knowledge is the product. Build a standard agent when adaptive execution is the product. Build a workflow agent when controlled process and recovery are the product. Combine them when a governed process needs adaptive specialists that share approved methods.

This framework has a limitation. It cannot calculate your exact operating cost because team structure, volume, risk, integrations, and Sitecore configuration differ. Use it to expose cost drivers, then measure actual run failures, review time, change frequency, and support effort. The right architecture is the smallest one that handles the real consequence of failure.

Before creating anything, write one sentence: “This asset exists because…” If the answer is “to reuse how we do this,” choose a skill. If it is “to give users a specialist that decides how,” choose a standard agent. If it is “to guarantee how the process moves and recovers,” choose a workflow agent. That sentence is a better architecture test than the number of steps in a diagram.

Anti-patterns that increase maintenance cost

The first anti-pattern is the “mega skill.” It combines brand rules, campaign planning, legal review, localization, analytics, and publishing guidance in one document. Consumers cannot tell which parts apply. Every owner must review every change. Conflicting instructions accumulate. Split by reason to change and domain ownership. Compose the needed skills in a focused agent instead of creating a universal handbook.

The second anti-pattern is the “toolbox agent.” It receives every available SitecoreAI capability because future use cases are unknown. The broad catalog raises authorization risk and makes tool selection less predictable. Users also assume the agent can safely complete end-to-end processes that were never designed. Create a narrow specialist, measure unmet requests, and add one capability only when its permissions, errors, and tests have an owner.

The third anti-pattern is the “prompt workflow.” Each box contains another long instruction, but the process has no real state boundary, validation, approval, or side effect. The workflow adds variables and mappings without improving recovery. Collapse the boxes into one standard agent unless intermediate artifacts have distinct owners or contracts. A diagram is not evidence of control.

The fourth anti-pattern is hidden mutation. A flexible agent both drafts content and writes it back to Sitecore because combining the steps looks convenient. When users retry after a weak result, they may repeat the mutation. Separate analysis and composition from the write step. Put the mutation in a workflow after a visible review, or require an explicit user-controlled action outside the agent.

The fifth anti-pattern is copied expertise. Three workflow steps and two standard agents contain slightly different competitive-analysis prompts. Fixes propagate manually and results drift. Extract the stable methodology into a skill, but keep consumer-specific input mapping and output contracts local. Reuse the method, not every sentence surrounding it.

A practical maintenance scoring model

Teams can estimate relative maintenance before implementation with a simple inventory. Assign one point for each custom skill, selected tool, schema, template, output type, and human role. Assign two points for each external integration, Sitecore mutation, resumable checkpoint, or shared dependency consumed by more than three assets. Assign three points for each irreversible action or regulatory approval. This is not a pricing formula. It forces the design review to acknowledge dependencies.

A skill often begins with a low score: one instruction asset, one owner, and several examples. Its score rises with consumers because every shared change needs broader testing. A standard agent adds tools, context, output contracts, and a behavioral regression suite. A workflow adds action mappings, state, retries, approvals, and integrations. Compare candidate designs by score and failure consequence, not score alone. A higher-cost workflow is correct when it contains a higher-cost operational risk.

Record recurring maintenance work for ninety days after launch. Count content updates, configuration changes, broken mappings, permission incidents, failed runs, reruns, approval delays, and user corrections. Add the time spent diagnosing each category. The observed distribution will show whether the architecture matches the task. High correction with few process failures points toward agent or skill refinement. High partial failures and duplicate actions point toward workflow controls.

Testing by asset type

Test a skill with scenario examples across every important consumer. Verify trigger clarity, required steps, prohibited behavior, and output guidance. Include a case where the skill should not apply. A skill that activates everywhere can degrade unrelated work. When the skill changes, run the consumer matrix rather than testing only the editor preview.

Test a standard agent with representative prompts, missing context, contradictory context, tool denial, tool timeout, and output validation. Record which tools it chose and whether it asked for clarification. Include adversarial requests that attempt to exceed its role. Because the execution path is adaptive, test invariants such as “never publish” or “always use the editorial skill for final review” separately from semantic quality.

Test a workflow with path coverage. Exercise each branch, approval outcome, retry, resume point, timeout, and duplicate trigger. Confirm variable mappings at every boundary. Force an invoked agent to return invalid structured data. Force an external call to fail after an earlier side effect. Verify that the workflow records committed work and does not repeat it. A workflow test that checks only the final artifact misses its main value.

Operating signals that justify a redesign

A skill needs redesign when consumers override large portions of it, owners cannot coordinate changes, or users apply it to unrelated tasks. Split it, clarify triggers, or move consumer-specific logic into agents. A standard agent needs redesign when tool-selection errors dominate, instructions contain a hand-built state machine, or support cannot reproduce the path. Narrow it or move process control into a workflow.

A workflow needs redesign when most runs follow one simple path but every small wording change breaks mappings, when users abandon it to work in chat, or when approval queues add delay without reducing risk. Remove ceremonial steps. Move adaptive work into an invoked standard agent. Keep only checkpoints tied to a real decision, contract, or side effect.

Portfolio-level signals matter too. If teams create several similar agents because existing ones are hard to discover, improve naming, tags, documentation, and ownership before building more. If a shared skill change causes surprise regressions, create a consumer registry and release process. If workflows depend on orphaned agents, assign lifecycle rules so a dependency cannot be deleted or substantially changed without impact review.

Governance without freezing experimentation

Use two lanes. An exploration lane allows chat, temporary instructions, and prototypes with no consequential write-back. A production lane requires an owner, documented inputs, least-privilege tools, regression examples, review date, and support route. Moving from exploration to production is a promotion decision. This keeps experimentation fast while preventing prototypes from quietly becoming critical infrastructure.

Govern shared assets more strictly than local ones. A local skill used by one agent can change with that agent’s review. A skill used by twelve assets needs release notes and coordinated testing. A workflow that publishes or contacts external systems needs stronger approval than a workflow that only produces a draft artifact. Governance should follow blast radius and consequence, not artifact type alone.

Archive aggressively. An inactive agent still appears in discovery, confuses users, and retains permissions. An obsolete skill can be selected by mistake. A dormant workflow can preserve expired integrations or owners. Define inactivity and review thresholds. Export or document what must be retained, then remove the asset from active use through the platform’s supported lifecycle rather than leaving a graveyard.

Decision Checklist

• Is the core value reusable instructions, adaptive execution, or controlled orchestration?
• Can the whole run be repeated safely and affordably?
• Must any action occur only after human approval?
• Does a failure need to resume from a checkpoint?
• Will several consumers share the same method?
• Does the task require selected tools, context, or a named artifact?
• Are there external systems or Sitecore write-backs?
• Who owns content, behavior, process, and operations?
• What changes most often, and how many consumers must be retested?
• Can a simpler asset meet the requirement without hiding risk?

Primary references: Sitecore’s guidance on agent skills, standard agents, workflow agents, the official standard-versus-workflow comparison, and workflow actions and invoked agents.