Skip to content
LVIS AI
EN|KO

Host · Agents

Agents — Small Task Units, Handled Autonomously

If a plugin is an entire domain, an Agent is a single task. It's a small autonomous unit built to do one thing well — like 'create a weekly retro' or 'summarize today's action items.' The host calls these Agents through shortcuts, Hub messages, or automation triggers.

One task = one Agent
The host calls it
Agents call agents
Delegation scope is set by the user

How is this different from a plugin?

Plugin

A large unit that connects an entire domain (mail / calendar / meetings / internal portal) to the host. Has its own area, its own tools, and its own UI panel.

Agent

A small unit that does just one task well. Usually borrows a plugin's tools and has no UI of its own. Returns only a single result card.

How does an Agent get started?

  1. 01

    Shortcut / command palette

    Search directly for the Agent's name in the host's command palette. The most common way to call one.

  2. 02

    Delegate from the work board

    From the work board, choose "hand this task to this Agent" → the Agent produces the result in the background and returns it as a message.

  3. 03

    Automation trigger

    Also started by automation rules such as "automatically run the meeting-notes Agent when a meeting ends."

Agents call agents

There is a fourth way beyond the three above — a running agent spawning its own sub-agent. It splits a large job into pieces, handles each piece in its own context, and brings back only the result.

  • It starts on a clean context. A sub-agent does not inherit the parent's conversation history. The tool list it may use is resolved and recorded at spawn, and a run that stops partway is re-scoped to that recorded list when it resumes — resuming does not re-grant permission.
  • Usually nobody waits. On a surface that can deliver their results back to the parent, sub-agents run in the background — the parent gets a run handle immediately and the result arrives later as a message. The surface decides this, not the model: a model asking to run one in the foreground is ignored. On a surface with no delivery path, the run is foreground and the parent waits for it.
  • A run that stops partway can be continued. A sub-agent that exhausts its budget before finishing is marked incomplete and returns a ticket to resume. That ticket continues the same sub-agent from where it stopped — it does not start a new one.
  • It can be steered while it runs. A parent can push one more directive into a sub-agent that is still running.
  • Its thinking is visible. What a sub-agent is doing streams into a panel while it works. The result does not just appear out of nowhere.
A sub-agent's permission questions go to the parent first
When a sub-agent asks to use a tool, that question goes to the parent agent before it reaches the user. There is a ceiling on what the parent may decide, and the only values that ceiling accepts are low and medium — so high risk cannot pass through and goes to the user — see the permission model.

Where is it stored?

An installed Agent is kept as a single text file in the LVIS area on the user's PC. It contains its own behavior, its calling keywords, and the user group that can call it. It is never sent to an external server.

Safety limits on autonomous execution
Even when an Agent calls multiple tools on its own, that scope can never exceed the limit the user set at the time of delegation. If an action outside the delegated scope is needed, the Agent stops and asks the user for additional consent.
Relationship to the Marketplace's 'Agents' catalog
The Agents catalog in the Marketplace is the source for publishing and installing. Once an install deeplink reaches the host, a single Agent is stored at the location described above.
Previous

Skills — Ability Bundles

Next

MEMORY — What It Learned