Deciding on an AI solution starts with two factors: where the capability should live and how much freedom it needs while running. Use this guide to assess your needs.

An AI feature may need repeatable instructions or access to internal knowledge, and it may also need tool use or a multi-step workflow. Those requirements describe what the feature must do without settling how we should build and deliver it.

Teams often use skills and plugins interchangeably with hosted AI assistants and systems, and they may call the same AI capability an agent. These terms describe different parts of the design: how we package and deliver the capability as well as how much discretion it has at runtime.

In this article, we’ll evaluate these options by asking where the experience must live and what we want to reuse, then deciding what we would want to control and whether we can define the steps in advance.

Ownership & Runtime Behavior

Our first decision is about packaging and ownership: what we create and how people access it.

A skill packages instructions and supporting resources for a repeatable workflow.
A plugin packages skills and tools for distribution through a supported AI host.
A hosted AI assistant packages a configured conversational experience that people can use directly through an existing AI platform.
An AI system places the model inside an application we build and operate, giving us ownership of the interface and backend as well as data access and controls.

Runtime behavior is a separate decision about how much discretion the software needs while completing a task. Because runtime behavior is separate from packaging, these options can overlap within the same solution.

A system can load a skill that an agent follows, and a hosted AI assistant can use uploaded knowledge and tool connections within a product surface we don’t own.

The diagram below maps these options across ownership and runtime behavior, showing where they can overlap within the same solution.

When a Skill Is Enough

A skill fits when the part we need to reuse is the procedure itself, such as a team’s method for summarizing pull requests into release notes or reviewing a component for accessibility. Without a shared procedure, we have to rewrite the instructions for each request, which wastes time and produces uneven results.

Skills can package instructions and references alongside scripts and templates, although the exact structure varies by host. If the workflow needs to be installed in a compatible AI platform, a plugin can distribute the skill with any tool connections required for external services or data.

When a Hosted AI Assistant Fits

A hosted AI assistant is well-suited when people need a shared conversational experience within an existing AI platform. Within that experience, we can configure instructions and reference files alongside capabilities and approved service connections.

For an onboarding assistant, the team can upload a handbook and set the expected tone before sharing the assistant in its workspace, creating a usable pilot without requiring a chat UI or model infrastructure.

The tradeoff is control because the provider runs the experience and its policies govern sharing and service connections. Once the capability becomes part of our application, our authentication model and release process become necessary, along with telemetry and support. Those requirements call for a system we operate.

When We Need a System

We need a system when the AI capability belongs to our product because our backend must authenticate the user and gather permissioned context before calling the model and validating its response. The interface becomes part of that boundary because it handles streaming and source citations alongside approvals and error states.

The surrounding components matter as much as the model call: retrieval keeps answers grounded in current content and guardrails block invalid actions. Evaluation checks whether changes improve the feature while observability records which sources and tools shaped a production response.

A billing assistant may need to explain a charge using account data and current policy. The feature must enforce the billing product’s access rules, and support engineers need a trace they can inspect when an answer is disputed. Even with one model call, a product-owned system keeps those checks and traces in code our team operates.

A system like this can remain deterministic: the billing assistant gathers the relevant policy and charge data before drafting an explanation, and plain application code orchestrates the known path with less variability than an agent loop would introduce.

When to Add Agent Behavior

Agent behavior becomes useful when we cannot specify the full path before the work starts. With agents, a task often has four characteristics:

The input describes an outcome for the software to complete.
The software must choose among tools or information sources.
An intermediate result can change the next step.
The workflow continues until it completes the task or reaches a stopping condition such as an approval checkpoint.

An incident investigation has this shape because the first log query may point toward a deployment or a third-party outage. As each result changes what the system should inspect next, an agent can select the next tool and evaluate the result before revising its plan.

This flexibility creates more work around the loop because tools need narrow permissions and validated inputs. Expensive or hard-to-reverse actions need approval checkpoints, and every run needs a decision trace and a stopping condition.

A Decision Sequence

To decide which option fits, we can work through the following questions in order, starting with product ownership and ending with runtime behavior.

Where must the experience live? An existing AI host may already reach the intended users, so a reusable package or hosted AI assistant may be sufficient. An experience that belongs inside our application calls for a system we control.

Where must the experience live? An existing AI host may already reach the intended users, so a reusable package or hosted AI assistant may be sufficient. An experience that belongs inside our application calls for a system we control.

What are we trying to reuse? A repeatable procedure points to a skill, which can be packaged as a plugin if the procedure needs to be installed with tools. A configured conversational experience points to a hosted AI assistant.

What are we trying to reuse? A repeatable procedure points to a skill, which can be packaged as a plugin if the procedure needs to be installed with tools. A configured conversational experience points to a hosted AI assistant.

What must we control? A hosted AI assistant’s service connections remain within the host’s product and governance model. Product-owned authentication and permissioned customer data point toward a system, as do audit records and release management.

What must we control? A hosted AI assistant’s service connections remain within the host’s product and governance model. Product-owned authentication and permissioned customer data point toward a system, as do audit records and release management.

Can we define the steps ahead of time? A known path belongs in normal application orchestration; a changing path that requires tool choice and recovery may justify agent behavior inside that system.

Can we define the steps ahead of time? A known path belongs in normal application orchestration; a changing path that requires tool choice and recovery may justify agent behavior inside that system.

An AI system can include retrieval and memory as well as tools and evaluation without making every step adaptive. We can add a narrow agent only where an uncertain part of the workflow requires it.

How the Options Combine

A single capability may combine several options: a coding team can store its pull request review method as a skill and package that skill as a plugin when a wider group needs to install the workflow in a compatible AI platform.

A customer support feature can combine a chat interface with retrieval over permissioned documentation; tools can read account state and an evaluation set can cover common requests. Within that system, a skill can hold the support procedure, and agent behavior can handle the narrow investigative portion where each tool result may change the course of the work.

Wrap-up

Choosing an AI solution starts with two decisions: where the capability should live and how much freedom it needs while running.

A skill captures a repeatable method, and a plugin makes that method installable with tools. A hosted AI assistant delivers a configured experience through an existing platform, and a system gives us ownership of the product boundary. Both can support agent behavior when the route cannot be known in advance, allowing the software to choose and revise steps as the work progresses.

For more on building AI-powered applications and agents with Progress, check out the following resources: