Lexicon
Not a glossary of definitions in isolation. Every term here is explained next to the term people actually confuse it with, because that's usually the real question.
The direct answer: human in the loop means a person stays close enough to an AI system's work to check it, correct it, and decide when it can run on its own. Full automation removes that checkpoint entirely. Neither is universally right, the question is always which specific steps in a process still need a person, and which don't.
This is the actual method behind every PITL Enablement engagement, not a tagline. Every build starts by mapping exactly where a human needs to stay in the loop and where the work is safe to hand fully to an agent or automation.
The direct answer: an assistant responds to what you ask it, one request at a time, inside a conversation you're actively driving. An agent is given a goal and takes multiple steps toward it on its own, using tools, deciding what to do next, and checking in only when it hits a decision a human actually needs to make.
Most teams start with assistant-style use (asking Claude or Copilot questions) and only later move to agent-style use (Claude doing a multi-step task with a defined goal). Jumping straight to agents without the assistant habit already built rarely works. That order matters, and it's part of what an Assessment maps out.
The direct answer: a workflow is the sequence of steps a task actually follows, whether or not software is involved. An automation runs a fixed version of that sequence without a person, best for steps that are well-defined and repeatable. An agent handles the steps inside that sequence that require judgment, deciding what to do based on what it finds, not following a fixed script.
This is the mistake worth naming directly: not every problem is an agent problem. A lot of what teams actually need is a clearly mapped workflow and a well-built automation for the repeatable parts, with an agent doing only the piece that genuinely needs judgment. Reaching for an agent everywhere adds cost and fragility where a plain automation would do the job better.
The direct answer: Claude Skills are packaged instructions, examples, and sometimes files that teach Claude how to do a specific task the way your team actually does it, so it doesn't need re-explaining every time. MCP (Model Context Protocol) is different: it's how Claude connects to outside tools and data, like a calendar, a CRM, or a codebase.
Put simply: Skills teach Claude your team's know-how. MCP gives Claude access to your team's actual systems. Most real implementations use both, a Skill for how to do the work, MCP connectors for where the work's data lives.
The direct answer: most teams under 20-30 people are well served by Claude Team. Claude Enterprise matters when there's a specific governance requirement, SSO, audit logs, data residency, not because of headcount alone.
An Assessment maps your actual workflows to the right mix of tools, agents, and automations.
Book an Assessment