Blog
When to use: Agents vs. Skills
Teams building their first agentic workflow in healthcare tend to get stuck on the wrong question. They ask "should this be an agent or a skill?" when the useful question is "what part of this needs judgment, and what part needs to happen the same way every single time?" This guide gives actAVA KORA users a clean mental model (skills are packaged know-how, agents are workers with judgment that can call those skills), a 4-question decision rule that stops at the first match, and a side-by-side comparison of what triggers each, how much autonomy each has, and what each is best for.
By Joon Lee
If you build on actAVA KORA, you hear two words constantly: agents and skills. They're related, they overlap, and the line genuinely blurs as workflows get more sophisticated. Here's a clean mental model, a fast decision rule, and how both map to the suite you already run.
Most teams building their first agentic workflow in healthcare get stuck on the same question, and it's rarely the one they think they're asking. They ask "should this be an agent or a skill?" when the real question is "what part of this needs judgment, and what part needs to happen the same way every single time?"
Answer that second question and the first one answers itself.
A skill is a saved, reusable way of doing one task well. An agent is a worker that decides which skills and tools to use to reach a goal. Skills are know-how. Agents are doers.
What each one actually is
A skill is packaged know-how
A skill is a reusable workflow stored in a portable file. It captures the process, structure, quality bar, must-haves, and things to avoid for one repeatable task, all in one place. When you invoke a skill, the system already knows how you want that task done, so you don't restate the instructions every time.
On KORA, think of a skill as the difference between writing a 5-paragraph prompt for a HIPAA-aligned discharge summary every single time, and simply saying "use the discharge-summary skill." The formatting, the compliance constraints, the tone, and the structure are baked in.
Key trait: a skill's trigger is you. It runs when invoked, and it does the same defined thing each time, reliably and on demand.
An agent is a worker with judgment
An agent is given a goal, a set of instructions, and access to tools, then it makes decisions on your behalf to reach that goal. It can read data, call tools, browse, run multiple steps, check its own work, and keep going until the goal is met. Critically, an agent can call skills as part of doing its job.
An agent brings together 3 things a skill does not: a trigger (a schedule, an event, or a request that sets it in motion), tool use, and often verification. It orchestrates all of it to complete a task.
You're the customer. The agent is the mechanic: it went to school, has a list of allowed actions, and decides the best way to get the job done. The skills are the tools and techniques on the mechanic's belt, specific and reliable ways of doing each individual thing.
You ask for an outcome. The agent figures out which skills to apply.
The core distinction
Two rules capture almost everything you need to remember.
Agents can use skills. Skills cannot use agents. A skill saves a workflow. An agent decides and executes a goal, choosing tools, taking actions across steps, and checking results.
So the question is rarely "agent or skill?" in isolation. Most mature KORA workflows use both: an agent runs the show, and skills give it consistent, governed ways to perform each repeatable step.
| Dimension | Skill | Agent |
|---|---|---|
| What it is | A saved, reusable workflow | A goal-driven worker that takes actions |
| What triggers it | You invoke it on demand | A request, a schedule, or an event |
| Decision-making | None, it does the defined thing | Chooses tools and steps to hit the goal |
| Tool use | Can include scripts and templates | Orchestrates many tools and connectors |
| Runs unattended? | No, hands-on by design | Yes, scheduled or event-driven |
| Best for | A consistent, repeatable task | A multi-step outcome across tools |
The decision rule
When you're not sure which to build, walk these questions in order and stop at the first match.
- Do you need a consistent, repeatable way to do one task? Build a skill. Rule of thumb: if you've done it by hand more than twice, make it a skill.
- Do you need something to run on its own, on a schedule or in response to an event, and act across tools? Build an agent.
- Do you want a hands-on assistant you drive step by step? Reach for a skill, optionally inside an agent's reach.
- Do you want an outcome to just appear, a report in your inbox, a record updated, a case triaged? That's an agent.
If you want to do something hands-on, you're probably using a skill to help you through it. If you want something to happen and just show up when you need it, you're using an agent. The simplest test
How this maps to the KORA suite
actAVA's platform is built around exactly this build-deploy-run pattern, so the agent and skill distinction lines up cleanly with the products you already use.
KORA|BLUE, build and orchestrate
This is where agents and skills are defined and deployed. BLUE.build assembles each agent's tasks, tools, and guardrails through the natural-language command center. The repeatable, governed steps you encode here are effectively your skills. The role-aware, reason-aware worker that routes between them is your agent. BLUE.deploy handles agent-to-agent orchestration, and one agent delegating to another is the multi-agent version of an agent calling a skill.
KORA|RED, test what you built
Agents have more autonomy, which means more surface area for things to go wrong. KORA|RED red-teams agents and their tool use before they touch production. Think of it as the safety counterpart to giving an agent real decision-making power.
KORA|GREEN, keep it improving
Skills are versioned, living artifacts. You refine them as you catch mistakes ("always do this," "never do that") and label versions so your team runs the latest. KORA|GREEN's continual-learning architecture is where that improvement loop lives at platform scale, across both agents and the skills they rely on.
In healthcare, the agent and skill split is also a control surface. Skills let you lock a process so the format, compliance constraints, and quality bar can't drift between runs. Agents let you set permissions per tool: read-only where you want visibility, approval-required for anything that writes or deletes.
Decide deliberately which steps an agent may run unattended and which need a human in the loop.
3 worked examples
A discharge-summary format (skill)
Your clinical-ops team produces discharge summaries that must follow a fixed structure and HIPAA-aligned redaction rules. You do this constantly, the same way each time. Textbook skill: encode the structure, the compliance constraints, and the tone once, version it, and invoke it on demand. No autonomy needed, because you want it identical every time.
A nightly staffing-risk brief (agent)
You want a staffing-risk report in your inbox every morning without lifting a finger. The worker needs to wake on a schedule, pull from multiple data sources, analyze ratios and overtime, format the findings, and deliver them. That's an agent: it has a time trigger, calls multiple tools, and produces an outcome unattended. Along the way it may invoke a staffing-brief skill to keep the report format consistent.
Resume-bias screening at scale (agent plus skills plus verification)
A compliance workflow that screens resumes for bias needs both: skills to apply consistent screening criteria and produce audit-ready output, and an agent to run the batch, route flagged cases, and check its own work. For anything this sensitive, give the agent a verifier, a second pass whose job is to be critical of the first pass's output, rather than trusting a single run.
An agent that writes its own output tends to treat that output as finished because it produced it. Pair a writer with a verifier: a sub-agent or a second model whose job is to critique against your standard for what good looks like.
On a high-stakes agentic workflow, that's the cheapest insurance you can buy.
Common pitfalls to avoid
- Building an agent when you needed a skill. If there's no trigger, no tool orchestration, and no decision-making, you've just wrapped a workflow in unnecessary autonomy. Use a skill.
- Hand-prompting the same task forever. If you've done it more than twice, the prompt belongs in a skill. You'll never find that one good chat again when you need it.
- Runaway loops with no exit. When an agent runs a goal-seeking loop, set a quantitative stop ("do this at most 3 times," or a clear "done looks like X") and a cost ceiling. Don't let it chase the last 1%.
- Unversioned skills. Label versions (v1.2, v1.3) so you and your team aren't silently running different copies of the same workflow.
- Over-permissioning agents. Default write and delete tools to approval-required. Reserve always-allow for read-only operations.
Quick reference
| If you want to… | Build a… |
|---|---|
| Do one repeatable task the same way every time | Skill |
| Standardize format or compliance for a deliverable | Skill |
| Have work run on a schedule or on an event | Agent |
| Take actions across multiple tools and connectors | Agent |
| Produce an outcome unattended | Agent |
| Give an agent a consistent way to do each step | Skill, inside the agent |
| Bundle many skills and connectors to share with a team | Plugin |
Start with the skill. It's the smaller commitment, it's the piece you'll reuse regardless, and it's the thing an agent will need anyway once you build one. Autonomy is worth adding when there's a trigger and an outcome waiting on the other side of it, and not a moment earlier.
Build agents and skills on governed rails
See how actAVA KORA lets your teams encode skills once, wrap them in agents with per-tool permissions, and test both before anything touches production.
Start a conversation
Written by
Joon Lee
Lead Forward Deploy Engineer
