Three words are doing the work of one, and the permission model pays for the confusion. A persona changes how an answer reads. A skill adds a capability. An agent chooses what to do next and then does it. Only the third acts while nobody is watching, which turns the definitional question into a security question: what does each of these get permission to touch?
Agents, Personas & Skills
What Is the Difference Between an AI Agent,
a Persona and a Skill?
Three constructs, three permission requirements. What each one is, how they chain, what a machine on your desk runs today, and where the human gate belongs.
Built from real buyer questions in our sales meetings
Direct Answer
A persona is who the assistant is being; a skill is something it can do; an agent is a loop that decides. In AirgapAI a persona is a named system prompt — a markdown file — pulled into a chat with an at-mention, the way you tag a colleague in Teams. A skill is a capability invoked on request, arriving as a slash command. Iternal defines an agent as more than a prompt: a de facto job role with provisioned credentials and an observability layer. A persona changes wording, a skill executes a capability, and an agent acts without one-by-one approval.
The limit: the local tier ships the persona and the skill, not the loop. The AirgapAI chat release running on laptops today carries no tool-calling loop of the kind cloud agents are known for — retrieval search is the closest thing in it to agentic behavior — and Iternal names these constructs personas rather than agents so buyers do not expect what has not shipped. A persona is authored inside a workflow rather than as a free-standing object, the capability is more experimental than the data-set side, a persona with data-set search switched off returns a hard failure instead of an answer, and the build asks users to set several parameters by hand. Sharpest of all: small local models cannot yet make several personas sound genuinely distinct, a ceiling in model intelligence rather than in software Iternal can patch.
Decide the permission model at the same time as the workflow. Three rules survive real deployments: every agent gets a least-privilege credential of its own, every action is either reversible or approval-gated, and the record of what the software did lives apart from what it said. Iternal's agent-auth work lends scoped, short-lived JWT tokens to agents rather than people and revokes them automatically, for on-device agent workloads and nothing past that.
Design for the agent you want; deploy the persona and the skill you can actually have. Keep anything that writes to a system of record behind an approval gate until loop, identity and observability exist together. For more information on which models a machine can host, visit the model provenance page; on wiring an assistant into your systems of record, visit the integration page. For more information on running an open-weight model of your own choosing behind a persona, visit the bring your own model page.
Three Definitions, Three Permission Consequences
Each definition below stands alone, because each gets quoted alone — into a security questionnaire, a design review, a policy document. The permission consequence is the half that goes missing, and the half that decides who approves it.
| Construct | What it is, in one sentence | What it changes about permissions |
|---|---|---|
| Persona | A persona is a named system prompt that changes how the assistant answers, not what it can reach. | It inherits the rights of whoever runs it: approving one is a content decision, not an access decision. Retrieval is set per persona. |
| Skill | A skill is a discrete, named capability the assistant invokes on request — in AirgapAI, a slash command. | The skill file is the artifact to review, because a person wrote it. Published skills elsewhere have prompt-injected an open agent loop into mailing a user's card details to an attacker. AirgapAI holds only the skills you bring in. |
| Agent | An agent is a loop that selects skills and takes actions until a goal is met. | It needs an identity of its own, a scoped credential, and a way to pull both mid-run. |
A fourth word earns its own line. A workflow chains prompts and processing steps, carries a persona and a fixed response structure, and can carry automations — which is why workflows sit in a different tier from skills. Personas run three ways inside one: independent answers, a sequential hand-off chain, a non-sequential roundtable. Authoring a persona in a workflow does not trap it there; any persona can be called on its own with an at-mention.
How the Hand-Offs Chain — and What to Log at Each One
Buyers ask two questions in one breath: can one answered question feed the next step, and do agents need the same tools a person uses? The second is easy — yes, and those are access controls, provisioned as you would for a human. The first is a sequence, and the sequence is where governance lives.
-
The request
The workflow supplies the system prompt and decides which personas are in play.
Record Who asked, under which workflow, with which personas enabled. -
Retrieval, checked per persona
For each enabled persona the software checks whether vector search is on for it, then queries whichever data set is active.
Record Which data set was active, and whether retrieval ran for that persona. -
The persona hand-off
Each persona applies its own knowledge on top of the prior output and the original document, until a compiler persona produces the deliverable.
Record The intermediate output at every hop; the final answer will not show them. -
The tool call
Where an agent tier exists, tasks become tool calls under an agent role, and the device reads — and potentially writes — to middleware beyond it.
Record The credential used, the target, the payload sent, the result returned. -
The escalation
A hand back to a person when the job exceeds what the model should settle.
Record Why it escalated, to whom, and what the person decided.
Steps four and five are where the local tier runs out today. Small local models remain unreliable at agentic tool calling next to server-class models, and most machines in a fleet lack the five to nine gigabytes of video memory the agentic model wants. AirgapAI Code supports MCP, and an outward connection to a platform such as Salesforce runs through a relay server. Agents require a chain of custody from the user to the agent acting for them, and the records above are what make it reconstructable.
How Long Does a Runaway Agent Have Before You Can Pull Its Access?
Attach a number to the question and the architecture argument settles itself. Buyers frame the risk concretely: an agent handed tools follows an instruction telling it to delete the production database, an agentic tool goes rogue and takes the network down, an agent becomes the exfiltration path an attacker never needed. The governing quantity is the same every time. Not whether it can be stopped — how long it runs first.
A fixed clock fails in both directions. Cap every credential at 24 hours and long-running work dies mid-flight: buyers described tokens expiring before long jobs finished, and noted that a credential good for a day cannot authenticate a file transfer that runs for a week. Leave the lease open and a compromised agent holds those rights as long as it lasts.
Lease to the job, revoke on completion, bound the worst case. The pattern Iternal builds toward lends scoped zero-trust tokens to the agent rather than a person, issues them as standard JWT tokens, and revokes them automatically; a token vending machine leases longer where the job is longer. In the example Iternal works through, the worst case is explicit:
12 hours
The access window a rogue agent would hold before revocation in that example — a number to govern against, not a product guarantee.
Twelve hours is something a security team can reason about. Take the credential you were about to issue, assume an attacker holds it for half a day, and decide whether that is survivable. If not, the credential is too broad rather than the lease too long: the fix is scope, not clock.
Do Not Point the Chat Straight at the Source
One objection stops more agent projects than any technical limit, and buyers state it plainly: connecting the chat interface directly to a data source is dangerous, and the security organization would say no. Querying data in place sets off every guardrail about what has access to what. As one buyer put it, no company will load all of its data and let an agent decide what in there is right.
The answer is an aggregator in the middle. Put a curated layer between the interface and the repository instead of a live query. Blockify does that job: it turns a corpus into validated idea blocks that are tagged, permissioned and traceable, small enough for a person to review every one. It sits at the chunking stage, so it works alongside guardrails you already run, and access can be scoped per department on a least-privilege basis.
The pattern changes the question your security team is asked: not live access to a repository, but a curated set with known provenance and known permissions. For more information on building that set, visit the governance page.
Where the Human Gate Belongs, by Action Class
Human in the loop is the phrase buyers reach for again and again, and Iternal advocates it on generated output — not as ritual, but because generated output gets numbers and chart types wrong often enough to matter. The failure mode is rarely a missing gate but a gate everywhere: buyers complain that every command needing its own permission grant is tedious, and tedium switches gates off.
| Action class | Example | Where the gate belongs |
|---|---|---|
| Read inside the boundary | Questioning a loaded data set; summarizing a document already on the machine. | No gate. Record it and move on. |
| Draft | A proposal response, a report, an outreach email. | Gate at send, not at generation. A person reviews before submission, and a workflow can flag redacted content before anything leaves. |
| Reversible write | Opening a ticket, updating a field, filing a record. | Gate by exception. Record every write with the credential that made it, and alert on anything unexpected. |
| Irreversible or outbound act | Deleting, paying, transmitting outside the boundary, acting on a customer or the supply chain. | Named approver, every time. Buyers are explicit that software given direct reins over customers eventually makes a call the business cannot live with. |
One risk no gate catches by itself: a biased answer removes judgment from the person through omission or subtle rephrasing, never through anything as visible as a wrong number.
Building Agents Got Easy. Governing Them Did Not.
The pain buyers describe here is a widening gap rather than a missing feature. In their own words: building agents has become easier and easier while monitoring, control, governance and discovery get harder every day. Allocating the right people and agents to the right tasks, with the right permissions and data, is the fundamental scaling problem, and it has to be solved across a decentralized estate rather than one console.
Bound the scope before you bound anything else. Iternal learned that the hard way: a first unsupervised agent run cost hours because nobody had bounded what it was allowed to attempt. Scope is the cheapest control available and the first one skipped.
The market has not closed the gap either: a unified observability layer for agents across an enterprise is what everyone is chasing and nobody has finished. Iternal bundles agent auth, a skills registry and observability under Iternal Workforce, with the caveat that the category is early. Settle which of them land in the build you receive in writing rather than from a demonstration:
Pin it down: questions for your evaluation
-
Which release carries the tool-calling loop, and is that the build we receive for the pilot?Whether the agentic behavior you saw demonstrated is in the version you are evaluating.
-
What is the maximum lifetime of a credential issued to an agent job, and who can revoke it mid-run?Your worst-case exposure window in hours, written down instead of inferred.
-
Which agent actions are recorded, and is that record kept separate from the chat transcript?Whether you can reconstruct what the software did without reading conversations.
Answered elsewhere
- Which model a machine can host, and bringing your own — see the model provenance page.
- Connecting an assistant to the systems of record you already run — see the integration page.
- Using a local model as the engine behind software you build — see the local backend page.
- Day-to-day practice with coding assistants — see the coding assistant page.
- User entitlements, single sign-on and the administrative console — see the access and administration page.
FAQ
FAQ: Agents, Personas and Skills
A markdown file holding a prompt and some context, given a name. You call one into a chat with an at-mention and it answers as a subject-matter expert with pre-prompting applied. AirgapAI ships 2,800+ pre-built workflows across industry verticals and departments; you can edit the personas inside them, generate new ones from a plain description, and package personas, workflows and data sets into a fleet bundle.
The same model, with different system prompts. An entourage nests several system prompts, one per persona, and splits the responses back out. Each persona can have retrieval switched on or off independently, and some are meant to run without it because their job is processing what an earlier step produced.
Chaining, yes: personas run as sequential hand-off chains, each building on the output before it until a compiler persona produces the deliverable. Tool access is an access-control question, provisioned as you would for a human. The limit is the loop itself — the AirgapAI chat release on a laptop today carries no tool-calling loop, and small local models remain unreliable at agentic tool calling.
No. That is a limit of local model intelligence rather than a setting you missed: a small model on a device cannot yet hold several personas genuinely apart, and Iternal is direct that software cannot patch around it. Iternal expects local models to close that gap within roughly six months.
Four controls, in the order they pay off: bound what it may attempt before it runs; give it a least-privilege credential that can be revoked mid-run; put a named approver in front of every irreversible or outbound action; and keep the record of what it did separate from what it said. And never point the interface straight at a live repository.
Write the Permission Model Before You Write the Workflow
Personas and skills go into production this quarter. The loop that acts on your systems arrives later, and safely only if the credential, the gate and the record are designed first. Do that work while the stakes are a badly worded paragraph rather than a deleted database.