Agents

An agent is a reusable definition of how the engine should behave for a kind of work: a name, a system prompt, and a default model. Where an assistant is the persona you talk to in the desktop, an agent is the lower-level definition the engine loads when it runs. The desktop assembles assistants on top of agents; the CLI works with agents directly.

Local and remote agents

The Agents settings panel has two tabs:

• Local agents run on the engine bundled with your desktop. You define the system prompt and model, and the agent runs against the providers you have connected.
• Remote agents point at an engine running somewhere else, reached over the Agent Client Protocol. The definition lives in the app, but the work happens on the other machine.

Wayland also ships a read-only pack of built-in agents. You can launch and copy these, but you edit a copy rather than the original, so an update never overwrites your changes.

In the engine

The engine exposes the same definitions through the agent command. wayland-core agent create, list, show, edit, and delete manage agent definitions on disk; agent list --builtins shows the built-in pack. You can pass a body from a file with @file. To run a single prompt against a named agent, use --agent <NAME>, and --list-agents prints what is available.

Because the desktop runs this same engine, an agent you define on the command line is the same definition the app loads. The two surfaces share the definition rather than reimplementing it.

How agents relate to assistants and teams

An assistant adds a persona, an avatar, attached skills, and scoped paths on top of an agent. A team groups several assistants under a leader. So the layering runs: agent (definition) to assistant (persona) to team (group). Most desktop users work at the assistant and team level; the agent layer is what you reach for when scripting the engine or building a definition by hand.

Next

• Assistants
• The Constitution
• Architecture Overview